答案是composer 2.2+已废弃repo.packagist键名，必须改用repositories.packagist.org.type和repositories.packagist.org.url双命令配置，且url须https并以/结尾、缓存需清除、项目级repositories会无条件覆盖全局设置。
composer config -g 写入后没生效？先确认字段名和值类型
最常见原因是字段名拼错或值不是整数。Composer 对 config 字段名大小写、连字符、下划线极其敏感，且只接受整型数值——字符串会被静默忽略。
必须检查以下三点：
-
process-timeout（不是timeout或process_timeout） -
http-basic-timeout（注意是http-basic-timeout，不是http_timeout；Composer 2.2+ 才支持，v1 完全不读） - 值必须为整数：
"process-timeout": 1200✅，"process-timeout": "1200"❌
打开 ~/.composer/config.json（全局）或项目根目录 composer.json 的 config 段，手动核对字段是否存在、拼写是否准确、值是否为数字。
镜像配置错误导致 timeout 根本没机会触发
如果卡在 Resolving dependencies 阶段，说明问题出在 DNS 或元数据索引层，http-basic-timeout 和 process-timeout 都不会起作用——因为还没走到下载环节。
此时要验证镜像是否真正生效：
- 运行
composer config -g repositories.packagist.org.url，输出必须是带末尾/的 HTTPS 地址，如https://mirrors.aliyun.com/composer/ - Composer 2.2+ 不再识别
repo.packagist，必须用repositories.packagist.org.url+repositories.packagist.org.type两行配置 - 项目级
composer.json中只要存在"repositories"字段（哪怕空对象{}），就会无条件覆盖全局镜像
底层 PHP 或系统超时机制截断了请求
Composer 的 timeout 设置只是应用层控制，若 PHP 底层 socket 超时更短，它根本等不到自己设的阈值就中断了。
执行 php -i | grep default_socket_timeout，若输出是 60，而你设了 http-basic-timeout 600，那实际生效的是 PHP 的 60 秒限制。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
同样要注意 CI 环境中其他层级的中断：
- Docker
--stop-timeout参数 - Shell 层
timeout命令包裹 - GitHub Actions runner 级别超时（如
timeout-minutes: 10）
这些 Composer 完全感知不到，日志里只会显示 “The process timed out”，但真实原因在外部。
卡点不对，调错 timeout 类型
看到 Downloading https://... 卡住？该调 http-basic-timeout。
看到 Executing command (CWD: /path): git clone 卡住？那是 process-timeout 或环境变量 COMPOSER_PROCESS_TIMEOUT 控制的范围。
两者完全不重叠，混着改等于乱按开关。用 -vvv 看最后一行输出，精准定位卡在哪一层：
- 停在
Resolving dependencies→ DNS 或镜像未生效 - 停在
Downloading→ HTTP 层，查http-basic-timeout和 PHPdefault_socket_timeout - 停在
Executing command→ 子进程耗时，看process-timeout和系统资源（内存、磁盘 I/O）
真正难的不是设值，而是确认这个值被谁读、在哪个环节起作用、有没有被更高优先级的机制覆盖——配置写进文件只是开始，不是终点。
