composer镜像对resolving dependencies和show --tree完全无效，因前者为本地sat求解无网络请求，后者纯读内存；卡顿主因是php约束过宽、xdebug启用、私有源超时或composer.lock缺失。
镜像对Resolving dependencies阶段完全无效
Composer中文镜像只加速Downloading packages，对Resolving dependencies阶段毫无影响。这个阶段是本地 SAT 求解器穷举版本组合的过程，不发任何网络请求，也不读取镜像配置。你看到的卡顿持续几十秒甚至几分钟，99% 是约束太松、minimum-stability设为dev、composer.lock缺失或私有源超时导致的，不是网速问题。
为什么composer show --tree变慢和镜像无关
composer show --tree读的是vendor/composer/installed.json，纯内存操作，不走网络。1000+ 包的项目，这个命令本身就能吃掉 300MB+ 内存、耗时数秒——它在递归构建依赖树结构，字符串拼接和嵌套输出开销大。镜像再快也帮不上忙。
- 加
--short（或-s）可折叠重复路径，显著减少内存占用和渲染时间 - CI 中避免无条件执行，改用
jq '.packages | length' vendor/composer/installed.json查包数量，轻量又快 - 终端宽度太窄会导致缩进错位，建议搭配
less -S横向滚动查看
真正影响大型依赖树遍历速度的关键点
依赖树“遍历”本身不发生在镜像侧，但以下几项会放大解析与展示阶段的延迟：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
php约束过宽，比如"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"，让求解器尝试数百种 PHP + 包组合 - 启用了
Xdebug：拖慢 SAT 求解器 3–5 倍，临时禁用要用php -d zend_extension= -d xdebug.mode=off composer install -
repositories里写了已下线的私有源，Composer 会逐个 timeout 后才 fallback，白白消耗时间 -
composer.lock被删或未提交，install退化为全量update，触发重解析
验证镜像是否真生效，别被假象骗了
换源后仍卡，先看-vvv日志里最后几行有没有mirrors.aliyun.com或mirrors.huaweicloud.com字样。没有？说明镜像根本没生效，常见硬伤：
-
repo.packagist写成repos.packagist（多一个s），静默失效 - URL 缺末尾
/，比如https://mirrors.aliyun.com/composer→ 拼出.../composer/packages.json404，然后 fallback 到官方源 - 项目级
repositories字段存在（哪怕为空对象{}），会屏蔽全局镜像 - 没加
-g参数，只改了当前目录的composer.json，换个项目就失效
真正卡在依赖解析环节时，优化镜像配置只是徒劳；把php约束收紧、关掉Xdebug、清理缓存、校验lock文件，才是见效最快的路。
