--timeout=600是唯一可靠的局部方式，因Composer不支持在composer.json中配置timeout，该参数必须带等号以覆盖process-timeout，仅对当前命令生效且适用于install、update等主命令。
局部命令的 timeout 只能通过 --timeout= 参数设置，且必须带等号、不能空格，否则静默失效。
为什么 --timeout=600 是唯一可靠的局部方式
Composer 不提供 per-command 的配置项（比如在 composer.json 的 config 里写 "timeout": 600 是无效的），它只认命令行参数。这个参数覆盖的是 process-timeout，即整个命令生命周期上限（含依赖解析、下载、解压、脚本执行）。
-
--timeout=600表示最多运行 10 分钟，超时后抛ProcessTimedOutException - 错误写法：
composer install --timeout 600（缺=）会被完全忽略，不报错也不生效 - 该参数只对当前命令有效，不影响后续任何操作，适合 CI/CD 单次调试或临时救急
- Composer 2.2+ 才支持
--http-basic-timeout=300单独调 HTTP 层，但这是另一层超时，和--timeout不叠加、不替代
哪些命令支持 --timeout=
所有触发子进程的主命令都支持，包括但不限于：
-
composer install、composer update -
composer require、composer remove -
composer run-script（注意：它控制的是 Composer 启动脚本的总耗时，不是脚本内部 PHP 的执行时间）
不支持的场景：composer dump-autoload 或 composer validate 这类纯本地操作，加 --timeout 无意义，也不会报错，只是被忽略。
容易踩的坑：你以为设了，其实没生效
常见失效原因不是参数写错，而是被更高优先级配置覆盖或环境干扰：
- 项目级
composer.json中硬写了"repositories"，会绕过全局镜像，导致网络卡在下载环节——此时调--timeout没用，得先切镜像或清缓存：composer clear-cache - 在 Docker 容器中运行时，外层
docker run --stop-timeout或宿主机timeout命令会先于 Composer 自身超时机制 kill 进程，--timeout根本来不及触发 - CI/CD 环境（如 GitHub Actions）默认 PHP 配置可能限制了
max_execution_time，导致自定义脚本在post-install-cmd里提前被 PHP 中断，这时要配合php -d max_execution_time=0使用
真正卡住的时候，别只盯着 --timeout —— 先跑 composer install -vvv 看最后一行停在哪：是 Resolving dependencies（DNS/元数据问题）、Downloading（HTTP 层）、还是 Executing command（process-timeout 生效范围）。不同位置，该调的参数完全不同。
