composer 安全必须强制 ci/cd 执行 composer audit --no-dev --strict、显式配置 allow-plugins 白名单、提交并校验 composer.lock、启用 secure-http 和 ssl-verify，并在每次 update 后人工复核依赖安全性。
composer audit 必须进 CI/CD 且带 --strict
本地跑 composer audit 没用，漏洞照样上线。CI/CD 流水线里必须加，而且得带 --no-dev --strict，否则构建不失败，等于没设防。
-
--no-dev：排除开发依赖干扰（比如过时的phpunit），只审生产实际加载的包 -
--strict：让有中高危漏洞时直接退出，不输出报告就完事 - CI 脚本里写成：
composer audit --no-dev --strict || exit 1 - 漏掉这步，
composer.lock更新后新引入的漏洞就没人知道
allow-plugins 必须显式白名单，不能留空或配 "*": true
Composer 2.2+ 默认禁用所有插件，但很多人配了 "*": true 或干脆不配，等于把插件执行权全放开。
-
"*": true是最危险写法——任意插件都能执行任意 shell 命令 - 正确做法是只开真正需要的，例如：
"composer/installers": true、"phpstan/extension-installer": true - 项目不用插件？直接写
"*": false，一劳永逸 - 检查当前配置运行：
composer config allow-plugins
必须提交 composer.lock，且 CI 开头校验存在
不提交 composer.lock，composer install 就退化为 update，每次拉的版本都不一样，线上行为不可控。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 现象：本地正常，CI 报错，线上类找不到、方法不存在
- 根本原因：没 lock 文件，Composer 自动选最新兼容版，可能含 breaking change
- CI 脚本开头加一句：
test -f composer.lock || (echo "ERROR: composer.lock missing" >&2; exit 1) - 别信
.gitignore里“临时注释掉”，团队有人漏提，整条链就断
secure-http 和 ssl-verify 绝对不要关
关掉 secure-http 或 ssl-verify，等于放弃传输层安全，中间人可篡改包元数据甚至下发恶意 zip。
-
composer config secure-http false→ 允许 HTTP 仓库，已用于真实投毒攻击 -
composer config ssl-verify false→ 跳过证书验证，攻击者伪造packagist.org域名就能发包 - 内网私仓确需 HTTP？用
repositories单独配，不碰全局secure-http - 验证是否生效：
composer diagnose输出里必须有secure-http: OK
最常被跳过的不是某条命令，而是每次 composer update 后的二次确认：新包有没有废弃、签名是否仍有效、allow-plugins 白名单是否还覆盖得住。安全配置不是设一次就完事，是每次依赖变动时都要重走一遍检查链。
