确认镜像源真生效需三步：运行composer config -g repo.packagist输出必须为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；curl -i测试镜像url返回200；检查composer.json无覆盖全局的repositories字段。
直接换国内镜像源，再调 http.timeout 和 process-timeout，90% 的“超时”根本不是慢，而是卡在 DNS 或 TLS 握手——不换源只调 timeout，等于给堵死的路口加红绿灯时间。
怎么确认镜像源真生效了
很多人执行 composer config -g repos.packagist 后就以为搞定了，但终端里还在刷 Downloading https://packagist.org/p/...，说明请求压根没走镜像站。
- 运行
composer config -g repos.packagist，输出必须是类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，不能是packagist.org - 手动测镜像连通性：
curl -I https://mirrors.aliyun.com/composer/packages.json，要秒回HTTP/2 200；如果超时、返回503或404，问题出在本地 DNS、代理或防火墙，不是 Composer 配置 - 检查项目根目录下
composer.json是否硬写了"repositories"字段——它会覆盖全局配置，得删或改成镜像地址
http.timeout 和 process-timeout 到底管什么
这两个参数作用完全不同，混着调等于蒙眼改配置：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
http.timeout：控制单个 HTTP 请求总耗时（DNS + TLS 握手 + 首字节等待 + body 传输），单位秒。默认仅 60 秒，下载大包或镜像首字节延迟高时最先触发失败。建议设为600 -
process-timeout：控制整个命令生命周期（依赖解析、下载、解压、脚本执行），单位秒。默认 300 秒，大项目跑 post-install-cmd 容易超。建议设为1200 -
http.connect-timeout：只管 TCP 连接建立阶段，弱网下容易卡住，建议同步设为30～60 -
http-basic.timeout是 v1 废弃字段，v2 完全不读，设了也没用
看 -vvv 输出最后一行，快速定位卡点
运行 composer install -vvv 或 composer update -vvv，盯住最后几行：
- 停在
Resolving dependencies：大概率是 DNS 解析失败或域名无法访问，跟 timeout 无关；可试dig packagist.org或换 DNS（如223.5.5.5） - 停在
Downloading https://...：HTTP 层超时，该调http.timeout - 停在
Executing command (CWD: ...)：git clone、unzip 或脚本执行卡死，process-timeout才管用 - 停在
Generating autoload files后无响应：不是网络问题，可能是 WSL2 symlink 解析慢、APCu 未启用 CLI 模式或文件系统权限问题
最常被忽略的是：项目级 composer.json 中的 repositories 字段会强制覆盖全局镜像配置，哪怕你已经跑了十遍 composer config -g，只要这个字段存在且指向 packagist.org，就白配。删掉或改成镜像地址，才是关键一步。
