Composer 2.9+ 默认启用自动安全拦截，执行 composer update 或 install 时检测到已知漏洞（如 CVE-2024-12345）即中止操作并提示修复命令；该机制基于官方安全通告数据库，无需插件，但仅作用于正安装/更新的版本。
Composer安全更新不能靠“自动升最新版”来实现，必须分层控制：用精确约束锁死基础版本、用composer audit主动扫描、靠allow-plugins掐断恶意执行入口。
怎么让 Composer 自动拦截不安全版本
Composer 2.9+ 默认启用安全拦截，执行 composer update 或 composer install 时，一旦检测到目标包含已知漏洞（如 CVE-2024-12345），会直接中止并提示：
Found 1 security vulnerability advisory affecting 1 package: 1. abc/xyz (version: 2.5.0) - CVE-2024-12345 [High severity] To update to a secure version, run: composer update abc/xyz
这个机制基于官方安全通告数据库，无需额外安装插件。但要注意：
- 它只检查你正要安装/更新的版本，不会回扫已安装但未改动的旧包——所以得定期手动运行
composer audit - 默认只拦截高危（High/Critical）问题，若想连中低危也拦，需配置：
composer config audit.block-insecure true - 被标记为 abandoned 的包默认不拦，如需拦截，加：
composer config audit.block-abandoned true
如何只修复漏洞而不引入新功能或破坏兼容性
安全更新的核心是「最小变更」：只升补丁版，不动小版本或主版本。错误做法是写 "monolog/monolog": "*" 或 "^2.0"，这会让 composer update 直接跳到 2.10.0，可能带入未测试的改动。
正确姿势是用波浪符 + 补丁锁定：
-
"monolog/monolog": "~2.8.0"→ 允许升到2.8.9，但绝不会到2.9.0 - 紧急修复已知 CVE 时，用精确版本：
"guzzlehttp/guzzle": "7.5.1"（前提是该版本已确认修复） - 升级后立刻跑
composer audit --no-dev验证是否真清除了漏洞
别依赖 --patch-only 参数——它只对当前约束范围内的补丁生效，如果约束本身太宽（比如 ^2.0），它仍可能升到 2.10.0。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
为什么 allow-plugins 是安全更新的前提
插件能在 composer install 阶段执行任意 PHP 代码，而很多安全漏洞正是通过恶意插件注入的。Composer 2.2+ 强制要求显式授权，否则插件直接被跳过。
典型安全配置长这样：
{
"config": {
"allow-plugins": {
"composer/installers": true,
"phpunit/phpunit": true,
"*": false
}
}
}
关键点：
-
"*": false是底线，必须存在；否则等于没设防 - 不要写
"roave/security-advisories": true——它不是插件，是 dev 依赖，靠composer require --dev roave/security-advisories安装即可 - CI 环境中建议加
--no-plugins参数强制禁用所有插件，避免配置被绕过
哪些操作看似安全实则埋雷
真实项目里，最常被忽略的其实是「非代码变更」引发的安全滑坡：
- 改了
composer.json里的description或空格，却不跑composer update --lock-only→composer.lock哈希失效，下次install可能拉错版本 - PHP 升级后没同步
config.platform.php→ Composer 仍按旧 PHP 版本解析依赖，可能装上不兼容的扩展 - 在 CI 脚本里写
composer update不带参数 → 某天某个 dev 依赖（如phpstan/phpstan）大版本更新，导致静态分析全挂，阻塞发布 - 把
composer.lock当缓存删掉重生成 → 丢失平台约束、dist shasum、甚至安装时的 PHP 扩展检查结果
安全更新不是一次性的动作，而是每次 composer.json 变更、每次 PHP 环境变动、每次上线前都必须校验的链路。漏掉任意一环，前面所有约束都可能失效。
