镜像配置仅影响元数据可见性，不改变依赖解析逻辑；resolving dependencies 卡住主因是 provider 文件缺失或404导致回退下载全量包；项目级 repositories 会覆盖全局镜像配置。
镜像配置本身不改变 Composer 的依赖树解析逻辑，只决定“能看见哪些版本”——你写 ^2.8.0，但镜像没同步 v2.9.0，那它就根本不会出现在求解器的候选列表里，不是解析错了，是压根没看到。
为什么换镜像后 composer update 还卡在 Resolving dependencies
这不是网络变快就能解决的问题。Resolving dependencies 阶段完全在本地运行 SAT 求解器，镜像只影响元数据下载（即 provider-*.json 文件是否可得、是否最新），不影响求解过程本身。
- 卡住的典型表现：CPU 拉满、终端停在
Resolving dependencies超 30 秒、日志反复刷Trying: monolog/monolog:v2.12.0 - 真正瓶颈常是 provider 文件缺失或返回 404 —— Composer 会 fallback 到下载全量
packages.json（20+ MB），触发内存暴涨和解析退化 - 执行
curl -I https://mirrors.aliyun.com/composer/p/provider-laravel~10.0.json看是否返回HTTP/2 200，对比官方源确认同步状态 - 若镜像返回 404，别等它“自动恢复”，临时切回官方源验证：
composer config -g repo.packagist composer https://packagist.org，再跑composer update --dry-run -v
composer show -a 和 composer why-not 输出为什么和预期不符
这两个命令的结果直接受当前镜像所见元数据支配，不是“错”，而是“所见即所得”。你看到的版本列表、冲突提示，都只是镜像缓存那一刻的快照。
-
composer show -a vendor/package列出的版本，是镜像provider-*.json里实际存在的，不是 Packagist 全量；新发布的v3.5.1若未同步，它就不会出现 -
composer why-not vendor/package:^3.0必须用完整版本号，比如vendor/package:3.0.0—— 范围表达式（^、~）不被识别，输出为空不是镜像问题，是输入格式不对 - 输出为空还可能因为：该版本根本不在当前镜像元数据中注册；
conflict字段被小众镜像裁剪；或本地缓存过期，需先composer clear-cache再删~/.composer/cache/repo/https---mirrors.aliyun.com-composer - 查到结果后要倒着读：最后一行是你项目
composer.json的声明，往上每行末尾的(required by xxx)才是真实阻断点
项目级 repositories 字段为何会让全局镜像失效
只要你在项目 composer.json 里写了 "repositories"（哪怕只是空对象 {}），Composer 就会忽略全局镜像配置，完全按你写的 repositories 顺序去请求元数据。
- 常见陷阱：CI 构建时因
repositories存在而走慢速源，本地却正常；或误删了私有仓库配置，导致所有包都 fallback 到官方源 - 检查方式：
composer config repo.packagist（项目级）和composer config -g repo.packagist（全局）输出必须一致才有效 - 合并配置时注意：已有
"repositories": [...]，新增镜像应 append，而非覆盖，否则私有包地址丢失 - 临时绕过：单次命令指定源，如
composer require vendor/package:3.0.0 --repository=https://packagist.org，不污染配置
最易被忽略的是：镜像同步延迟对 dev-main、alpha、刚打 tag 的版本影响最大，而这类版本恰恰常出现在重构期或 CI 测试链中——你以为是约束写错了，其实只是镜像还没“看见”那个版本。
