答案是需两步验证：1. composer config -g repo.packagist 输出必须为含 "url": "https://mirrors.aliyun.com/composer/" 的完整JSON；2. composer config --list | grep repositories.packagist.url 确认未被项目级repositories字段覆盖，否则会静默回退至官方源。
阻塞超时不是镜像“慢”，而是 Composer 在元数据缓存策略、网络握手或配置覆盖上卡住了；换源后仍卡住，90% 情况下是本地没真正连上镜像，或还在用旧缓存算依赖。
怎么确认镜像真的生效了
很多人执行了 composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/，但实际请求仍发往 packagist.org。原因很隐蔽：
- 项目级
composer.json里写了"repositories"字段，会完全屏蔽全局配置——哪怕只有一行旧地址（比如已停用的https://packagist.phpcomposer.com），Composer 就会静默 fallback 到官方源 -
COMPOSER_HOME被自定义过，导致config -g写入失败，但命令不报错 - CI 环境中
~/.composer目录被挂载为空或权限受限，配置未持久化
验证方式必须两步走：
1. 运行 composer config -g repos.packagist，输出必须是完整 JSON 且含 "url": "https://mirrors.aliyun.com/composer/"
2. 运行 composer config --list | grep repositories.packagist.url，确保没被项目配置覆盖
为什么换了阿里云镜像还卡在 “Loading composer repositories”
这个阶段根本没开始下载 ZIP 包，只是 GET packages.json 元数据。卡住说明请求压根没发出去，常见真因：
-
curl -I https://mirrors.aliyun.com/composer/packages.json返回Could not resolve host→ DNS 解析失败，改/etc/resolv.conf或 hosts 绑定 IP -
curl -v https://mirrors.aliyun.com/composer/packages.json停在* TLS handshake→ WSL2 时间不同步、公司中间件拦截、或系统证书链缺失 - 返回 HTTP 502/503 → 正在用 Laravel China 镜像（
https://packagist.laravel-china.org），该源自 2025 年底起已不稳定，应立刻切到阿里云或腾讯云
注意：process-timeout 在这一步完全不生效，它只管后续依赖解析和下载阶段。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Composer update 显示 “Nothing to install or update” 却明明有新版本
这不是网络问题，是 Composer 默认复用本地缓存的 packages.json，15 分钟内不过期。哪怕镜像站已同步 monolog/monolog v3.6.0，你本地仍按旧元数据算，直接跳过远程校验。
-
composer clear-cache没用：它清的是整个缓存目录，但下次update会立刻重建并复用旧元数据 - 正确做法是
composer update --refresh（≥2.5 版本支持）：只丢弃所有缓存的packages.json和provider-*.json，强制从当前镜像源拉最新元数据 - 老版本 Composer 只能手动删：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
别信“加大 timeout 就能等到新版本”——timeout 再大，它也不会主动去查远程。
HTTP 超时和进程超时根本不是一回事
看到 cURL error 28: Operation timed out after 300000 milliseconds，说明是底层网络连接卡死，process-timeout 完全不管用。
-
http.timeout：控制单次 HTTP 请求总耗时（DNS + TCP + TLS + 响应头），单位秒，适用于Could not fetch https://...类错误 -
process-timeout：控制整条命令生命周期（依赖解析 + 下载 + 解压 + 执行脚本），超时直接kill -9 - 临时调高：运行时加
--timeout=600（等效于http.timeout），或设全局composer config -g http.timeout 600
但最短路径永远是：先确认 curl -I 能通镜像，再调 http.timeout，而不是一上来就 --timeout=3600 让命令 hang 更久。
真正卡住的地方往往藏在 DNS、TLS、缓存策略或配置覆盖里，而不是 Composer 本身。每次卡住，先 curl -I 验证镜像可达性，再 composer config --list 看实际生效配置，最后才动 timeout —— 顺序错了，调再多参数也没用。
