卡在downloading https://时应调http-basic-timeout（composer 2.2+）或旧版http.timeout，控制单次http请求的连接与读取总时间，默认60秒太短，建议设为300～600；同时须确保php default_socket_timeout不低于该值，否则底层会提前中断。
Composer 默认 timeout 太短，不是改一个地方就能解决的——它有三层超时机制，各自管不同阶段，必须按需同时调整。
卡在 Downloading https:// 该调哪个参数
这是 HTTP 请求卡住，比如拉 packages.json 或 ZIP 包头几 KB 就不动了。错误里常带 cURL error 28 或反复 retry 后失败。
-
http-basic-timeout（Composer 2.2+）控制单次 GET 的连接 + 读取，建议设为300；旧版用http.timeout，但注意它不能写进composer.json的config段 - 别碰
config.timeout：这个字段早已废弃，写了也无效 - 临时验证：运行
composer install --http-basic-timeout=300，看是否跳过卡点
报 The process timed out 该调谁
错误信息里明确含 The process "" exceeded the timeout，且 -vvv 输出最后一行是 git clone、unzip 或某个脚本命令，说明是子进程执行太久被杀。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只认
process-timeout：它控制每个外部命令（如解压、克隆）的最大秒数，默认300，大包或弱网下至少设1200～1800 - 全局生效：
composer config -g process-timeout 1800 - 项目级生效：
composer config process-timeout 1200（写入当前composer.json的config段） - CI/CD 中优先用环境变量：
COMPOSER_PROCESS_TIMEOUT=2000，优先级最高
为什么改了还是超时？PHP 底层 socket 会提前掐断
即使你把 http.timeout 设成 1200，如果 PHP CLI 的 default_socket_timeout 是默认的 60 秒，cURL 在底层就会直接报错，Composer 根本收不到完整响应。
- 查当前值：
php -i | grep default_socket_timeout - 临时覆盖：
php -d default_socket_timeout=1200 composer install - 长期修改：编辑
php.ini，改default_socket_timeout = 1200，然后重启 CLI 环境 - 注意：Docker 容器中要确认
php.ini被正确加载，不是只改了宿主机的配置
比调 timeout 更有效的第一步：换镜像源 + 清缓存
80% 的“超时”本质是源不稳定，不是网速慢。阿里云镜像能绕过 DNS 污染、TLS 握手抖动和国外源响应延迟。
- 切镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清缓存：
composer clear-cache（不执行这步，仍可能从损坏缓存读取） - 验证是否生效：
composer config -g repo.packagist应输出镜像地址；composer install --dry-run中下载链接应变成mirrors.aliyun.com - Git 类包（
"type": "git"）不走镜像，此时必须靠process-timeout+ Git 自身超时设置兜底
真正麻烦的从来不是“等多久”，而是中断后 vendor/ 里那些看似完整、实则校验失败的 ZIP 文件——它们不会自动清理，也不会被 --force 覆盖，下次执行仍会复现 Failed to extract 或 Content-Length mismatch。
