镜像源不改变版本约束逻辑，只影响元数据可见性；^和~的解析由本地composer/semver完成，镜像仅决定“能看到哪些版本”，如镜像未同步v2.9.0则^2.8.0无法升至该版，而composer show -a显示的是镜像所见非全量版本。
镜像源不改变版本约束逻辑，只影响元数据可见性
镜像本身不参与语义化版本计算，^ 和 ~ 的行为完全由 Composer 解析器决定；但它会决定你“能看到哪些版本”——比如你写 "monolog/monolog": "^2.8"，若镜像尚未同步 v2.9.0，composer update 就不会升到该版本，而是停在镜像里最接近的 v2.8.4。
常见误判：看到没升到最新版就以为是约束写错了，其实是镜像延迟导致“可选版本集合”变小了。
-
composer show -a vendor/package列出的版本，反映的是当前镜像所见，不是 Packagist 全量 - 执行
composer update --dry-run后仍装旧版？先查镜像地址是否返回对应版本（如访问https://mirrors.aliyun.com/composer/p/provider-2024-07.json搜索包名） - 金融类项目倾向用
~2.8.4+ 固定镜像，就是为了规避“理论上可升、实际上不可达”的中间态
换镜像后 composer update 仍卡住或失败？先看锁文件和配置优先级
镜像再快，也绕不过 composer.lock 的硬锁定。如果 lock 文件里记着 "version": "1.1.5"，而你 composer.json 里写的是 "^1.2.0"，composer install 仍会装 1.1.5 —— 因为它只认 lock。
真正触发更新的，是 composer update 重新解析依赖图并生成新 lock；但这个过程会被以下情况打断：
- 项目级
repositories字段存在（哪怕只是空对象{}），全局镜像配置就完全失效 -
composer.json里写了过严约束，如"laravel/framework": "10.48.0"，它死也不会升到10.49.0 - PHP 版本不匹配、
conflict字段显式禁止、私有包未同步等硬冲突，镜像加速不了这些
强制获取最新包的三步实操：清缓存 ≠ 清元数据
composer clear-cache 只删已下载的 ZIP 包，不影响元数据缓存（即 packages.json 索引）。这就是为什么你换了镜像、清了缓存，composer update 还是拉不到新包。
必须按顺序执行：
- 运行
composer clear-cache - 手动删掉
~/.composer/cache/repo/下对应镜像的整个子目录（如https---mirrors.tuna.tsinghua.edu.cn-composer） - 加
-vvv参数重试：composer require vendor/package:dev-main -vvv，观察日志里请求的 URL 是否含镜像域名、状态码是否200
并发下载和权威类映射：两个常被忽略的本地性能瓶颈
换完镜像发现 composer install 还慢？大概率不是网络问题，而是本地配置没调好。
parallel-downloads 默认只有 3，并发太低；classmap-authoritative（Composer 2.x+ 默认开启）会让每次 update 强制重扫整个 vendor/ 目录，I/O 开销极大。
- 启用高并发：
composer config -g parallel-downloads 8（设 10 容易触发临时文件竞争） - 关闭权威类映射：
composer config authorative false（注意拼写是authorative，不是authoritative） - 删掉
composer.json中的"optimize-autoloader": true，改用composer dump-autoload --optimize手动触发
这些设置不改变镜像行为，但决定了你能否真正把镜像的带宽优势跑满——否则再快的镜像，也会被本地 I/O 或串行下载拖垮。
