process-timeout仅控制单个外部进程超时，不影响php执行时间、dns解析或网络代理等问题；需配合调整max_execution_time、切换https源、配置镜像等综合解决。
composer install 或 update 卡住时，process-timeout 真的能解决问题？
不能一概而论。它只影响「单个外部进程」（比如 git clone、unzip）的最长等待时间，不是整个命令的总超时。如果你卡在 DNS 解析、网络代理、或 PHP 扩展缺失导致的挂起，调高 process-timeout 毫无作用。
常见错误现象：PHP Fatal Error: Maximum execution time of 300 seconds exceeded —— 这是 PHP 自身的 max_execution_time 限制，和 composer 的 process-timeout 无关。
- 默认值是
300（秒），即 5 分钟；设为0表示禁用超时（不推荐） - 仅对子进程生效：比如下载 tarball 后解压、执行
git命令、运行post-install-cmd脚本中的外部命令 - 不影响 Composer 内部逻辑耗时（如依赖解析、包筛选）
全局设置 process-timeout 到 300 的正确方式
别改 composer.json —— 它不支持这个配置项。必须通过 Composer 配置系统写入，且优先级高于命令行参数（除非显式用 --process-timeout 覆盖）。
- 运行：
composer config -g process-timeout 300 - 效果：写入全局配置文件（通常是
~/.composer/config.json），所有项目都继承该值 - 验证是否生效：
composer config -g process-timeout，输出应为300 - 如果已存在本地
composer.json中的config块，它会覆盖全局值；此时需手动删掉本地配置里的process-timeout字段
临时覆盖：命令行传参比配置更直接
某些 CI 环境或一次性调试场景，用参数最稳妥，避免污染配置。
composer install --process-timeout=300-
composer update --process-timeout=600（需要更久时可设更高） - 注意：参数名是
--process-timeout，不是--timeout或--process_timeout，拼错会静默忽略 - 如果同时用了全局配置 + 命令行参数，后者优先生效
为什么设了 300 还超时？检查这三处
process-timeout 不是万能解药。真正卡住的地方往往在它管不到的层面。
- PHP 的
max_execution_time：Composer 主进程本身受此限制，尤其在慢速服务器上。可在命令前加php -d max_execution_time=0 - Git 协议问题：用
https替代git@地址，避免 ssh 连接 hang 死（Composer 默认倾向用 SSH） - 国内网络：即使
process-timeout足够长，DNS 或连接 github 可能直接失败。建议搭配composer config -g repo.packagist composer https://packagist.phpcomposer.com（或其它镜像）
真正难搞的是那些不报错、也不前进的状态——比如卡在 Downloading... 却没进度条，这时大概率是网络层问题，不是 timeout 设置低了。