--no-plugins是唯一可靠方案，因它强制跳过所有插件加载与执行（含PluginInterface::activate()），而环境变量、disabled-plugins配置或目录操作均存在隐蔽性、版本限制或失效风险。
必须用 --no-plugins 才能真正跳过插件加载，其他方式只是绕开或掩盖问题。
为什么 --no-plugins 是唯一可靠方案
Composer 插件一旦被识别（无论来自 require 还是全局安装），就会在 install、update、dump-autoload 等几乎所有命令前自动激活，并执行 PluginInterface::activate()。这意味着：
- 环境变量如
COMPOSER_DISABLE_PLUGINS=1或COMPOSER_NO_PLUGINS=1效果等同于--no-plugins，但更隐蔽，容易在 CI 脚本中被遗漏 -
disabled-plugins配置只在 Composer ≥2.2 生效，且仅禁用指定插件，对未声明的插件无效 - 删
vendor/下插件目录或重命名，只能阻止 autoload，但composer install会立刻重新拉取并激活——除非你同时删掉composer.lock并跳过--lock - 注释
composer.json中的插件依赖后不运行composer update --lock，vendor/和composer.lock仍保留旧状态，插件照常运行
--no-plugins 的正确写法和常见错位
这个参数必须紧接在主命令之后、其他选项之前，否则会被忽略或报错：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- ✅ 正确：
composer install --no-plugins、composer update --no-plugins --with-dependencies - ❌ 错误：
composer install --with-dependencies --no-plugins（旧版 Composer 可能静默忽略） - ❌ 错误：
composer --no-plugins install（等价于composer --help） - ⚠️ 注意：如果项目用了 wrapper 脚本（如
bin/composer），需确认它没在内部硬编码插件相关 flag
禁用特定插件的三种实操路径
想只停掉某个插件（比如 hirak/prestissimo 或 phpstan/extension-installer），而不是全关：
- 改
composer.json："extra": {"disabled-plugins": ["hirak/prestissimo"]}，然后运行composer update --lock（Composer ≥2.2） - 临时重命名 vendor 目录：
mv vendor/hirak/prestissimo vendor/hirak/prestissimo.disabled，插件发现不了目录就跳过加载；调试完再改回来 - 查插件文档是否支持环境变量开关：比如某些插件响应
PHPSTAN_SKIP_EXTENSIONS=1或PRESTISSIMO_DISABLE=1，但不是所有插件都实现该逻辑
CI 环境里最容易漏掉的关键点
CI 构建脚本里每一条 composer 命令都该显式带上 --no-plugins，不能靠“默认没装插件”来假设安全：
- CI 镜像可能预装了全局插件（如
~/.composer/vendor/下的composer/installers） - 第三方
composer.lock文件可能引入不可信插件，--no-plugins是唯一能切断执行链的硬开关 -
composer diagnose在插件禁用时会提示 “plugins disabled”，但这只是状态反馈，不代表你已主动控制——它不会告诉你哪些插件本该被禁 - 别把
COMPOSER_NO_PLUGINS=1写进Dockerfile ENV或~/.bashrc，本地开发时容易意外失效，且难以追溯
