若composer config -g http-basic-timeout或process-timeout返回整数（如600）则写入成功；无输出说明键名错误、路径不对或值非整数，需结合-vvv日志确认是否加载及卡点位置。
看 composer config -g 输出有没有值
运行 composer config -g http-basic-timeout 或 composer config -g process-timeout，如果返回一个整数（比如 600），说明已写入成功；如果无输出或返回 null，代表配置没落盘，不是命令没执行，而是键名拼错、路径不对，或被其他配置覆盖。
常见错误包括：http-timeout（旧版键名）在 Composer 2.2+ 中已被 http-basic-timeout 取代；process_timeout（下划线）会被静默忽略；值写成字符串 "600" 也不生效——必须是纯数字。
加 -vvv 看日志里是否带对应参数
真正起作用的不是“写进去了”，而是“运行时读到了”。用 composer update -vvv 触发真实流程，盯住开头几行：
- 若看到
Running update with --http-basic-timeout=600，说明http-basic-timeout被加载了 - 若看到
Running update with --process-timeout=1200，说明process-timeout生效了 - 但注意：这两个参数只在对应阶段出现——
http-basic-timeout出现在Downloading https://...行之前；process-timeout出现在Executing command (CWD: ...)行附近
如果日志里压根没提 timeout 相关字段，要么配置根本没读到，要么你用的是旧版 Composer（http-basic-timeout 需 ≥ 2.2）。
观察卡点位置，反推哪个 timeout 在起作用
超时不是抽象概念，它一定卡在某一行日志末尾。直接根据 -vvv 输出的最后一行判断：
- 停在
Resolving dependencies：跟所有 timeout 参数都无关，是 DNS 或镜像未生效，查dig packagist.org和composer config -g repos.packagist - 停在
Downloading https://mirrors.aliyun.com/composer/packages.json：调http-basic-timeout，不是process-timeout - 停在
Executing command (CWD: /tmp): git clone https://github.com/xxx：这时才轮到process-timeout
改错参数等于白改。比如卡在下载却去调高 process-timeout，完全不影响 HTTP 连接行为。
用 curl 和 php -i 排掉底层干扰
即使 Composer 配置全对，也可能被更底层机制掐断：
- 运行
curl -I https://mirrors.aliyun.com/composer/，看是否能快速返回200；如果连curl都卡住或返回000，说明问题出在网络或 DNS，不是 Composer 配置问题 - 运行
php -i | grep default_socket_timeout，输出值（如60）是 PHP 底层 socket 超时上限；若它比你设的http-basic-timeout小，Composer 设置就形同虚设，必须同步改php.ini或用ini_set('default_socket_timeout', 600) - CI 或 Docker 场景中，还要确认没被
timeout命令、Docker--stop-timeout或 runner 级别限制截断——那些 Composer 根本感知不到
最麻烦的不是配不配得上，而是你以为配上了，其实请求在半路就被系统或 PHP 拦下了。
