-vvv是唯一能真正暴露Composer报错根源的方式，因其输出cURL原始请求、未解压响应体、SAT求解步骤、插件堆栈及扩展缺失提示等底层信息，而-v和-vv仅显示表层动作，无法定位SAT卡死、gzip解码失败、SSL静默中断等真实问题。
直接调 process-timeout 或 http.timeout 不一定管用——得先看卡在哪一层，否则白等。
怎么一眼看出卡在哪儿
运行 composer install -vvv 或 composer update -vvv，盯住最后一行输出：
- 停在
Resolving dependencies：DNS 或 Packagist 域名不通，跟 timeout 无关；试dig packagist.org或换 DNS（如114.114.114.114） - 停在
Downloading https://...：HTTP 层超时，该调http.timeout - 停在
Executing command (CWD: ...)：子进程（比如git clone、unzip）卡死，process-timeout或COMPOSER_PROCESS_TIMEOUT才起作用 - 停在
Generating autoload files后没反应：不是网络问题，是文件系统慢（如 WSL2 symlink）、APCu 未启用 CLI 模式，或 PHPmemory_limit不足
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 秒。下载大包或镜像首字节延迟高时最先触发失败。建议设为300～600 -
process-timeout：控制整个命令从 start 到 end 的总耗时上限，默认 300 秒。它包含解压、执行post-install-cmd、生成 autoloader 等所有步骤。大型项目跑脚本容易超，推荐设为1200 -
http-basic.timeout是 Composer v1 废弃项，v2 完全不读取，写了也无效
CI/CD 中必须组合出手，光加 timeout 不顶用
CI 环境更易超时，得同步做几件事：
- 必须配国内镜像：
composer config -g repos.packagist.org.url https://mirrors.aliyun.com/composer/ - 强制用 dist 包：
--prefer-dist，避免git clone卡住 - 环境变量比命令行参数更可靠：
COMPOSER_PROCESS_TIMEOUT=1200能覆盖插件和自定义 installer 启动的子进程 - 检查是否硬编码了 SSH 地址（如
git@github.com:xxx）；换成 HTTPS 或配GIT_SSH_COMMAND - 确认 Docker 容器没被
--stop-timeout或外层timeout命令包裹——那是另一层中断，Composer 根本感知不到
为什么调了 timeout 还失败
常见但容易被忽略的点：
-
process-timeout=0后仍失败？大概率是内存不足。检查php -r "echo ini_get('memory_limit');"，update阶段建议 ≥ 1.5G - 私有包走 Git 时，每次
git checkout都计入process-timeout总耗时，不是单次独立计时 -
composer dump-autoload --optimize在大项目里本身就很慢，可先install --no-autoloader，再手动运行 - Windows 长路径或杀软拦截会导致 symlink 创建极慢，表现为卡在 autoload 阶段，非超时问题
