–no-plugins 是诊断插件兼容问题的“安全模式”，仅禁用全局及项目声明的插件，不触自动加载、脚本或非插件命令；遇类未找到、卡死、升级后报错等现象应优先尝试。
为什么 --no-plugins 有时是唯一能跑通命令的选项
某些 composer 命令在插件干扰下会直接失败，比如 composer install 卡在 PluginManager::loadPlugins()、composer update 报 class not found（实际是插件里某个 autoload 逻辑崩了），甚至 composer diagnose 自己都报错。这不是你项目写错了，而是插件本身和当前 Composer 版本、PHP 版本或依赖树存在兼容问题。禁用插件不是“绕过问题”，而是快速确认问题是否由插件引发——它相当于给 Composer 启一个“安全模式”。
--no-plugins 真实生效范围和常见误判
这个参数只禁用 全局安装的插件 和 项目 composer.json 中声明的插件（即 "extra": {"plugin": ...} 或通过 require 引入的插件包）。它不跳过：Composer 自带功能（如 autoloader 生成）、脚本（scripts 字段里的 post-install-cmd 等）、或非插件类的第三方包提供的命令（比如 phpunit 本身不是插件，不受影响）。
- 如果你用的是
hirak/prestissimo（http 并行下载插件），加--no-plugins后下载会变慢，但不会报错 - 如果你装了
dealerdirect/phpcodesniffer-composer-installer，禁用后 PHPCS 规则不会自动注册到phpcs命令里，但phpcs本身还能运行 - 某些 CI 脚本硬编码了插件行为（比如靠插件注入自定义仓库源），此时禁用会导致
Could not find package
哪些场景必须加 --no-plugins
不是所有命令都需要它，但遇到这几类现象时，第一反应就该试：
-
composer update报PHP Fatal Error: Uncaught Error: Class 'SomePluginClass' not found，且该类确实存在于插件包中 -
composer install在Loading composer repositories阶段卡住超过 2 分钟，strace显示反复尝试访问不存在的插件配置路径 - 升级 Composer 到 2.5+ 后，原来正常的
composer dump-autoload -o开始报ArgumentCountError，怀疑是插件 hook 传参签名变了 - 想验证某个问题是否与插件无关（例如：删掉
vendor和composer.lock后仍复现，就加--no-plugins再试一次）
替代方案比 --no-plugins 更危险？
有人会改 composer.json 临时删掉插件依赖，或者手动删 vendor/bin 下插件注册的二进制文件。这两种做法风险更高：
- 删
require里的插件包，可能触发 Composer 自动移除其他依赖（因为插件包可能被其他包conflict或replace） - 删
vendor/bin文件，下次install会重建，但中间如果执行了脚本（如post-autoload-dump），可能因找不到对应二进制而失败 -
--no-plugins是纯运行时开关，不改任何文件，不触发重安装，不影响 lock 文件，最干净
真正麻烦的是插件本身没提供 disable 开关，又没法升级——这时候 --no-plugins 就是唯一可控的杠杆。别指望它解决插件 bug，但它能帮你把问题域缩到最小：是插件的问题，还是别的地方出了岔子。