卡在Downloading https://就调http-timeout，卡在Installing dependencies或报The process timed out就调process-timeout；二者独立生效，只改一个无效：http-timeout控制HTTP请求总时长（DNS+TLS+下载），默认300秒；process-timeout控制子进程执行时长（git clone等），默认300秒，新版需用环境变量COMPOSER_PROCESS_TIMEOUT全局设置。
卡在 Downloading https:// 就调 http-timeout，卡在 Installing dependencies 或报 The process timed out 就调 process-timeout；二者完全独立，只改一个大概率还是失败。
怎么判断该调哪个 timeout
错误现象直接决定配置方向：
- 看到
Could not fetch https://repo.packagist.org/packages.json、curl error 28、反复 retry 后失败，或卡在Downloading https://mirrors.aliyun.com/——这是http-timeout不够，它管的是 HTTP 请求从 DNS 开始到 body 下载完成的总时长 - 看到
[RuntimeException] The process "git clone ..." exceeded the timeout、卡在Installing dependencies阶段几秒后直接中断——这是process-timeout触发，它只杀子进程（如git、unzip、自定义脚本），和网络下载无关
注意：--timeout=600 这种命令行参数在 Composer 2.2+ 中仅等价于 --process-timeout=600，不改 HTTP 层；旧版甚至可能忽略 --http-timeout。
全局配置的正确写法（避免静默失效）
Composer 2.2+ 对键名、类型、URL 格式极其敏感，错一个就 fallback 到官方源，且不报错：
-
repo.packagist必须是单数，repos.packagist或repositories.packagist全无效 -
type值必须显式写成"composer"，不能省略，也不能替换成 URL 或注释 -
url必须以https://开头，且末尾必须带/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会请求/composer/packages.json，404）
正确命令示例：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ composer config -g http-timeout 600 composer config -g process-timeout 1800
验证是否生效，只看这一行输出：composer config -g repo.packagist，结果必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
CI/CD 或 Docker 构建中怎么确保配置生效
容器每次启动都是干净环境，COMPOSER_HOME 未固化会导致全局配置丢失：
- 必须在构建脚本开头显式执行配置命令，不能只靠本地开发机设置
- 更稳的做法是放弃全局配置，进项目根目录运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带-g），它会安全合并进composer.json的repositories字段，Git 可追踪，CI 可复现 - 若项目已有私有仓库配置，别手动编辑
composer.json的repositories字段——容易格式错、漏逗号、破坏 JSON 结构
另外，process-timeout 在新版中全局配置已失效，必须用环境变量：COMPOSER_PROCESS_TIMEOUT=1800（Linux/macOS）或系统级环境变量（Windows）。
为什么调了 timeout 还卡在 github.com
这不是 http-timeout 没起作用，而是底层 socket 连接根本没建立成功——http-timeout 只计「连接建立后」的数据传输阶段，DNS 解析慢、TLS 握手卡住、代理不可用，都会让请求卡在 connect 阶段，永远等不到超时计时开始。
此时要检查：
-
echo $HTTP_PROXY和echo $HTTPS_PROXY是否设了但实际不可用 - 是否被公司防火墙拦截，可试
curl -v https://github.com看卡在哪一步 - macOS 用户需刷新 DNS 缓存：
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
真正麻烦的是混合场景：镜像源启用了防盗链、PHP CLI 的 default_socket_timeout（查 php -i | grep default_socket_timeout）仍为默认 60 秒、或 ulimit 限制了打开文件数——这些都比单纯调 timeout 更容易被忽略。
