中文镜像不评估依赖复杂度，仅加速下载；真正影响复杂度的是本地求解、锁文件状态和可视化工具链。resolving dependencies卡顿源于本地sat求解器穷举，与镜像无关。
中文镜像本身不评估依赖复杂度，它只加速下载；真正影响复杂度分析的是本地求解过程、锁文件状态和可视化工具链。换镜像后 dependency resolution 还卡在 Resolving dependencies，说明瓶颈根本不在网络。
为什么镜像对依赖复杂度分析毫无帮助
Composer 中文镜像（如阿里云、华为云）仅替换 packagist.org 的元数据与包下载地址，所有依赖图解析（SAT 求解）、版本回溯、冲突剪枝都发生在本地 CPU 上。你看到的 Resolving dependencies 卡顿，htop 显示单核 100%，就是 SAT 求解器在穷举组合——镜像再快也绕不开这一步。
常见误判场景：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 终端停在
Resolving dependencies且无网络请求（strace -e trace=connect composer update --no-install几乎无输出） - 切换镜像前后耗时一致，但
composer why-not guzzlehttp/guzzle:7.9.0响应飞快 -
composer show -t输出混乱、缩进错位，误以为是“镜像没生效”，其实是树状输出本身不反映真实拓扑
真正能评估依赖复杂度的三个命令组合
复杂度体现在间接依赖数量、层级深度、环形结构和未使用包比例。必须绕过镜像干扰，直击锁文件和已安装状态：
-
composer show --tree --no-dev：过滤掉require-dev干扰项，观察主干依赖层级；若超过 8 层或某包反复出现（如myorg/core → myorg/utils → myorg/core），就是高复杂度信号 -
composer depends --tree vendor/package：查某个基础组件（如psr/log或symfony/polyfill）被多少路径引用；返回结果 >5 条且跨多个业务域，说明耦合过深 -
composer-unused --format=json：静态扫描代码中实际use或new的类，对比composer.json中require列表；差值越大，冗余越严重
可视化依赖图才是复杂度的“显微镜”
文本命令只能看局部，而图能暴露全局结构问题：
- 用
composer require --dev kylekatarnls/composer-dependency-graph安装轻量 HTML 图工具，运行./vendor/bin/composer-dependency-graph --filter="your-vendor/*"聚焦私有包 - 图中出现闭环箭头（A→B→A）、密集中心节点（一个包被 >20 个其他包指向）、或大量孤立子图（如测试工具链自成一派但无主干引用），都是复杂度超标的直观证据
- 注意箭头方向是「被依赖」：A→B 表示 B require A；别按中文语序反读，否则会把依赖关系完全搞反
最易被忽略的点：所有分析都依赖 composer.lock 是最新快照。刚改完 composer.json 就跑 composer-dependency-graph，图里不会出现新包——必须先 composer update --no-install 同步锁文件，再生成图。
