Composer install/update 超时应优先配置国内镜像并设置 process-timeout=600～1200，而非已废弃的 http-basic.timeout；若仍报 cURL 28 错误，说明问题在 DNS、代理或 TLS 握手层，需用 curl -v 测试镜像连通性。
composer install/update 时提示 Connection timed out 怎么办
超时本质是 Composer 在下载包或访问 Packagist 时，HTTP 请求被中断。默认 timeout 是 300 秒（5 分钟），但实际中常因网络波动、镜像响应慢、大包下载卡顿等提前失败。
直接改全局 timeout 最有效，但要注意：不是所有环境都允许无限制延长，盲目设太高反而掩盖真实问题（比如镜像不可用）。
-
composer config -g repos.packagist.org.type composer必须确保已配置国内镜像（如阿里云、腾讯云），否则延长 timeout 只是硬扛烂网络 - 临时生效用
--timeout=600：例如composer update --timeout=600 - 永久生效写入全局配置：
composer config -g process-timeout 600（注意不是timeout，是process-timeout） - 若仍失败，检查是否触发了 DNS 或代理问题——加
-vvv看具体卡在哪一步：composer update -vvv --timeout=600
process-timeout 和 http-basic.timeout 有啥区别
很多人搜到 http-basic.timeout 就去配，结果没用。这是旧版 Composer（v1）遗留的配置项，v2 已废弃；真正控制 HTTP 请求超时的是 process-timeout，它管的是整个命令生命周期（包括解压、脚本执行、依赖解析等），不是单个 HTTP 连接。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
process-timeout：单位秒，默认 300，推荐设为600～1200，再高意义不大 -
http-basic.timeout：v1 配置，v2 不读取，设了也无效 - Composer v2 实际底层用的是 Guzzle，但不暴露 HTTP 层 timeout 控制，所以别试图改
guzzlehttp/guzzle配置
在 CI/CD（如 GitHub Actions）里怎么稳定跑 composer install
CI 环境更易超时，尤其首次安装或缓存失效时。不能只靠拉长 timeout，得组合优化。
- 优先启用缓存：
composer install --no-interaction --prefer-dist --optimize-autoloader，避免 dev 包和源码拉取 - 加
--ignore-platform-reqs谨慎使用——仅当明确知道 PHP 扩展缺失不影响构建时才加，否则会掩盖兼容性问题 - GitHub Actions 示例片段：
run: | composer config -g repos.packagist.org.url https://mirrors.aliyun.com/composer/ composer config -g process-timeout 1200 composer install --no-interaction --prefer-dist
- 如果用 Docker，记得宿主机 DNS 不稳会导致超时，可显式指定
--dns 8.8.8.8或在/etc/resolv.conf中加固
为什么改了 process-timeout 还报 cURL error 28: Operation timed out
这个错误说明 cURL 层已放弃连接，Composer 还没来得及介入计时——也就是说，超时发生在 DNS 解析、TCP 握手或 TLS 协商阶段，process-timeout 根本没启动。
- 先确认镜像地址是否可直连：
curl -v https://mirrors.aliyun.com/composer/packages.json - 若 curl 也超时，问题不在 Composer，而在网络策略（公司代理、防火墙、DNS 污染）
- 某些企业网络会拦截 HTTPS SNI，导致 TLS 握手卡住，此时需配置
composer config -g github-oauth.github.com xxx或换用支持 SNI 的镜像 - Windows 上 WSL2 用户常见问题：/etc/resolv.conf 自动注入的 nameserver 不可用，需手动覆盖
process-timeout 是最快止血手段，但每次遇到都该顺手查下 composer diagnose 输出和镜像连通性——否则下次还是同一块石头绊倒。 
