构建基于Composer中文元数据的项目复杂度监控与依赖热度分析

先说几个关于 Composer 依赖管理的实用点，特别是在做项目复杂度监控和依赖热度分析时，有些细节值得深挖。composer show 的几个子命令，用好了能省不少排查时间。

composer show --tree 输出里哪些缩进是真实依赖层级

那个缩进不是随手敲的空格，它对应的是直接 require 声明的嵌套深度。简单来说，每往右缩进一级，就代表这个包在它的 composer.json 里明确写了 require——比如 guzzlehttp/guzzle 下面缩进出现了 psr/http-client，那就说明 Guzzle 官方的 composer.json 里确实有这行 require 声明，不是巧合。

实际使用中，有几个容易看错的地方：

• 同一个包出现在不同缩进层级（比如 symfony/polyfill-php80 既在 2 级也能在 6 级看到）——这意味着它被多个上游包分别引入，而且版本可能还不一致，需要留意。
• 看到 [dev-main] 的标记，但你实际要求的是 "^6.0"——这并不是你的约束失效了，而是依赖链中某个上游包锁死了版本，把你的要求给“降级”了。
• 还有一个常被忽略的点：--tree 只列包名，不显示具体版本号。想确认装了哪个版本，得单独跑 composer show guzzlehttp/guzzle 才能看到。

怎么用 composer show --who 精准定位“谁在用这个包”

composer depends 在 2.4 版本之后默认就是关闭的，而且它对 provide、replace 以及 path 仓库的支持很差，容易遗漏。真正可靠的是 composer show --who。

这个命令的逻辑很简单：只扫描所有已安装包的 require 和 require-dev 字段，然后返回直接声明者的列表，不追踪间接提供关系。

• composer show --who psr/log 会列出所有直接 require psr/log 的包，比如 monolog/monolog、slim/slim 这些。
• 加个 --no-dev 参数，比如 composer show --who --no-dev monolog/monolog，就可以过滤掉开发依赖，只看生产链路上的引用情况。
• 如果结果为空，不代表没人用——可能是通过虚拟包间接提供的，比如 psr/log-implementation。这时候还是得回去看 composer show --tree . 的全局结构才能搞清楚。

composer --profile 抓不到的隐藏性能杀手

composer install --profile 确实能精准输出 [2.1s] Resolving dependencies 这样的耗时数据，但它不会告诉你 Xdebug、open_basedir 或者 autoload 冲突这些因素带来的拖慢。

这些因素不会出现在 --profile 的日志里，却能让整体流程慢上好几倍：

• 运行 composer diagnose 时，如果提示 The xdebug extension is loaded，而你没主动开调试模式，那么 Xdebug 就在后台拖慢所有 PHP 操作，包括依赖解析中的数组合并。等跑完你会发现，时间全花在看不见的地方。
• open_basedir 启用后，Composer 会自动禁用 opcache 预加载。autoload 阶段的性能可能下降 3 到 5 倍，但 Resolving dependencies 那一行的数值完全不变——这也是为什么很多人排查半天找不到原因。
• vendor/ 目录权限异常或者磁盘 I/O 延迟高，会导致 Writing lock file 耗时飙升。但 --profile 只会告诉你“写文件花了 3 秒”，不会告诉你底层是文件系统问题。

中文元数据热度分析的关键陷阱

所谓“中文元数据”，指的是包名、描述、作者名里包含中文字符的 Composer 包。这类包极少出现在主流生态中，绝大多数是私有包或本地 path 仓库。分析它们的“热度”，靠 composer show --tree 或者第三方统计接口都不靠谱。

真正可操作的判断依据只有三个：

• 这个包是否出现在 composer.lock 的 packages 或 packages-dev 列表中——只要存在，就说明它曾经被解析过。
• 是否被至少一个其他包在 require 字段直接引用——用 composer show --who 验证即可。
• 它的 autoload 命名空间是否被主项目或其他包的 PSR-4 映射覆盖——否则就算装上了也加载不到。

别信什么“下载量”或“star 数”，私有包根本没有这些指标。也别依赖 composer-unused 的扫描结果，它识别不了中文命名空间下的类引用。最稳妥的方式：把这个包删掉，跑一遍全量测试，看看哪块逻辑崩了——这才是真正能说明“有没有人在用”的证据。