Composer无法真正禁用timeout，应设为86400等超大整数：全局执行composer config -g process-timeout 86400，项目级执行composer config process-timeout 86400，process-timeout控制git/unzip等外部命令超时，与网络下载超时无关。
composer install/update 时卡住，timeout 怎么彻底禁用
Composer 默认的网络请求 timeout 是 300 秒（5 分钟），超时会直接中断命令并报错 file could not be downloaded: failed to open stream: Connection timed out。想让 Composer 完全不中断等待（比如内网慢源、大包下载、调试代理），不能设成 “0” 就完事——它不认 0 作为合法值，会报错 Invalid timeout value: 0。
全局或项目级设置 timeout=0 不生效？改用超大整数
Composer 的 timeout 配置只接受正整数（单位：秒），0 被明确拒绝。真正可行的做法是设一个足够大的值，让实际使用中几乎不会触发：
- 运行
composer config -g process-timeout 0❌ 会失败 - 正确做法：设为
0等效的“无限”——用3600（1 小时）或86400（24 小时）足够覆盖绝大多数场景 - 全局生效：
composer config -g process-timeout 86400 - 仅当前项目：
composer config process-timeout 86400（写入composer.json的config段）
process-timeout 和 github-oauth timeout 是两回事
很多人混淆这两个配置：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
process-timeout控制的是 Composer 自身执行外部命令（如git clone、unzip）的最长等待时间，和网络下载无关 - 真正影响
https://packagist.org或私有源下载的是 PHP 的default_socket_timeout，但 Composer 不暴露该参数；它底层用的是 cURL，所以最终依赖系统级 cURL 行为 - 如果你卡在
Downloading https://.../package.zip，优先调大process-timeout；如果卡在Cloning to /tmp/...，可能还要检查 git 的core.sshCommand或代理设置
临时绕过 timeout（调试用，不推荐长期）
某些极端情况（如断点调试、离线镜像同步），需要跳过所有超时逻辑：
- 加
-vvv查看具体哪一步卡住：composer update -vvv - 用
COMPOSER_PROCESS_TIMEOUT=0环境变量 ❌ 无效（Composer 会校验数值） - 有效临时方案：
COMPOSER_PROCESS_TIMEOUT=86400 composer update - 若仍失败，可能是 DNS 或 TLS 握手问题，需配合
curl -v https://repo.packagist.org/packages.json单独验证网络链路
真正“取消限制”在 Composer 里不存在，它的设计就是防 hang 死；所谓“0”，只是用一个远超实际需求的数字来逼近效果。别信文档里没明说的 magic 值，老老实实填整数。
