Composer 2.2+ 插件权限：从“装上了”到“跑起来”，你缺了哪一步？
很多开发者都踩过这个坑：明明用 composer require 把插件包装好了，可它就像个“幽灵”，死活不生效。问题出在哪？其实，Composer 从 2.2 版本开始，安全策略大幅收紧——默认情况下，它会禁用所有插件的执行，除非你明确地、逐项地给它“开绿灯”。换句话说，装上包只是拿到了入场券，能不能真正“登台表演”，还得看几道关键的权限开关。
第一道闸门：composer.json 里 config.disable-plugins 必须为 false 或未设置
这是最隐蔽、也最容易忽略的总开关。只要在你项目根目录的 composer.json 里发现了这行配置：
"config": {
"disable-plugins": true
}
那么，无论你后续安装了多少合法的 composer-plugin 包，它们都只会静静地躺在 vendor 目录里，永远不会被实例化和调用。
- 怎么检查？ 运行
composer config disable-plugins，如果输出是true，那插件的大门就被彻底关死了。 - 临时开启： 执行
composer config disable-plugins false，这个改动会直接写入当前项目的配置。 - 注意全局配置： 更要小心的是，如果你运行过
composer config -g disable-plugins true，这个“禁用”指令会影响到你机器上的所有项目。除非有特殊的安全考量，否则生产环境外通常没必要这么做。
第二道关卡：全局配置中 plugin-autoloader 不能被禁用
Composer 2.2+ 引入了一个名为 plugin-autoloader 的安全功能，专门负责插件的安全加载。如果这个功能被意外关掉，那么即使插件类型正确、第一道闸门也打开了，它也会静默失败，让你无从查起。
- 检查命令：
composer config -g allow-plugins - 默认状态： 其默认值是
null，这意味着 Composer 会在遇到新插件时提示用户进行确认。但有些 CI/CD 流水线或 Docker 基础镜像为了自动化，可能会将其设置为false，这就导致了问题。 - 精细化控制： 你可以选择只放行特定的插件。例如，只允许
phpstan/phpstan运行，可以设置为{"phpstan/phpstan": true}。 - 风险提示： 直接设置为
true会允许任何composer-plugin自动执行，这在生产环境中存在安全风险，一般不推荐。
关键动作：安装后必须运行 composer install 或 update 才触发插件激活
这是一个常见的操作误区。composer require vendor/plugin-name 这个命令，本质上只是修改了 composer.json 和 composer.lock 文件。此时，插件的代码虽然被下载了，但它的类还没有被 Composer 的主进程扫描和实例化。
- 正确流程： 先执行
require，然后必须紧接着执行一次composer install（或composer update vendor/plugin-name）。 - 如何验证加载成功？ 在运行安装或更新命令时，加上
-v（详细）参数。在输出信息中搜索，看看是否有Using version x.y for vendor/plugin-name以及插件自身输出的自定义日志（例如[MyPlugin] activated）。 - 一个隐蔽的坑： 如果插件类的构造函数抛出了异常，Composer 可能会静默跳过它——没有错误提示，但关键的
activate()方法就是没执行。因此，在开发调试插件时，不妨在构造函数里加个简单的echo或日志语句，来确认执行流是否真的到达了这里。
最高权限：extra.allow-plugins 配置优先级最高，且不可绕过
从 Composer 2.2 开始，项目 composer.json 中顶层的 extra.allow-plugins 字段被赋予了“一票否决权”。它的设置会覆盖全局的 allow-plugins 配置，并且无法通过命令行参数绕过。
- 示例配置（白名单模式）：
"extra": { "allow-plugins": { "phpstan/phpstan": true, "lara vel/pint": true } } - 白名单机制： 如果一个插件没有出现在这个白名单对象里，那么即使
disable-plugins是false，它也会被坚决地拒绝加载。 - 特殊值含义： 将其设置为空对象
{}等同于禁止所有插件；设置为true则会恢复旧版本的行为（允许所有插件，不推荐）。 - 最终性： 这个字段是“最终裁决”，想修改它，唯一的方法就是直接编辑
composer.json文件，然后重新安装依赖。
说到底，插件不生效的症结，往往不是代码逻辑有 bug，而是它在 Composer 的启动阶段就被安全策略给“过滤”掉了——它连自动加载的门都没进去，自然没有机会报错。所以，下次再遇到插件“装聋作哑”的情况，别急着埋头翻源码。先按顺序检查这三处：disable-plugins、allow-plugins、extra.allow-plugins，排查效率会高得多。
