Composer中文环境下的依赖图谱可视化分析与冗余包清理工具

先说几个核心判断：Composer 在中文环境下的坑，其实主要集中在字符编码、依赖图可视化和自动加载这三个方面。很多开发者遇到问题后第一反应是“工具不行”，但仔细拆解下来，你会发现每个问题都有明确的根因和对应的解决路径。

为什么 composer show --tree 在中文路径下会乱码或崩溃

根本问题出在 Composer 默认使用的系统 locale 编码上。Windows 中文版默认是 GBK，而 composer show --tree 内部调用的 Symfony Console 组件在输出包含中文的包信息（比如注释、作者名）时，没有做编码强制转换，直接按 UTF-8 去解码字节流，结果就是乱码，严重时直接 panic。

别急，这里有几种解决思路：

• 临时修复：Windows 用户在终端里先执行 chcp 65001，把编码切到 UTF-8，再运行 composer show --tree。这个方法最直接，但每次都要手动操作。
• 长期方案：在项目根目录创建 COMPOSER_HOME/config.json，加入 "process-timeout": 300，并确保 PHP 启动时加载了 mbstring 扩展——很多中文包依赖它做字符串截断。
• 绕过法：改用 composer show --format=json | jq '.'，前提是你得先装好 jq。JSON 输出天然就是 UTF-8 安全的，之后再用 Python 脚本解析生成树状结构，基本不会出问题。

用 graphviz 可视化 composer dependents 结果时节点重叠严重

这里有个常见的认知误区：很多人以为直接把 composer dependents vendor/package 的扁平列表丢给 dot 就能自动生成漂亮的依赖图。结果呢？所有下游包都作为一级子节点平铺，Graphviz 的自动布局算法根本扛不住，节点必然堆叠在一起。

正确的做法是：

• 先用 composer show --tree vendor/package 提取完整的依赖链条，然后用 Python 脚本递归解析缩进层级，生成带 rank/same 属性的 .dot 文件。
• 有几个关键参数必须加上：rankdir=LR（横向布局更适合深依赖）、nodesep=20（节点最小间距）、concentrate=true（合并平行边）。
• 中文节点名记得用双引号括起来，并显式声明字体：node [fontname="Microsoft YaHei", fontsize=10]。否则 Graphviz 用默认的无衬线字体渲染中文，会糊成一团。

composer-unused 误报“未使用包”却漏掉真实冗余包

composer-unused 的工作原理是静态扫描 use 语句和函数调用，但有三类情况它完全无能为力：动态类名（比如 new $class）、配置驱动加载（比如 Lara vel 的 config/app.php 里注册的 service provider），以及通过反射访问的类（比如 Doctrine 的实体映射）。

针对这些问题，建议的做法是：

• 运行前先执行 composer dump-autoload -o，避免因 autoloader 缓存导致类存在性判断错误。
• 配合 phpstan 做反向分析：用 phpstan analyse --level=0 --no-progress --error-format=raw src/ | grep "Class.*not found"，定位那些被引用但未声明依赖的包。
• 人工核验重点目录：config/ 下的所有 PHP 配置文件、database/migrations/ 中的 Schema 调用、tests/ 里 mock 的第三方类——这些地方的依赖，composer-unused 一个都抓不到。

清理 vendor/ 后 CI 环境编译失败，提示 Class not found

这个问题的根因不在 Composer 本身，而在于某些包（比如 symfony/flex、lara vel/pint）会在 post-autoload-dump 阶段向 vendor/composer/autoload_psr4.php 注入运行时逻辑。如果你用脚本暴力删除了那些未被 composer-unused 标记、但实际被构建工具调用的包，autoloader 就会残留无效映射，PHP 加载时找不到类，却仍然尝试 include。

怎么避免？

• 永远不要手动删除 vendor/ 的子目录；清理后必须立刻执行 composer dump-autoload -o 强制重建映射表。
• 在 CI 脚本里加一道防护：在 composer install 后插入校验步骤——php -r "include 'vendor/autoload.php'; echo class_exists('SomeUsedClass') ? 'OK' : 'FAIL';"。
• 对于 Flex 这类包，检查 composer.lock 中是否残留了其插件条目。如果有，运行 composer remove --dev symfony/flex 彻底卸载，而不是仅仅删除 vendor。

真正麻烦的是那些只在构建时起作用、运行时不加载的包——它们不会出现在任何 use 或 new 中，但删掉就会让 php artisan optimize:clear 或 npm run build 失败。这种问题没有捷径，只能靠反复注释 require-dev 区块，配合观察 CI 日志来定位。