Composer 2.2+ 默认禁用所有插件，必须在 composer.json 根级显式声明 allow-plugins 数组列出可信插件名（大小写敏感、无通配符），否则 composer install 直接失败；config.disable-plugins 必须为 false 或未设置，extra.allow-plugins 配置优先级最高且不可绕过。
Composer 默认会禁用插件执行，除非你明确允许——不是装上包就自动生效，而是得让 Composer 主进程“愿意加载”它。
composer.json 里 config.disable-plugins 必须为 false 或未设置
这是最常被忽略的开关。只要项目根目录的 composer.json 中有这一行：
"config": {
"disable-plugins": true
}
哪怕你 require 了合法的 composer-plugin 包，它也完全不会被实例化。
- 检查方式：运行
composer config disable-plugins，输出true就是关死了 - 临时启用：执行
composer config disable-plugins false（会写入当前项目配置） - 全局禁用更危险：运行
composer config -g disable-plugins true会影响所有项目，务必确认是否真需要
全局配置中 plugin-autoloader 不能被禁用
Composer 2.2+ 引入了 plugin-autoloader 功能，用于安全加载插件类。如果它被关掉，插件即使类型正确、权限放开，也会静默失败。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查命令：
composer config -g allow-plugins - 默认值是
null（即提示用户确认），但 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） - 插件类构造函数抛异常会导致静默跳过——没有报错，但
activate()不执行，建议加简单echo或日志确认入口是否到达
extra.allow-plugins 配置优先级最高，且不可绕过
从 Composer 2.2 开始，composer.json 顶层的 extra.allow-plugins 字段拥有最终决定权，它会覆盖全局 allow-plugins 设置。
- 示例配置（只允许两个插件）：
"extra": { "allow-plugins": { "phpstan/phpstan": true, "laravel/pint": true } } - 若插件不在该白名单中，即使
disable-plugins是false，也会被拒绝加载 - 设为
{}（空对象）等价于全部禁止；设为true则恢复旧行为（不推荐） - 这个字段无法通过命令行参数覆盖，只能改文件后重装依赖
真正卡住人的地方，往往不是插件代码写错了，而是 Composer 在启动阶段就把它筛掉了——它连 autoloader 都没进，自然没机会报错。每次怀疑插件不生效，先查 disable-plugins、allow-plugins、extra.allow-plugins 这三处，比翻源码快得多。
