Composer超时控制分三层：php.ini的default_socket_timeout、全局config的process-timeout、命令行--timeout；优先级从高到低，需同步调高PHP底层超时才真正生效。
Composer 的 timeout 设置存在哪几个层级
Composer 的超时控制不是单点配置，而是分三层叠加生效的：php.ini 中的 default_socket_timeout、全局 Composer 配置里的 process-timeout，以及命令行临时传入的 --timeout 参数。其中 process-timeout 默认是 300 秒（5 分钟），但一旦你用 composer config --global process-timeout 0 改过，它就会持久写入 ~/.composer/config.json，后续所有命令都受其影响。
如何确认当前生效的 timeout 值
别猜，直接查：
composer config --global process-timeout
如果返回 0 或一个非默认数字，说明已被修改；若提示 Key "process-timeout" does not exist，说明该配置项根本没设过，此时走的是内置默认值（300）或 php.ini 限制。注意：这个命令只查全局配置，项目级配置需进项目目录后去掉 --global 再试。
重置 timeout 的三种实操方式
根据你的修改来源选对应操作：
- 如果是用
composer config --global process-timeout N设的，就用composer config --global --unset process-timeout彻底删掉这一项 - 如果手动编辑过
~/.composer/config.json并加了"process-timeout": 0，删掉那行再保存即可（不推荐手改，容易格式出错） - 如果只是某次命令临时加了
--timeout=0，下次不带它就行——它不持久，无需“重置”
执行完 unset 后，composer config --global process-timeout 应该报错“does not exist”，这才是真正恢复默认状态。
为什么设成 0 还可能超时
很多人以为 process-timeout=0 就万无一失，其实不然：
-
process-timeout只控制 Composer 自身 PHP 进程的执行时间，不覆盖底层 cURL 或系统的 socket 超时 - PHP 的
default_socket_timeout（通常在php.ini里）仍会起作用，比如设成 60 秒，那即使 Composer timeout 是 0，网络请求卡住超过 60 秒也会中断 - 某些共享主机或 CI 环境会硬性 kill 长时间运行的进程，Composer 挡不住
真要调高容错，得同步检查 php --ini 找到的 php.ini 文件里 default_socket_timeout 的值，而不是只盯着 Composer 配置。
