卡在Downloading时应调http.timeout或http-basic-timeout：前者控制DNS+TLS+首字节+body总时间（默认300秒，弱网建议600），后者为Composer 2.2+新增、专管单次HTTP连接/读取（默认60秒，大包建议300）；二者均与process-timeout无关。
本地开发环境统一设 timeout，必须分三类配：HTTP 下载、子进程执行、PHP 脚本运行——三者互不干扰，漏一个就可能卡死。
卡在 Downloading https:// 时该调哪个参数
这是 HTTP 请求阶段失败，比如拉 packages.json 或下载 ZIP 包，错误里常带 cURL error 28 或反复 retry 后失败。它只认 http.timeout（Composer 2.x）或 http-basic-timeout（2.2+），和 process-timeout 完全无关。
-
http.timeout控制 DNS 解析 + TLS 握手 + 首字节等待 + 整个 body 传输总时间，默认 300 秒；弱网下建议设为600 -
http-basic-timeout是 Composer 2.2+ 新增项，专管单次 HTTP 连接/读取时限，默认仅 60 秒；大包场景建议同步设为300 - PHP 的
default_socket_timeout必须 ≥ 你设的http.timeout，否则 PHP 层先掐断；查命令：php -i | grep default_socket_timeout，若为 60 就得改 php.ini - 项目级最稳：运行
composer config http.timeout 600和composer config http-basic-timeout 300，写入当前composer.json的config段，可提交、可复现
The process timed out 错误该调哪一项
错误里含 [RuntimeException] The process "" exceeded the timeout，加 -vvv 能看到最后执行的命令（如 git clone、unzip、post-install-cmd）。这是子进程被杀，只由 process-timeout 控制，和 HTTP 完全无关。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
process-timeout默认 300 秒，影响整个composer install/update流程，包括依赖解析、下载后解压、运行脚本等 - 本地开发建议设为
1200（20 分钟）：运行composer config process-timeout 1200 - 若项目含大量私有包或需频繁
git clone，可设为1800；但不建议设为 0，避免静默卡死无响应 - 注意：某些旧版 Composer 对
process-timeout读取不稳定，CI 中建议额外用环境变量兜底：COMPOSER_PROCESS_TIMEOUT=1800
自定义脚本（如 post-install-cmd）超时怎么破
Composer 脚本本身是 PHP 进程，超时由 PHP 控制，不是 Composer 的 timeout 配置项能管的——很多人在 composer.json 的 config 里写 "timeout": 600，完全无效。
- 最常用方式：调用前加
php -d max_execution_time=0，例如：php -d max_execution_time=0 composer install - 若只针对某个脚本，用
composer run-script时同样生效：php -d max_execution_time=600 composer run-script post-build - 脚本内部可用
set_time_limit()主动延长，但要注意：必须在脚本开头尽早调用，且不能在已禁用该函数的环境中使用（查disable_functions） - 本地开发中，建议在 shell alias 或 Makefile 里封装好带参数的命令，避免每次手敲
本地开发最容易忽略的是 PHP 层的 default_socket_timeout 和 max_execution_time 冲突——哪怕 Composer 配置全调高了，PHP 自己先断连或 kill 进程，照样失败。务必用 php -i 确认这两个值，再动手改 Composer 配置。
