--no-plugins 是安全隔离手段而非可选优化，必须用于绕过插件执行链、防止任意代码执行、跳过失效签名校验等场景，常见于CI/CD防恶意脚本、白名单缺失时强制安装、调试污染vendor、生产环境防插件注入。
用 --no-plugins 不是为了“省事”，而是当你要绕过插件执行链、防止任意代码执行或跳过签名校验失效的依赖脚本时才必须加。
哪些场景下必须加 --no-plugins
这个参数不是可选优化项，而是安全隔离手段。常见触发点包括：
- CI/CD 流水线中执行
composer install --no-dev --prefer-dist但发现某包的post-install-cmd脚本偷偷调用了curl或写入临时文件 → 加--no-plugins强制跳过所有插件生命周期钩子 - 项目用了 Laravel Pint 或 Symfony Flex 这类需白名单的插件，但
composer.json里没配"allow-plugins"，或配成了{"*": true}→ Composer 2.5+ 会拒绝加载，此时加--no-plugins可让安装继续，但要立刻补上白名单配置 - 你正在调试一个疑似被污染的
vendor/，想确认是否插件注入了异常逻辑 →--no-plugins能帮你排除插件侧干扰，纯看 autoload 和 class 加载是否正常 - 生产部署脚本里写了
composer install却没加任何限制 → 一旦某天某个依赖更新了带恶意PluginInterface实现的版本，就可能在安装时执行任意 PHP 代码
--no-plugins 和 allow-plugins 的关系
Composer 2.2+ 引入插件白名单机制后，--no-plugins 实际是“覆盖白名单”的最终开关。它不关心你配了什么，直接禁用全部插件加载逻辑。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 如果你已全局设了
composer config --global allow-plugins false，再加--no-plugins没额外效果 - 但若只在项目级配了
"allow-plugins": {"phpstan/extension-installer": true}，而某次 install 时想临时禁掉它（比如怀疑该插件触发了内存溢出），就必须显式加--no-plugins -
--no-plugins不影响autoload自动加载，也不跳过scripts（除非你同时加--no-scripts）
容易被忽略的副作用
加了 --no-plugins 后，某些看似“基础”的功能会静默失效：
- Laravel 的
php artisan vendor:publish依赖laravel/framework的插件注册资源发布逻辑 → 若用--no-plugins安装，后续 publish 命令可能找不到配置路径 - Symfony Flex 的
recipes下载、自动配置注入全部跳过 →config/packages/下不会生成默认 YAML 文件 - 某些私有仓库认证插件（如
composer-registry-auth-plugin）不工作 → 若源需要 token 认证，--no-plugins会导致 401 报错 - PHPStan / Psalm 的自动扩展安装失败 → 因为它们靠插件把 bin 脚本 symlink 到
vendor/bin/
真正关键的不是“要不要加”，而是“加完之后你是否清楚哪些能力被砍掉了”。很多线上故障源于开发者加了 --no-plugins 应对一次报错，却忘了它会让整个插件生态失效——尤其在框架深度集成插件的项目里。
