--timeout=600仅延长主流程熔断阈值，若卡在Downloading则需--http-basic-timeout，卡在git clone则需process-timeout，且PHP的default_socket_timeout和环境变量优先级更高，单独调--timeout常无效。
Composer 运行依赖命令（如 composer install 或 composer update）超时，本质是三个独立超时机制在打架，只调 --timeout 很大概率没用。
为什么 composer install --timeout=600 有时还是报错？
因为 --timeout=600 只延长主流程熔断阈值（依赖解析 + 下载 + 解压 + 脚本执行），但卡在某个环节时，真正起作用的可能是另一个超时参数：
- 下载 ZIP 包卡住？那是
--http-basic-timeout在管（Composer 2.2+ 才支持） - 执行
git clone卡住？那是process-timeout在管 - PHP 自身
default_socket_timeout小于你设的 HTTP 超时？照样提前中断 - PHP CLI 的
max_execution_time被disable_functions禁用？也可能干扰
--timeout 和 --http-basic-timeout 怎么配才不白设？
两者必须配合使用，尤其在弱网、大包或私有源场景下：
-
--timeout必须带等号：composer install --timeout=1800有效，composer install --timeout 1800完全无效 -
--http-basic-timeout仅 Composer 2.2+ 支持，旧版本只能换镜像或硬扛 - 若卡在
Downloading https://阶段，光加--timeout没用，必须同步设--http-basic-timeout=300 - 私有 Git 仓库（如
git@xxx或https://github.com/org/private）不受--http-basic-timeout影响，得靠process-timeout
环境变量和命令行参数谁说了算？
环境变量优先级最高，会覆盖配置文件和大多数命令行参数（--timeout 是少数能显式覆盖它的例外）：
-
COMPOSER_PROCESS_TIMEOUT=0会让所有composer install忽略process-timeout设置，进程可能无限挂起 -
COMPOSER_HTTP_TIMEOUT=300会覆盖--http-basic-timeout（如果存在） - Docker 中设了环境变量，还要确认没被外层
timeout 600 composer install或docker run --stop-timeout截断
最常被忽略的一点：超时不是越设越大越好。设成 0 或极大值（如 3600），在 CI/CD 中一旦网络异常或镜像不可达，整个流水线就卡死不动，排查成本远高于合理设限后快速失败重试。
