跳转到主要内容
基础用法请参考指南页面。本文介绍官方文档没有涉及的实战模式。

多租户 SaaS 中的团队范围

如果想按团队(租户)而不是按个人用户来管理标志,可以把默认范围改成团队。
这样 Feature::active('billing-v2') 就会自动以当前团队为对象。无论团队成员是谁,只要属于同一个团队,得到的结果就一致,UI 也能保持一致。 以下是按团队注册时间做灰度发布的例子。
只想对特定团队开启的场景(例如面向企业客户的抢先体验):

紧急 kill switch(利用 before 方法)

生产环境发现 bug 时,可以不回滚代码就立即关闭某个功能。给基于类的 feature 添加 before 方法,检查会先于存储中的值执行。
只需要设置环境变量 FEATURES_NEW_CHECKOUT_DISABLED=true,就能在不动 DB 的情况下关闭功能。这是无需部署的 kill switch。
before 返回 null 时会执行 resolve(),返回 false 时立即视为未激活。除紧急情况外,请返回 null

定时发布

想在某个特定日期自动向所有用户开放的场景。用 before 方法即可实现。
这样过了 2025-04-01 就会自动向所有用户开放。无需部署、无需 DB、无需 Artisan 命令,自动化完成。

暗发布(Shadow Mode)

一种在不给用户看到的前提下用生产数据运行新逻辑,并把结果与旧逻辑比较的模式。没有问题时,只需要打开开关就完成发布。
确认日志中没有差异后,把标志切换到 recommendation-v2 就好。

用事件来收集 A/B 测试结果

官方文档提到了 FeatureRetrieved 事件,但没有给出实际的 A/B 测试收敛模式。 FeatureResolved 事件仅在 feature 值首次被解析时触发。可以用它来记录用户被分配到的变体。
在转化发生时另行记录,就能按变体统计转化率。
FeatureResolvedFeatureRetrieved 的区别:FeatureResolved 只在首次评估时触发,FeatureRetrieved 每次检查都会触发。记录变体分配用 FeatureResolved,页面浏览追踪用 FeatureRetrieved 更合适。

队列作业中的范围

在队列作业中不存在已认证用户,所以 feature 检查可能出现意外行为。请给作业显式传入范围。
也可以在派发作业时评估好标志,然后传给作业。

用 Artisan 命令做管理 UI

写一个管理标志的简单 Artisan 命令,不用部署就能操作生产标志。

Feature 名称的安全重构(Name 属性)

在重命名基于类的 feature 时,如果 DB 中保存的标志名跟着变,所有用户的标志都会被重置。用 Name 属性固定保存名。
这样即便你自由重构类名,DB 里的数据也不会变。

总结

在掌握官方文档的基础用法后,以下模式能真正发挥 Pennant 的价值。

Laravel Pennant 指南

安装和基础用法请参考指南页面。
最后修改于 2026年7月18日