换源比调timeout更有效，因超时主因是dns污染、tls握手失败或镜像未同步；阿里云镜像走bgp+cdn，首字节延迟仅50–200ms，远低于官方源的>5s，且必须执行composer clear-cache才生效。
直接换阿里云镜像源，再清缓存，90% 的“超时”问题当场消失。调 http.timeout 或 process-timeout 是补救，不是根治——因为卡住的根源几乎从来不是“慢”，而是 DNS 污染、TLS 握手失败或镜像未同步。
为什么换源比调 timeout 更有效
Composer 卡在 Downloading https://packagist.org/... 时，80% 是因直连境外源触发中间网络拦截（企业网/校园网/运营商 DNS 污染），不是你本地网速差。官方源无 CDN、无国内节点，首字节响应常 >5s，而默认 http.timeout 只有 60 秒，根本等不到响应就报错。
- 阿里云镜像（
https://mirrors.aliyun.com/composer/）走 BGP 多线+CDN，实测首字节延迟稳定在 50–200ms - 腾讯云镜像（
https://packagist.proxy.tencent.com）对 GitHub API 请求有额外代理优化，适合含github.com私有包的项目 - 中科大镜像（
https://mirrors.ustc.edu.cn/composer/）学术网络友好，但高峰期偶有同步延迟
换源后必须清缓存才生效
Composer 不会自动丢弃旧缓存里的元数据。即使你已执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，只要 ~/.composer/cache/repo/https---packagist-org/ 或对应镜像子目录还存在，它就会继续读损坏/过期的 packages.json。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 精准清理：运行
composer clear-cache（必须加这个命令，不能只改配置） - 验证是否真切换：执行
composer config -g repo.packagist，输出应为完整 JSON，且url字段末尾带/ - 再确认下载链接是否变：运行
composer install --dry-run -v，日志里所有Downloading行的域名应变成mirrors.aliyun.com
仍超时？检查是不是卡在 DNS 或 Git 克隆阶段
如果 -vvv 日志最后一行停在 Resolving dependencies，说明压根没发 HTTP 请求——这是 DNS 解析失败，http.timeout 完全无效。
- 用
dig mirrors.aliyun.com @8.8.8.8测试 DNS 是否通；若超时，临时改系统 DNS 为8.8.8.8或223.5.5.5 - 若卡在
Cloning into 'vendor/xxx'，说明是 Git 包（非 ZIP dist），镜像源不代理 Git 协议，需单独配 GitHub Token 或改用 HTTPS 克隆 - Git 克隆超时要调 Git 自身参数：
GIT_TIMEOUT=300环境变量，或改~/.gitconfig加[core] sshCommand = "ssh -o ConnectTimeout=10"
真正麻烦的不是“等多久”，而是中断后 vendor/ 里那些校验失败却看似完整的 ZIP 文件——它们不会自动清理，也不会被 --force 覆盖，下次 install 还会复用并报 Failed to extract。遇到这种，先删 vendor/autoload.php 和 vendor/composer/，再 composer dump-autoload，最后重试。
