必须用composer config --global设置全局timeout，否则写入项目级配置无效；process-timeout、http.timeout、http-basic-timeout须为整数且键名严格匹配，验证需结合-vvv日志观察实际行为。
composer config -g 写入全局 timeout 配置的正确姿势
必须用 composer config --global，否则写进的是当前项目的 composer.json，对其他项目完全无效。timeout 类配置（如 process-timeout、http.timeout、http-basic-timeout）只在全局或项目级 config 段生效，但只有全局设置能跨项目起作用。
-
process-timeout控制命令执行超时（如git clone、php脚本），单位秒，值必须是整数：composer config --global process-timeout 1200 -
http.timeout控制 HTTP 下载超时（如获取packagist.org的packages.json），Composer 2.0+ 支持，同样要整数：composer config --global http.timeout 600 -
http-basic-timeout仅 Composer 2.2+ 支持，专用于 Basic Auth 场景（如私有仓库带账号密码），不能和http.timeout混用：composer config --global http-basic-timeout 900 - 别写错键名：不是
timeout、process_timeout或http-timeout，连字符和大小写必须严格匹配官方命名
为什么写了却没生效？常见静默失败原因
Composer 不报错，但配置被忽略——这是最典型的“假写入”。核心问题就两个：路径不对、格式不对。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确认真实全局配置路径：
composer config --global --list --verbose，首行显示的Global configuration file才是唯一有效位置；若显示/home/user/.config/composer/config.json，那~/.composer/config.json里的内容全作废 - 值必须是整数，不能加引号：
"process-timeout": "1200"❌（字符串会被忽略），"process-timeout": 1200✅ - Windows 上用 Git Bash 时，
%APPDATA%不自动展开，composer config --global可能写到空目录；换 PowerShell 或 CMD 重试 - 如果设了
http.timeout 600但下载仍卡在 60 秒，检查 PHP 底层：php -i | grep default_socket_timeout，若输出60，说明 PHP 自己掐断了连接，Composer 设置无效
怎么验证 timeout 配置真正在用？
看输出比看配置文件更可靠。运行带详细日志的命令，观察实际触发行为。
- 执行
composer update -vvv，留意开头几行是否出现Running update with --timeout=1200（仅当显式传--timeout参数时才打这个） - 更关键的是看下载阶段：若之前卡在
Downloading https://mirrors.aliyun.com/composer/packs/xxx.json，调高http.timeout后仍 60 秒中断，说明该参数没读到，大概率是 Composer 版本太低（http-basic-timeout需 2.2+） - 若卡在
Executing command (CWD: /path): git clone，而你只改了http.timeout，那完全不相关——得查process-timeout - 最终验证：删掉刚设的值，再
composer config --global --list | grep timeout，无输出即已清空；此时composer update应恢复默认 300 秒超时行为
CI/CD 或 Docker 环境里 timeout 配置容易被覆盖
全局配置只是 Composer 层的一环，上层系统限制会让它彻底失效。
- Docker 运行时若加了
--stop-timeout 30，容器可能在 Composer 超时前就被强制 kill，process-timeout完全没机会触发 - GitLab CI 的
timeout:或 GitHub Actions 的timeout-minutes:是硬性上限，Composer 自己的 timeout 再大也突破不了 - 某些 runner（如 self-hosted）自带 shell 级 timeout，比如
timeout 300 composer update，这时 Composer 根本等不到自己设的 1200 秒 - 建议做法：在 CI 脚本里统一用
timeout命令包裹，并把 Composer 的process-timeout设为略小于它（如 shell timeout 1800s，则 Composer 设 1700）
