真正可追溯的依赖变更藏在 composer.json 修改与对应 composer.lock 差异的组合中；重点检查 name、version、dist.shasum 字段变化，content-hash 变则依赖图已变，platform 不一致需先对齐。
直接看 composer.lock 的 Git 历史没用——它不记录“为什么变”，只存结果；真正可追溯的变更线索，藏在 composer.json 修改 + 对应 composer.lock 差异的组合里。
怎么从 PR 里快速定位真实依赖变动
别扫 composer.lock 全文。重点抓三类行："name"、"version"、"dist": {"shasum"。这些字段变了，才代表包本身有实质升级或降级。
- 用
git diff --no-color HEAD~1 composer.lock | grep -E '^\+ {4}"(name|version|dist)' | head -20快速筛出新增/改版包 - 如果
content-hash字段变了，说明依赖图结构已不同；没变，大概率只是 lock 文件重生成（比如换了 PHP 版本或 Composer 小版本） -
"type": "git"或"reference": "abc123"出现在新增包里，要立刻确认是否指向不稳定分支或临时 commit - 同一包名出现多个版本（如
symfony/console同时有6.4.5和7.0.0），说明存在冲突，Composer 已做降级处理，需查composer show --tree symfony/console
如何比对两个环境（如本地 vs 生产）的依赖一致性
最可靠的方式是比对 composer.lock 文件本身，而不是跑 composer show ——后者受 vendor 状态、平台配置、缓存影响，结果不可信。
- 从生产环境拿到
composer.lock，重命名为composer.lock.prod - 本地先执行
composer update --lock，确保 lock 是最新解析结果（不是缓存残留） - 用
diff -u composer.lock composer.lock.prod | grep "^\([+-]\|\"name\"\|\"version\"\)"聚焦关键字段差异 - 若两边
composer.json中"platform"配置不一致（如 PHP 版本声明不同），lock 文件会天然不一致，必须先对齐再比 - 发现版本一致但行为异常？运行
composer show --tree vendor/package-name分别检查本地和生产中该包的上游依赖路径是否相同
怎样用命令行快速提取“我亲手写的依赖”变化
composer show --root-reqs 是唯一能准确反映 composer.json 中 require 和 require-dev 实际生效版本的命令，它跳过所有传递依赖，只输出你明确声明的包。
- 执行
composer show --root-reqs --format=json > root-deps.json，再用jq或diff比对前后 - 注意：它不显示你在
composer.json里写的约束（如"^3.0"），只显示最终装上的版本（如"3.5.2"）——这是好事，因为约束没生效时，版本才是真相 - 不要和
--tree一起用，两者互斥；也别指望它标出 dev 分支风险，它照单全收"dev-main"，得靠人工判断 - CI 中建议用它生成变更摘要：如果
composer.json没动，但composer show --root-reqs输出变了，说明有人偷偷跑了composer update
依赖变更最难防的不是大版本跳跃，而是某个 polyfill 包的补丁更新悄悄改了时区处理逻辑，或者一个 dev-only 包意外混进生产 lock 里——这些都藏在 composer.lock 的字段细节里，而不是 composer.json 的增删行中。
