Composer怎么配置忽略插件 Composer环境安全性调整手册

--no-plugins 在 CI/CD 和生产部署中属于硬性安全要求，因为它会彻底绕过 PluginManager::loadPlugins()，禁用所有插件的加载与执行，从根本上防止恶意或不可信插件导致任意代码执行。

必须加 --no-plugins，否则在 CI/CD 或生产部署中，插件有机会执行任意代码——这不是可选项，而是安全底线。

先说一个核心判断：在CI/CD或生产环境里，--no-plugins这个参数不是锦上添花，而是硬性指标。理由很简单——Composer插件在 install 或 update 时会自动加载并执行PHP代码，而且来源不限于 composer.json 里的 require；它可能来自全局配置、项目 extra.plugins，甚至第三方包的 installer 声明。一旦插件被篡改或不可信，composer install就相当于直接运行远程代码，风险极高。

加上 --no-plugins 后，Composer会完全跳过 PluginManager::loadPlugins() 流程——不扫描、不实例化、不触发任何插件生命周期方法。这不是“禁用”，而是“彻底绕过”，效果天差地别。

• CI脚本里没加这个参数？等同于给所有PR开后门。
• 用Docker构建时依赖镜像预装插件？必须显式禁用，不能靠“默认没装”这类侥幸心理。
• 某些私有仓库认证插件（比如自定义token注入）会在安装阶段调用API，禁用后这类行为直接消失。

为什么 --no-plugins 必须放在命令末尾前，且不能和wrapper冲突

参数顺序直接影响它是否生效：Composer解析时会优先把 --no-plugins 当作早期开关，用于决定是否初始化插件系统。位置放错，就等于没加。

• ✅ 正确：composer install --no-plugins --no-interaction --no-scripts
• ❌ 错误：composer install --no-interaction --no-plugins（旧版Composer可能静默忽略）
• ❌ 错误：composer --no-plugins install（这等价于 composer --help，完全不是一回事）
• 如果CI里用了封装脚本（比如 bin/composer），要确认它没自动注入 --plugins 或覆盖环境变量。

禁用插件后哪些功能会降级或失效

需要明确一点：--no-plugins 不影响 scripts（如 post-install-cmd），只跳过插件注册。但很多常用功能就依赖插件实现，禁用后会回退到最基础的行为，带来一些具体影响：

• hirak/prestissimo：并行下载失效 → 恢复串行下载，速度变慢但行为可预测。
• composer/installers：不再将WordPress插件装进 wp-content/plugins/ → 全部回落到 vendor/ 标准路径。
• PHPStan / Psalm扩展安装器：扩展不会自动注册 → phpstan analyse 可能报 “unknown rule”。
• 自定义installer（比如处理 .phar 或私有协议的情况）：直接报错 “Could not parse version constraint”。

注意：vendor/bin/ 下的可执行文件（如 php-cs-fixer）不受影响——它们不是插件，只是普通的二进制文件。

别指望“只禁一个插件”，真想控制得从源头下手

Composer目前没有 --disable-plugin=xxx 这种细粒度开关。所谓“只禁某个”插件，实际只有三条路可走：

• 在 composer.json 的 extra 字段里写："disabled-plugins": ["vendor/package-name"]（需要 Composer ≥2.2）。
• 临时删掉 vendor/vendor-name/package-name 目录（⚠️ 危险：会破坏 autoload 和完整性校验，下次 install 可能失败）。
• 用环境变量 COMPOSER_NO_PLUGINS=1 替代（效果等同 --no-plugins，但更隐蔽，CI日志里容易被忽略）。

真正关键的是意识到：插件一旦激活，就能 hook 到 install、update、dump-autoload 等几乎所有核心流程。所以CI中每一条Composer命令都该显式带上 --no-plugins，而不是等出了事再回头补上。