先说几个核心判断：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 日志来定位。