composer install/update卡住通常是process-timeout（默认300秒）触发进程中断，常见于内网拉包、大包解压、ci资源受限等场景；可通过命令行--process-timeout=600、composer.json配置或全局config设置，但不推荐设为0；需结合网络、解压工具、脚本优化及php配置排查根本原因。
composer install 或 update 卡住，实际是 process-timeout 在起作用
Composer 默认的 process-timeout 是 300 秒（5 分钟），一旦某个命令（比如 git clone、unzip 或脚本钩子）超过这个时间，就会被强行 kill，报错类似：Process timeout exceeded。这不是网络或权限问题，而是 Composer 主动中断了进程。
常见于：内网拉私有 Git 包、大体积扩展包解压、CI 环境资源受限、PHP 脚本钩子执行慢等场景。
- 修改方式优先级：命令行参数 >
composer.json配置 > 全局配置 - 命令行最直接，适合 CI/临时调试：
composer install --process-timeout=600 - 若想长期生效，可在项目根目录的
composer.json中加："config": { "process-timeout": 600 } - 注意：该值设为
0表示禁用超时，但不推荐——万一卡死就彻底 hang 住，尤其在自动化流程里更危险
全局设置 process-timeout 影响所有项目，慎用
运行 composer config -g process-timeout 600 会写入全局配置文件（通常是 ~/.composer/config.json），之后所有项目默认都用 600 秒。看似省事，实则埋雷：
- 不同项目依赖差异大：有的只是小工具包，根本不需要 10 分钟；有的跑测试脚本却仍可能超时
- 团队协作时容易“静默覆盖”——别人没意识到你改了全局配置，本地复现不了问题
- CI 环境通常应显式传参（如
--process-timeout=600），避免依赖机器上的全局状态
process-timeout 不解决根本性能问题，只是兜底
把 process-timeout 设成 600 并不能让慢操作变快，它只延迟失败时间。如果频繁触发超时，说明有更深层问题：
- Git 包拉取慢？检查是否用了 HTTPS 而非 SSH，或是否命中了低速镜像源
- 解压慢？确认
unzip是否可用，或是否启用了7z替代（Composer 会自动 fallback，但某些容器里没装） - 脚本钩子（如
post-install-cmd）超时？应单独优化脚本逻辑，而非一味调高 timeout - PHP 内存不足也会表现为“假性超时”，可同时检查
memory_limit和composer diagnose输出
PHP CLI 配置和 Composer 版本也会影响实际表现
process-timeout 的行为在不同 Composer 版本中略有差异，且严重依赖底层 PHP 进程控制能力：
- Composer 2.2+ 对 Windows 的
proc_open超时处理更稳定；旧版本在 WSL 下可能误判 - PHP 编译时若禁用了
pcntl（如某些 Alpine 容器），process-timeout会退化为无效——此时只能靠外部 timeout 工具（如 GNUtimeout命令）包裹 - CLI 模式下
max_execution_time若设得太小（如 30），也可能提前中断 Composer 自身，需一并检查：php -r "echo ini_get('max_execution_time');"
process-timeout 只是掩盖症状。 
