composer 安装 laravel pennant 无需额外配置但需 laravel 10.43+ 或 11.x，低于版本会报 class not found；vendor:publish 无反应因 pennant 默认不注册命令且需手动指定 --tag=pennant-migrations 或 --tag=pennant-config；features::active() 返回 false 可能因默认 array 缓存未刷新，建议开发时设 driver => 'database' 或调用 flushcache()；livewire 中调用失败多因服务容器绑定延迟，应避免在 mount() 或构造函数中直接使用，改在 render() 或 boot() 中解析；核心问题在于生效时机依赖服务启动顺序、缓存策略与门面解析时机，调试应优先检查 config/pennant.php 驱动配置及 app_debug=true 下的门面绑定状态。
Composer 安装 Laravel Pennant 不需要额外配置，但必须满足 Laravel 10.43+ 或 11.x，且项目已启用 Laravel Pint / Pest（非强制但官方推荐）——低于这个版本会直接报 class not found 错误。
为什么 composer require laravel/pennant 后 php artisan vendor:publish 没反应
这是最常见的卡点：Pennant 默认不注册 Artisan 命令，也不自动发布配置或迁移，它靠“按需加载”机制工作。只有当你第一次调用 Features::active() 或运行 php artisan pennant:install（Laravel 11.9+ 新增）时，才会触发初始化。
- 如果你用的是 Laravel 11.9+，直接运行
php artisan pennant:install，它会自动生成迁移、发布配置pennant.php并注册服务 - 如果用的是 Laravel 10.43–11.8，得手动执行：
php artisan vendor:publish --tag=pennant-migrations和php artisan vendor:publish --tag=pennant-config - 漏掉
--tag=xxx参数是导致“没反应”的最常见原因，vendor:publish默认只列可选项，不会自动选中 Pennant
Features::active('billing_v2') 返回 false，但数据库里明明有记录
Pennant 默认使用内存缓存（array 驱动），不读数据库，除非你显式切换驱动或调用刷新方法。也就是说，即使你用 Tinker 插入了 Feature 记录，Features::active() 仍可能返回旧值。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 开发时建议在
config/pennant.php中把'driver' => 'database'，避免缓存干扰 - 若坚持用
array驱动，每次修改后需调用Features::flushCache()，否则缓存永不更新 - 注意：数据库驱动下，
Features::activate()会写入feature_flags表，但该表默认无索引，高并发场景下可能因行锁变慢
在 Livewire 组件里用 Features::active() 报 Target class [features] does not exist
这不是 Pennant 的问题，而是 Laravel 的服务容器绑定延迟导致的——Livewire 在组件实例化早期就尝试解析 Features，而 Pennant 的服务提供者还没完成注册（尤其在某些包加载顺序异常时）。
- 最稳解法：不要在
mount()或属性初始化里直接调用Features::active()，改用 lazy 方式，例如：$this->shouldShowNewBilling = Features::active('billing_v2');放在render()里 - 或者在
boot()方法中提前 resolve：$this->features = app('features');，再用$this->features->active(...) - 别试图在
__construct()里注入Features，Livewire 不支持构造函数注入门面类
Pennant 的核心复杂度不在安装，而在“什么时候真正生效”——它依赖 Laravel 的服务启动顺序、缓存策略和门面解析时机。哪怕命令跑通了，也可能在请求生命周期某个环节静默失效。调试时优先检查 config/pennant.php 的 driver 和 APP_DEBUG=true 下的门面绑定状态，比反复重装 Composer 包有用得多。
