“the process timed out”错误源于子进程卡住，非网络慢；应优先用-v定位卡点，再针对性优化而非盲目调高process-timeout；环境变量composer_process_timeout是新版唯一全局有效方式，设0易掩盖ssh密钥缺失等真实问题。
“The process timed out” 错误不是网络慢，而是 git clone、unzip 或某个 post-install-cmd 脚本卡住了——调大 process-timeout 是最快验证手段，但设为 0 很可能掩盖 SSH 密钥缺失、权限错误或 symlink 扫描死循环等真实问题。
为什么 process-timeout 改了还不生效
常见失效原因不是命令写错，而是优先级和版本兼容性被忽略：
-
composer config --global process-timeout在 Composer 2.2+ 中已废弃，执行后看似成功，实际不写入配置也不生效 - 命令行参数
--process-timeout=1800优先级最高，但只影响当前这一次执行；CI 流水线里若没显式传参，就退回到默认 300 秒 - 环境变量
COMPOSER_PROCESS_TIMEOUT是唯一真正全局且新版全支持的方式，Linux/macOS 用export COMPOSER_PROCESS_TIMEOUT=1800，Windows PowerShell 用$env:COMPOSER_PROCESS_TIMEOUT="1800" - 在
composer.json里写"timeout": 0是无效字段，Composer 完全忽略，不会报错也不会警告
process-timeout 和 http-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只管子进程：比如git clone git@xxx、unzip vendor.zip、php -r "require 'vendor/autoload.php';"这类本地命令的单次执行时长 -
http-timeout只管网络请求：比如拉取https://mirrors.aliyun.com/composer/packages.json或下载 ZIP 包时的 cURL 等待时间 - 看到
curl error 28或卡在Downloading https://？该调http-timeout，不是process-timeout - 看到
[RuntimeException] The process timed out.或卡在Installing dependencies后无响应？这才是process-timeout的责任范围
怎么安全地调高 process-timeout
推荐按场景选择方式，避免一刀切设为 0：
- 临时调试（如 CI 救急）：
COMPOSER_PROCESS_TIMEOUT=1800 composer install—— 显式、可追溯、不污染环境 - 项目级固化（最推荐）：
composer config process-timeout 1800，会写入当前composer.json的"config"段，提交后团队共用，且不影响其他项目 - 全局生效（仅限开发机）：用环境变量
export COMPOSER_PROCESS_TIMEOUT=1800加到 shell 配置中；别信composer config -g process-timeout，新版已不认 - 值设多少合适？600～1800 秒（10～30 分钟）覆盖绝大多数私有 Git 仓库、大包解压、autoload 生成慢等场景；设为 0 表示禁用检查，但真遇到死循环或内存耗尽，你得手动
kill -9
比调超时更关键的是定位卡点
加 -v 参数运行是唯一可靠的方法，它能暴露真正卡住的命令：
-
composer install -v会逐行输出正在执行的子进程，最后几行就是卡点所在，比如停在Executing command (CWD): git clone --no-checkout 'https://xxx' 'vendor/xxx' - 如果卡在
Generating autoload files，大概率是 WSL2/NTFS 挂载路径下 symlink 太多，试试composer install --no-autoloader再手动composer dump-autoload - 如果卡在
post-install-cmd，检查脚本是否调用了未安装的全局命令（如php-cs-fixer），或含交互式输入（readline()），加--no-interaction可跳过 - Git 克隆卡住？先单独跑
git clone https://xxx看是否超时，再决定是换 HTTPS 源、配git config --global core.sshCommand "ssh -o ConnectTimeout=30"，还是调process-timeout
真正稳的做法不是把 process-timeout 设成 0，而是先用 -v 看清哪条命令在拖时间，再针对性优化——比如换镜像源、删掉冗余脚本、修复 symlink 权限，或者干脆改用 archive-format zip 绕过 git clone。
