换镜像本身不降低cpu占用，但能避免因dns/tls超时、http重试导致的i/o忙等伪高负载；若镜像未生效，composer会反复阻塞等待海外源，表现为cpu 95%+空转而非真计算。
换镜像本身不能降低 CPU 占用，但它是让 Composer 不卡死、不触发高 CPU 回溯的前提——没它，其他优化全白搭。
为什么换镜像和 CPU 占用有关？
很多人以为“CPU 高是解析慢”，其实 Resolving dependencies 阶段的 CPU 飙高是纯本地计算，换镜像不影响它；但若因 DNS 解析失败、TLS 握手超时、HTTP 重试过多导致 Composer 在下载阶段反复阻塞、重试、回退，就会让 PHP 进程长时间空转等待 I/O，表现为 CPU 持续 90%+（实际是忙等，不是真计算）。这种假高负载常被误判为 Solver 问题。
- 老旧 CentOS 或 Docker 容器里
packagist.org常 TLS 握手卡在 10–30 秒，Composer 默认重试 3 次，每次等完才进下一步 - 镜像源未生效时，
composer config -g repo.packagist输出仍是packagist.org，说明全局配置根本没写进去 - 项目级
repositories配置会覆盖全局镜像，哪怕你设了阿里云，只要composer.json里有"type": "composer", "url": "https://packagist.org"，就照连海外
怎么确认镜像已真正生效？
别信“我执行过命令”，要验证输出和行为：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer config -g repo.packagist，必须看到完整 JSON 包含"url": "https://mirrors.aliyun.com/composer/"；若为空、null或含packagist.org，说明没生效 - 旧版 Composer（1.x）不识别
repo.packagist，得用：composer config -g repos.packagist '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}' - 换源后必须立刻执行
composer clear-cache，否则缓存里还是旧元数据，仍会尝试连海外 - 临时验证：加
-vvv参数跑一次composer install --dry-run，看日志里下载 URL 是不是全部指向mirrors.aliyun.com
镜像设置错误导致的 CPU 高占用典型现象
这些表现不是 Solver 问题，而是网络层卡死引发的伪高负载：
- 终端卡在
Loading composer repositories with package information超过 20 秒，且top显示php进程 CPU 95%+、内存缓慢上涨 -
strace -p $(pgrep -f "composer install")显示大量epoll_wait和clock_gettime，几乎没有磁盘或网络 syscall —— 这是典型的 I/O 等待忙等 - 同一台机器上
curl -I https://mirrors.aliyun.com/composer/packages.json秒回，但composer install就是不动 —— 说明 Composer 没走你配的镜像
阿里云镜像 + 并发控制才是完整组合
只换镜像还不够，必须同步限制并发，否则国内镜像也会被压垮：
- 设全局并发：
composer config -g http-max-concurrent-downloads 6（推荐 6～8，10+ 容易触发阿里云限流返回429 Too Many Requests） - 临时覆盖用：
COMPOSER_MAX_PARALLEL_HTTP_REQUESTS=6 composer install（注意不是COMPOSER_PARALLEL，该变量已废弃） - 如果用了 Docker，记得在
docker build中加--memory=1g --cpus=2，否则并发下载可能挤占 Solver 所需 CPU 资源
最易被忽略的是：镜像配置和并发控制必须同时生效，单独做任一者，在老旧服务器上都可能让 CPU 卡在“看似在算、实则在等”的状态里不动。
