最直接有效的组合是换阿里云镜像、清缓存、调http.timeout，必须按序执行；验证需运行composer config -g repo.packagist确认输出为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，并用composer install -vvv | grep -i "mirrors.aliyun"检查日志是否命中镜像地址。
换阿里云镜像 + 清缓存 + 调 http.timeout 是最直接有效的组合，但必须按顺序做对，否则 90% 的“已换镜像仍超时”都是这三步没走全或走错。
怎么确认镜像真的生效了
别信“我执行过命令了”，得看实际请求地址：
运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；
如果返回空、null、字符串 "https://packagist.org" 或报错，说明配置根本没写进去。
再跑一次 composer install -vvv | grep -i "mirrors.aliyun"，日志里没出现 mirrors.aliyun.com 就等于还在直连海外。
为什么清缓存比换镜像还关键
Composer 缓存的是元数据（packages.json、provider-*.json），不是 ZIP 包。即使你改了镜像，它仍可能拿着旧缓存里的 packagist.org 地址去发请求——这不是网络慢，是状态污染。
必须做两件事：
• 执行 composer clear-cache
• 手动删掉缓存目录：rm -rf ~/.composer/cache/repo/https---packagist.org/（Linux/macOS）或 %APPDATA%\Composer\Cache\repo\https---packagist.org\（Windows）
项目级配置覆盖全局时，还要检查 composer.json 里有没有硬编码的 "repositories" 字段，有就删或改成阿里云地址。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
http.timeout 和 process-timeout 别混用
这两个参数作用层完全不同：
• http.timeout 控制单次 HTTP 请求耗时（DNS + TCP + TLS + 响应头），解决 cURL error 28 和 Could not fetch https://... 类错误；建议设为 600
• process-timeout 控制整个命令生命周期（依赖解析、下载、解压、脚本执行），解决卡在 Generating autoload files 后长时间无响应；建议设为 1200
注意：process-timeout 超过 7200 秒会被 Composer 硬编码回退到 300 秒，设再大也没用。
CI/CD 环境下容易忽略的固化动作
容器每次重启都会丢掉全局配置，COMPOSER_HOME 不显式指定就等于白配：
• 脚本开头加 export COMPOSER_HOME=/tmp/composer
• 再跑 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• 强制走 IPv4：加环境变量 COMPOSER_IPV4=1（Windows 下值是字符串 "1"，不是布尔）
• 别在 CI 上跑 composer update，它会重新解析依赖树，耗时远高于 install。
真正卡住的地方往往不是镜像本身，而是 DNS 解析失败、TLS 握手卡死、IPv6 干扰或缓存残留——这些环节不排查清楚，换十个镜像都没用。
