--no-plugins 能阻止恶意插件执行，因为它彻底跳过插件的发现、注册和激活流程，连 PluginInterface::activate() 都不会调用，从而杜绝投毒插件在 composer install/update 时运行任意代码。
为什么 --no-plugins 能阻止恶意插件执行
Composer 插件在安装/更新时自动加载并运行任意 PHP 代码，权限等同于当前用户。一旦插件包被投毒（比如维护者失陷、包名劫持），composer install 就可能触发远程命令执行、凭证窃取或依赖污染。而 --no-plugins 会跳过所有插件的发现、注册和激活流程——不是“禁用”，是彻底不加载，连 PluginInterface 的 activate() 都不会被调用。
这招对 CI/CD 环境尤其关键：你无法完全信任 composer.json 里声明的插件来源，尤其当项目引入了第三方模板、脚手架或老旧生态包（如某些 Laravel 5.x 插件）时。
composer install --no-plugins 的真实使用场景
它不是日常开发命令，而是用于受信程度低、自动化程度高的环节：
- CI 构建阶段（GitHub Actions / GitLab CI），尤其当
composer.lock不由你直接生成时 - 生产环境部署脚本，避免因本地
composer.json意外包含插件而触发非预期行为 - 审计或沙箱分析：想纯看依赖树、不跑任何钩子逻辑时
- 修复被插件破坏的环境（比如某插件覆盖了
autoload导致Class not found）
注意：--no-plugins 不影响核心功能——自动加载、依赖解析、包下载、post-install-cmd 脚本（除非脚本本身是插件写的）照常工作。
容易踩的坑：你以为关了插件，其实没关干净
这几个点不注意，--no-plugins 就形同虚设：
-
composer update默认仍会加载插件来决定是否需要更新插件自身——必须显式加--no-plugins，只写在install上没用 - 全局插件（如
hirak/prestissimo或phpstan/extension-installer）也会被跳过，但如果你依赖它加速下载或注入扩展，--no-plugins会导致失败或降级行为 - 某些“伪插件”不走 Composer 插件机制，而是靠
scripts+require-dev组合实现类似效果（比如用phpunit的--bootstrap加载恶意文件），这种--no-plugins完全不管 - 如果项目根目录有
composer.json声明了插件，但你 cd 进子目录执行composer install --no-plugins，它仍然会读父级配置——路径不影响插件加载范围
更安全的组合姿势：不止靠 --no-plugins
单靠这个参数不能解决全部风险，得配合其他约束：
- 在 CI 中固定 Composer 版本（如
COMPOSER_VERSION=2.5.8），避免新版自动启用未声明的插件类型 - 用
composer install --no-scripts --no-autoloader --no-plugins三连，彻底剥离所有可执行逻辑，后续再分步补全 - 检查
composer.json是否含"extra": {"plugin-api-version": "..."}或"require"里有知名插件包名（如squizlabs/php_codesniffer的旧版插件模式），提前人工审计 - 生产部署优先用
composer install --no-dev --no-plugins --optimize-autoloader，既防插件又减体积
真正麻烦的是那些没声明为插件、却通过 autoload-files 或 scripts 注入的代码——它们不会出现在插件列表里，--no-plugins 对它们毫无感知。这时候得靠文件完整性校验或运行时沙箱了。
