直接调高process-timeout和http-basic-timeout并切换国内镜像可解决90%超时问题，但须先通过composer update -vvv定位卡点：停在Resolving dependencies是DNS或域名访问问题；Downloading是HTTP层超时，需调http-basic-timeout；Executing command则需调process-timeout。
直接调高 process-timeout 和 http-basic-timeout 并切换国内镜像，90% 的超时问题当场消失；但卡在不同阶段要分层处理，乱调参数只会白等。
看 -vvv 输出最后一行，先定位卡点
运行 composer update -vvv，紧盯最后几行输出：
- 停在
Resolving dependencies：不是超时，是 DNS 解析失败或 packagist.org 域名不可达，跟 timeout 无关；可试dig packagist.org或换 DNS（如114.114.114.114） - 停在
Downloading https://...：HTTP 层卡住，该调http-basic-timeout（Composer 2.2+）或旧版的http.timeout - 停在
Executing command (CWD: ...)：比如git clone或unzip卡死，process-timeout才管用 - 停在
Generating autoload files后无响应：不是网络问题，是文件系统慢（如 WSL2 symlink）、PHP 配置限制（APCu CLI 未启用）或磁盘 I/O 堵塞
process-timeout 和 http-basic-timeout 必须一起设
这两个值独立生效，只改一个大概率仍失败：
-
process-timeout控制整个composer update生命周期（含依赖解析、下载、解压、脚本执行），默认 300 秒；大项目建议设为1200（20 分钟） -
http-basic-timeout控制单次 HTTP 请求（DNS + TLS + 首字节 + body 传输），默认仅 60 秒；下载 laravel/framework 这类大 dist 包时容易触发，建议设为300～600 - 临时生效：
composer update --process-timeout=1200 --http-basic-timeout=300 - 全局永久生效：
composer config -g process-timeout 1200+composer config -g http-basic-timeout 300
换镜像源比加 timeout 更治本
单纯拉长超时只是“等得更久”，不能解决连接不稳定这个根因：
- 阿里云镜像命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 中科大镜像命令：
composer config -g repo.packagist composer https://mirrors.ustc.edu.cn/composer/ - 禁用 packagist.org 回源（防 fallback 拖慢）：
composer config -g repo.packagist false - 注意：项目级
composer.json中的repositories字段会完全覆盖全局镜像配置，必须删掉或清空
CI/CD 环境要额外防三类坑
容器环境里超时更容易发生，且表现隐蔽：
- 环境变量比命令行参数更可靠：
COMPOSER_PROCESS_TIMEOUT=1200能覆盖插件和自定义 installer 启动的子进程，而--timeout有时失效 - 强制用 dist 包：
--prefer-dist避免git clone卡住，尤其对私有仓库无效的镜像场景 - 检查是否被外层中断：Docker 的
--stop-timeout或 shelltimeout命令会提前 kill 进程，Composer 自己根本感知不到
最常被忽略的是元数据缓存——即使换了镜像，Composer 默认 15 分钟不刷新远程 packages.json，composer update 可能根本没去新镜像站拉数据；用 composer update --refresh（≥2.5）或手动删缓存目录才能真正生效。
