使用Composer生成项目依赖关系报告的方法

如何利用Composer生成项目的依赖关系报告

说到分析项目依赖，composer show --tree 无疑是那条最直接的路径。但如果你真把它当成“终极报告”，那可就踩坑了。实际用起来，输出过长、格式混乱、开发依赖被忽略，都是家常便饭，一不小心就会误判项目的真实依赖结构。

用 composer show --tree 快速查看层级依赖

这个命令会递归展开所有已安装的包及其子依赖，用缩进来清晰地表示依赖层级。不过，这里有个关键细节：它默认只显示生产环境依赖，也就是 require 部分里的包，那些在 require-dev 里的测试或构建工具，比如 phpunit、phpstan，连同它们引发的整条依赖链，都会被“隐藏”起来。

• 想看全貌？必须加上 --dev 参数。
• 输出结果动不动就占满好几屏？建议配合 less 分页查看，或者干脆重定向到文件：composer show --tree --dev | less。
• 还有一点必须注意：某些包会通过 replace 或 conflict 声明来干预依赖解析过程，而 --tree 展示的只是最终解析结果，并不会体现背后这些复杂的逻辑关系。

导出为 JSON 便于程序化分析

想要用程序处理依赖数据？composer show --format=json 输出的只是一个扁平列表，没有层级信息。而能反映依赖图谱的 composer depends --tree，其视角又比较逆向。遗憾的是，Composer 原生命令并不支持导出完整的树形 JSON。那怎么办呢？别急，有替代方案：

• 脚本解析法：先用 composer show --tree 输出，再写个自定义脚本解析缩进（通常每两个空格代表一层）。这个方法适合进行简单的依赖审计。
• 第三方工具法：借助更专业的工具，比如安装 edsonmedina/composer-dependency-graph 后，运行 composer dependency-graph --format=dot，就能生成可供 Graphviz 渲染的可视化图谱。
• CI/CD 集成法：如果需要在持续集成中自动检查，推荐先用 composer show --direct 筛选出项目显式声明的包，然后对每个包执行 composer show vendor/package --tree 来拼接完整视图。这样可以有效避免漏掉那些条件性加载的依赖。

警惕 provide 和 replace 导致的“隐形依赖”

这才是依赖分析里真正的“暗礁”。举个例子，symfony/polyfill-php80 这个包，会通过 provide 声明自己“提供了” PHP 8.0 的某些特性。这样一来，其他包可能直接依赖这些特性，而不是依赖具体的 polyfill 包。此时，composer show --tree 根本不会显示它，但它却实实在在地参与了依赖解析。

• 想用 composer why-not php:8.0 这类命令来排查？往往行不通，因为这并非版本冲突，而是一种“能力模拟”。
• 可靠的检查方法是：直接去查看 composer.lock 文件里的 packages 和 packages-dev 字段，搜索其中的 provide 键，才能发现这类间接关联。
• 带来的实际风险是：升级时如果移除了某个 polyfill，你必须人工确认是否有包实际调用了它所模拟的函数，否则运行时很可能冷不丁地报出 Call to undefined function 错误。

最后必须强调：依赖报告从来都不是一份静态快照。Composer 的自动加载规则、平台配置（比如 platform 设置）、甚至是一些优化插件（如 hirak/prestissimo），都可能改变最终的加载行为。所以，生成报告只是第一步，务必在目标环境中验证 vendor/autoload.php 是否真的能加载到所有关键类，这才是确保项目稳健运行的最终防线。