镜像只加速下载，不解决依赖解析卡顿；根本原因是本地sat求解器穷举版本组合，受宽松约束、xdebug启用、php版本不匹配等影响，与网络无关。
Composer 镜像本身不解决依赖冲突，它只加速包下载；依赖分析慢的根本原因，是 composer update 在本地执行完整依赖求解（SAT 求解），镜像再快也绕不开这一步。
为什么换镜像后 dependency resolution 还是卡住？
镜像只替换 packagist.org 的下载源（如把 https://packagist.org/packages.json 指向国内节点），但 composer install 或 composer update 的依赖解析逻辑完全在本地运行，涉及版本约束检查、回溯尝试、冲突路径剪枝——这些 CPU 密集型操作不受网络影响。
常见误判现象：
- 终端长时间停在
Resolving dependencies...且无网络请求（htop显示单核 100%） - 切换镜像前后耗时几乎一致
-
composer why-not vendor/package:version响应快，但update卡死
真正提速依赖分析的三个实操动作
聚焦本地求解过程本身，而非网络：
- 用
composer update --dry-run --verbose观察卡在哪条约束上（输出里会逐条打印正在尝试的版本组合） - 临时删掉
composer.lock后运行composer update --prefer-lowest，可快速暴露宽松约束引发的爆炸式组合 - 对大型项目，加
--with-dependencies并配合--no-install，跳过下载和安装，纯做解析验证
注意：composer config repo.packagist composer https://mirrors.aliyun.com/composer/ 这类镜像配置，只影响后续 install 或 update 中的下载阶段，不影响解析阶段的算法复杂度。
哪些场景下镜像确实能“感觉更快”？
当问题本质是网络或元数据加载慢时，镜像才起效：
- 首次运行
composer install且composer.lock里含大量未缓存包（此时 90% 时间花在下载.zip或git clone） -
composer show查某个包时反复超时（因需从 Packagist API 拉取元数据） - CI 环境中频繁
composer clear-cache && composer install（镜像减少 DNS 解析失败和 TLS 握手抖动）
验证方法：开两个终端，一个跑 strace -e trace=connect,sendto,recvfrom composer update --no-install，另一个看是否大量 connect 调用；如果几乎没有，说明瓶颈根本不在网络。
依赖冲突的本质是语义约束的不可满足性，不是带宽问题。越想靠换镜像“蒙混过关”，越容易忽略 conflict 规则写得太宽、require-dev 引入了不该上线的包、或者 PHP 版本约束和扩展要求存在隐式矛盾这些真正该修的地方。
