composer audit 报 high 不能直接 update，它仅比对 composer.lock 精确版本与 friendsofphp 数据库，不分析调用链、不触发更新，每条 high 或 critical 都需手动决策升级、替换或确认误报。
composer audit 报了 HIGH，但不能直接 update？
不能。composer audit 只是比对 composer.lock 中的精确版本和 FriendsOfPHP 安全数据库，它不分析调用链、不判断是否实际使用了漏洞代码、也不触发任何更新动作。你看到的每一条 HIGH 或 CRITICAL，都得手动决策——升级、替换、忽略，或确认误报。
常见误操作是：一看到审计报告就跑 composer update vendor/package，结果间接升级了其他包，引发兼容性问题或行为变更。真正该做的，是先锁定影响范围：
- 检查报告里的
affectedPath，确认该包是否被生产代码直接引用（比如vendor/symfony/http-foundation是否在路由或请求处理中被调用） - 查该漏洞的 CVE 描述，看触发条件（例如需启用
debug=true或特定扩展），你的运行环境是否满足 - 运行
composer outdated --direct，确认当前锁死版本是否有安全补丁版可用（如symfony/http-foundation5.4.32 有漏洞，但 5.4.33 已修复）
如何实现“静默热更新”？根本不存在
Composer 没有“静默热更新”机制——它不支持运行时替换已加载类、不提供 hot-swap 依赖的能力。所谓“热更新”，实际是指：在不停机前提下完成依赖升级并验证。这需要你主动构建流程，而不是依赖 Composer 自身功能。
关键约束条件必须明确：
-
composer install是幂等的，只按composer.lock安装，适合部署；composer update是非幂等的，会改写 lock 文件，绝不能在生产环境直接执行 - 真正的“静默”靠的是灰度发布 + 健康检查：先升级测试环境 → 跑回归测试套件 → 验证监控指标（HTTP 5xx、响应延迟、队列积压）→ 小流量切流 → 全量 rollout
- 如果项目用容器部署，更新方式是重建镜像：修改
composer.json或composer.lock→docker build→ 替换旧 Pod，而非在运行容器里执行composer update
回归测试该测什么？别只跑 PHPUnit
安全补丁升级后，回归测试不是为了证明“代码还能跑”，而是验证“没因版本跳变引入新问题”。重点不在覆盖率，而在风险路径。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
必须覆盖的场景：
- 所有涉及该漏洞包的业务主链路（例如升级
guzzlehttp/guzzle后，重放支付回调、Webhook 接收、第三方 API 调用） - 边界输入组合：特别是触发过漏洞的参数模式（如含特殊字符的 URL、超长 header、空 body POST）
- 异常处理分支：模拟网络超时、服务端返回 503、SSL 验证失败等，确认降级逻辑未被新版本破坏
- 性能基线对比：同一请求在旧/新版本下的内存占用、响应时间 P95，防止补丁引入性能 regress（常见于某些安全补丁增加校验开销）
CI 流水线里建议加一道硬检查：composer audit --no-dev --severity=high --severity=critical --format=json | jq 'length == 0'，确保 lock 文件更新后不再报高危漏洞。
为什么 CI 里总卡在 audit 或 update？三个硬门槛常被忽略
composer audit 在 CI 中失效，90% 是栽在这三件事上：
- 基础镜像自带 Composer 2.4.x ——
composer --version必须 ≥ 2.5.0，否则命令不存在；企业 CI 环境常禁用composer self-update，直接换官方composer:2.5镜像更省事 - 全局配置缺失 ——
composer config --global experimental.audit true必须执行，该配置写入~/.composer/auth.json，Docker 构建中容易漏掉这一行 -
composer.lock不可用 —— Git 未提交 lock 文件、CI 步骤跳过composer install、或用了--no-install参数，都会导致 audit 找不到输入源，直接静默退出（不是报错）
真正稳定的 CI 写法是：composer install --no-interaction --optimize-autoloader && composer audit --no-dev --severity=high --severity=critical --fail-on-security-violations，中间不能断开，且必须确保 lock 文件存在并校验通过。
