必须审查 composer.lock 而非仅 composer.json，因其记录隐式依赖变更，如 psr/log 从 2.0.0 升 3.0.0 可能引发 BC break；需重点检查 packages 变更、content-hash、platform 及 dist.shasum。
Code review 时只看 composer.json 的增删改，大概率漏掉关键风险——真正影响运行时行为的，往往是 composer.lock 中隐式升级的依赖树。
为什么不能只 diff composer.json
开发者常以为改了 require 才算“动了依赖”，但 composer update（尤其没锁版本号时）会连带更新整棵子依赖树，而这些变更全记录在 composer.lock 里。比如：monolog/monolog 从 2.9.1 升到 2.9.2，看似小版本，却可能因上游依赖 psr/log 从 2.0.0 变为 3.0.0，触发 BC break——这种变化在 composer.json 里完全不体现。
常见错误现象：
• PR 里 composer.json 没动，composer.lock 却有几百行变更，reviewer 直接跳过
• composer.json 新增一个包，但 lock 文件里实际引入了 5 个新子依赖，其中某个含已知 CVE
- 必须把
composer.lock当作「可执行清单」来审，而非「自动生成文件」 - 重点关注
packages和packages-dev数组下新增、删除、版本号变动的条目 - 如果
lock有变更但json没对应操作，要追问：是手动update？还是 CI 自动刷新？
怎么快速定位 lock 文件里的高风险变更
别逐行扫 composer.lock。用 git diff 配合结构化查看更高效：
git diff --no-color HEAD~1 composer.lock | grep -E '^\+ {4}"(name|version|source)'
这条命令能筛出新增/修改的包名、版本、源类型（如 "type": "git" 比 "type": "package" 更需警惕）。使用场景：
• 发现 "version": "dev-main" 或 "reference": "abc123" → 指向不稳定分支或特定 commit，需确认是否必要
• 同一包出现多个版本（如 symfony/event-dispatcher 同时存在 6.3.2 和 7.0.0）→ 暗示依赖冲突，Composer 已降级处理
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 检查
content-hash字段是否改变：变了说明依赖图确实不同，不变则大概率是无害的 lock 重生成 - 留意
platform区块（PHP/扩展版本声明），它被修改可能意味着环境兼容性收紧 - 若项目用
composer install --no-dev上线，但lock里packages-dev大量变动，通常可忽略；反之则要严查
review 时必须核对的 3 类 json 配置陷阱
composer.json 表面简单，但几个字段写错会导致 lock 文件行为不可控：
-
"minimum-stability": "dev"或"prefer-stable": false→ 允许安装dev-分支，CI 构建结果可能每天都不一样，必须禁用或加注释说明理由 - 版本约束写成
"^1.2"而非"^1.2.0"→ Composer 会按语义化规则解释为>=1.2.0 ，但人容易误读；建议统一补零，降低歧义 -
repositories区块新增私有源或packagist.org镜像 → 要确认该源可信，且镜像同步延迟是否可接受（例如某安全补丁发布后，镜像滞后 2 小时）
参数差异直接影响 lock 稳定性："require": {"foo/bar": "1.2.*"} 比 "^1.2" 更危险，前者允许 1.2.99，后者止步于 1.2.x 最高兼容版。
自动化辅助：用什么工具补人工 review
人工盯 lock 文件易疲劳，推荐两个轻量级检查点：
- CI 中加一步：
composer validate --strict→ 检查 json 格式、字段合法性（如license是否为空） - 用
composer show --outdated --direct对比 base 分支和当前分支的直接依赖版本差（需在 checkout 后运行） - 对高危包做白名单检查：比如项目禁止使用
guzzlehttp/guzzle，可用 shell 脚本提取 lock 中版本号比对
性能影响提醒：频繁 composer update 生成的 lock 文件体积会膨胀（尤其含大量 dev 依赖），review 时若发现 lock 增长超 50KB，先确认是否误提交了 vendor/ 或冗余配置。
最常被忽略的是：lock 文件里 "dist" 下的 "shasum" 变了但版本号没变——这代表同一版本的包内容被重新打包（如维护者撤回恶意 patch 后重发），必须人工确认来源是否可信。
