如何优化作曲家软件安装超时，增强网络稳定性？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1035个文字，预计阅读时间需要5分钟。
Composer安装超时并非网络中断，而是默认的300秒等不及于弱网下的DNS解析、TLS握手或首字节延迟——提高http-timeout和process-timeout是必要操作，但更换镜像源才是治本之策。
怎么改 Composer 的 HTTP 超时时间
Composer 的 HTTP 层超时由 http-timeout 控制，单位是秒，默认 300（5 分钟）。它最终映射为 cURL 的 CURLOPT_TIMEOUT，只影响元数据拉取和 zip 下载，不影响 vendor 内代码运行时的网络请求。
- 全局修改（推荐）：
composer config --global http-timeout 600 - 仅当前项目：
composer config http-timeout 600 - 临时生效（CI 中常用）：
COMPOSER_HTTP_TIMEOUT=600 composer install -
http-basic配置项跟超时完全无关，改了也无效 - 某些共享主机禁用该配置，会静默忽略，此时必须用环境变量方式
为什么只调超时还不够：process-timeout 才是卡死主因
process-timeout 控制的是整个命令生命周期，不是单个 HTTP 请求。Composer 在下载大包（如 symfony/symfony dist）或执行 post-install-cmd 脚本时，可能耗时远超 300 秒，此时 process-timeout 触发，进程被直接 kill —— 这比 cURL error 28 更难排查，日志里往往只显示 “Killed”。
- 全局设长：
composer config --global process-timeout 600 - CI 中更安全的做法：
COMPOSER_PROCESS_TIMEOUT=600 composer install - 别设成 3600：过长可能掩盖真实问题，600～1200 是国内弱网下的合理区间
-
set_time_limit(0)对composer install完全无效，PHP 脚本超时和 cURL 层超时是两层机制
镜像源配置错误导致“换源没用”的常见坑
换源是提升稳定性的第一步，但配错地址、路径末尾斜杠、覆盖逻辑或未禁用默认源，都会让镜像形同虚设。
- 阿里云正确地址是：
https://mirrors.aliyun.com/composer/（末尾带斜杠），但实际配置时必须写成https://mirrors.aliyun.com/composer（末尾不能有斜杠），否则返回 404 -
repo.packagist是单值字段，重复执行composer config -g repo.packagist ...会覆盖前一次，不会叠加 - 想实现“阿里云 + 官方兜底”，必须在项目
composer.json的repositories数组中声明，并加"packagist.org": false根节点配置 - 验证是否生效：
composer config -g repo.packagist输出应明确含国内域名；再用curl -I https://mirrors.aliyun.com/composer/packages.json看是否秒回 200 - 已停服的
https://packagist.phpcomposer.com别再用，2025 年底起已不可用
IPv6 fallback 和并行下载才是隐藏瓶颈
很多用户调高超时、换了镜像后仍卡顿，真实原因是 IPv6 尝试失败后才 fallback 到 IPv4，每次卡几秒，上百个包就累加成分钟级延迟；而默认并发数只有 3，根本吃不满带宽。
- 强制走 IPv4（最有效）：
COMPOSER_IPV4=1 composer install，Linux/macOS 可写入~/.bashrc永久生效 - 提高并发下载数（Composer 2.2+）：
composer config --global parallel-downloads 10，设太高（如 20）可能触发文件写入失败，6～10 更稳 - 别信“多线程下载插件”：旧版
hirak/prestissimo在 Composer 2.x 中已失效，甚至会静默降级为单线程 - 启用 HTTP/2（需 PHP 7.3+ + cURL 7.62+）：
composer config --global use-http2 true，减少握手开销
真正卡住的从来不是某一个参数，而是 IPv4 强制、镜像地址末尾斜杠、packagist.org 是否禁用、以及 parallel-downloads 和 process-timeout 的组合效果——这些点不全对，光调 http-timeout 就只是耐心等失败。
本文共计1035个文字，预计阅读时间需要5分钟。
Composer安装超时并非网络中断，而是默认的300秒等不及于弱网下的DNS解析、TLS握手或首字节延迟——提高http-timeout和process-timeout是必要操作，但更换镜像源才是治本之策。
怎么改 Composer 的 HTTP 超时时间
Composer 的 HTTP 层超时由 http-timeout 控制，单位是秒，默认 300（5 分钟）。它最终映射为 cURL 的 CURLOPT_TIMEOUT，只影响元数据拉取和 zip 下载，不影响 vendor 内代码运行时的网络请求。
- 全局修改（推荐）：
composer config --global http-timeout 600 - 仅当前项目：
composer config http-timeout 600 - 临时生效（CI 中常用）：
COMPOSER_HTTP_TIMEOUT=600 composer install -
http-basic配置项跟超时完全无关，改了也无效 - 某些共享主机禁用该配置，会静默忽略，此时必须用环境变量方式
为什么只调超时还不够：process-timeout 才是卡死主因
process-timeout 控制的是整个命令生命周期，不是单个 HTTP 请求。Composer 在下载大包（如 symfony/symfony dist）或执行 post-install-cmd 脚本时，可能耗时远超 300 秒，此时 process-timeout 触发，进程被直接 kill —— 这比 cURL error 28 更难排查，日志里往往只显示 “Killed”。
- 全局设长：
composer config --global process-timeout 600 - CI 中更安全的做法：
COMPOSER_PROCESS_TIMEOUT=600 composer install - 别设成 3600：过长可能掩盖真实问题，600～1200 是国内弱网下的合理区间
-
set_time_limit(0)对composer install完全无效，PHP 脚本超时和 cURL 层超时是两层机制
镜像源配置错误导致“换源没用”的常见坑
换源是提升稳定性的第一步，但配错地址、路径末尾斜杠、覆盖逻辑或未禁用默认源，都会让镜像形同虚设。
- 阿里云正确地址是：
https://mirrors.aliyun.com/composer/（末尾带斜杠），但实际配置时必须写成https://mirrors.aliyun.com/composer（末尾不能有斜杠），否则返回 404 -
repo.packagist是单值字段，重复执行composer config -g repo.packagist ...会覆盖前一次，不会叠加 - 想实现“阿里云 + 官方兜底”，必须在项目
composer.json的repositories数组中声明，并加"packagist.org": false根节点配置 - 验证是否生效：
composer config -g repo.packagist输出应明确含国内域名；再用curl -I https://mirrors.aliyun.com/composer/packages.json看是否秒回 200 - 已停服的
https://packagist.phpcomposer.com别再用，2025 年底起已不可用
IPv6 fallback 和并行下载才是隐藏瓶颈
很多用户调高超时、换了镜像后仍卡顿，真实原因是 IPv6 尝试失败后才 fallback 到 IPv4，每次卡几秒，上百个包就累加成分钟级延迟；而默认并发数只有 3，根本吃不满带宽。
- 强制走 IPv4（最有效）：
COMPOSER_IPV4=1 composer install，Linux/macOS 可写入~/.bashrc永久生效 - 提高并发下载数（Composer 2.2+）：
composer config --global parallel-downloads 10，设太高（如 20）可能触发文件写入失败，6～10 更稳 - 别信“多线程下载插件”：旧版
hirak/prestissimo在 Composer 2.x 中已失效，甚至会静默降级为单线程 - 启用 HTTP/2（需 PHP 7.3+ + cURL 7.62+）：
composer config --global use-http2 true，减少握手开销
真正卡住的从来不是某一个参数，而是 IPv4 强制、镜像地址末尾斜杠、packagist.org 是否禁用、以及 parallel-downloads 和 process-timeout 的组合效果——这些点不全对，光调 http-timeout 就只是耐心等失败。