--no-plugins仅临时跳过插件激活与事件绑定，不阻止类加载、scripts执行或全局插件；真正禁用需配置allow-plugins: false或全局设置。
--no-plugins 确实能禁用所有 Composer 插件，但它不是“安全运行”的万能开关，而是一个临时隔离手段——仅在当前命令生效，不改变配置、不阻止插件注册，更不防范恶意代码已加载的情况。
什么时候必须加 --no-plugins
它只在你明确怀疑某插件干扰了当前操作时才有意义，比如：
- 执行
composer install卡在某个自定义脚本（如pre-install-cmd），怀疑是插件注入的钩子导致 - 调试
composer dump-autoload失败，想排除插件重写自动加载逻辑的可能 - CI 环境中需要确保行为与本地开发完全一致，而团队又未统一禁用插件
- 运行第三方
composer.json（如从不可信源下载的包）前做最小化环境验证
--no-plugins 不等于“安全模式”
它不阻止以下行为：
- 插件类仍会被
autoload加载（只要它们在vendor/autoload.php中被声明） -
composer.json里定义的scripts依然执行（插件常通过 scripts 注入逻辑） - 已通过
composer global require安装的全局插件，在非全局命令下不受影响（--no-plugins只作用于当前项目上下文） - 插件若已在
vendor/composer/autoload_plugins.php中静态注册，部分生命周期事件仍可能触发
换句话说：它跳过插件的 activate() 和事件绑定，但无法撤回已加载的类或已修改的全局状态。
真正限制插件的两种可靠方式
如果目标是长期可控、可审计的插件管理，应该：
- 在项目根目录的
composer.json中显式设置：{ "config": { "disable-tls": false, "secure-http": true, "allow-plugins": false } }该配置从 Composer 2.2+ 开始生效，会拒绝任何插件启用，除非在allow-plugins中白名单列出（如"phpstan/extension-installer": true） - 全局禁止（需谨慎）：
composer config -g allow-plugins false
这会影响所有项目，适合严格合规环境，但可能破坏依赖特定插件的工具链（如hirak/prestissimo已废弃，但旧项目仍可能引用）
常见误用和副作用
加了 --no-plugins 却发现命令失败？大概率是因为：
- 你依赖的某个包（如
symfony/flex）本身就是插件，且其功能被硬编码进安装流程（例如自动写入配置文件），禁用后composer install会跳过这些步骤，导致应用启动报错 -
composer create-project默认启用插件，若用--no-plugins，则post-create-project-cmd类脚本不会运行，可能缺失初始化文件 - 某些私有仓库认证插件（如
composer-aws-s3-plugin）被禁用后，composer update直接因无法拉取包而终止
插件不是敌人，而是 Composer 生态的扩展机制；盲目禁用比放任更危险——关键在知道哪个插件做了什么，以及它是否真的必要。
