Composer “Operation timed out” 是因 cURL 默认 300 秒 HTTP 超时过短所致，应通过 composer config timeout 600～900 调整；COMPOSER_PROCESS_TIMEOUT 对该错误无效，因其仅控制 git 等子进程超时；配合国内镜像源效果更佳。
Composer install/update 时提示 “Operation timed out”
这是 Composer 默认连接 GitHub/GitLab/ Packagist 等源时，底层 cURL 的超时阈值太低导致的，尤其在弱网、代理环境或国内直连境外源时高频出现。错误信息里通常含 Operation timed out 或 cURL error 28。
根本不是网络完全不通，而是请求发出去了，但没在默认 300 秒（5 分钟）内收到完整响应（比如大包下载、重定向链长、DNS 解析慢），就被强行中断。
- Composer 本身不提供全局“超时秒数”配置项，
timeout和process-timeout控制的是不同阶段——前者是 HTTP 请求级（实际生效），后者是子进程执行命令级（如 git clone） -
timeout默认值是300（单位：秒），可直接覆盖；但设太高可能掩盖真实网络问题，建议先试600～900 - 修改方式优先用项目级配置，避免污染全局：
composer config timeout 600
，该命令会写入项目根目录下的composer.json的config.timeout字段
为什么 set COMPOSER_PROCESS_TIMEOUT 不起作用
很多人搜到 COMPOSER_PROCESS_TIMEOUT 环境变量，但设了仍报超时——因为这个变量只影响 git clone、hg update 这类外部 VCS 命令的执行时长，不控制 HTTP 下载包本身的连接/读取超时。
真正管 HTTP 层的是 timeout 配置项（对应 cURL 的 CURLOPT_TIMEOUT），而 process-timeout 对应的是 CURLOPT_TIMEOUT_MS 的毫秒级变体，但 Composer 当前稳定版（2.x）中并未将其暴露为独立配置，仅通过 timeout 统一控制。
- 别再导出
COMPOSER_PROCESS_TIMEOUT=0试图“无限等待”，它对Operation timed out错误无效 - 确认生效：运行
composer config --list | grep timeout，看到config.timeout值已变更 - 若用 Docker 或 CI 环境，确保该配置写入了构建上下文，而不是只在本地 shell 里 export
配合镜像源使用效果更明显
单纯调高 timeout 只是“等得久一点”，不能解决下载慢的本质。国内用户强烈建议同步切换为可信镜像源，例如阿里云或腾讯云的 Packagist 镜像。
- 一键切阿里云：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
- 注意：
-g是全局设置，若项目已锁定源（如composer.json里有repositories），需先删掉或改写对应项 - 镜像源 + 合理 timeout（如
300）往往比直连 +900更快更稳——因为镜像延迟低、带宽足，cURL 很少真等到超时就完成了
调试时怎么确认是哪个环节卡住
加 -v（verbose）参数看详细日志，重点观察最后一行失败前的 URL 和操作类型：
- 如果卡在
Downloading https://packagist.org/p/xxx.json—— 是 metadata 请求超时，调timeout就对了 - 如果卡在
Downloading https://api.github.com/repos/xxx/zipball/xxx—— 是 dist 包下载慢，除了 timeout，还要检查是否被 GitHub 限速（需配github-oauthtoken） - 如果卡在
Executing command (CWD): git clone --no-checkout 'https://xxx' 'xxx'—— 才轮到process-timeout生效，此时才需要调这个值
超时值不是越大越好，900 秒以上容易让 CI 流水线无谓空转；真正难搞的 case 往往不在 timeout，而在 DNS、MTU、中间代理劫持或源站限流——这些得靠 curl -v 和 traceroute 进一步定位。
