直接修改 repo.packagist 并同步调大 http.timeout（建议600）和 process-timeout（建议1200）可解决90%超时问题；但键名必须为单数 repo.packagist、type 值必填 composer、URL 需以 https:// 开头且末尾带 /，否则镜像静默失效。
直接改 repo.packagist 并同步调大 http.timeout 和 process-timeout 就能解决 90% 的超时问题；但配错键名、漏掉 composer 类型标识、URL 缺末尾 /，会导致镜像完全不生效——表面命令成功，实际还在连 packagist.org。
composer config -g repo.packagist 命令为什么没用
不是网络慢，是配置根本没写对。Composer 2.2+ 对这个字段极其严格，任意一项出错都会静默 fallback 到官方源：
-
repo.packagist必须是单数，repos.packagist（多一个 s）或repositories.packagist.org都无效 - 命令中间的
composer是 type 值，不能省略，也不能替换成 URL 或注释 - URL 必须以
https://开头，且末尾必须带/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会请求/composer/packages.json，404） - 验证是否生效，只看这一行输出：
composer config -g repo.packagist，正确结果必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
http.timeout 和 process-timeout 到底该设多少
这两个参数管的是完全不同的阶段，混设等于白调：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
http.timeout控制每次 HTTP 请求（DNS + TLS 握手 + 首字节 + body 下载）的总时长，默认仅 60 秒。国内镜像首字节延迟高时最先触发失败，建议设为600（10 分钟） -
process-timeout控制整个composer install命令从启动到退出的总耗时上限，默认 300 秒。它包含解压、运行post-install-cmd、生成 autoload 等所有步骤，大项目推荐设为1200（20 分钟） -
http-basic.timeout是 v1 废弃项，v2 完全不读；--timeout=600只影响命令总时长，对 HTTP 下载阶段无效
CI/CD 或 Docker 构建中镜像不生效
容器每次启动都是干净环境，COMPOSER_HOME 未固化会导致配置丢失：
- 必须在构建脚本开头显式执行两条命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/和composer config -g http.timeout 600 - 更稳的做法是放弃全局配置，进项目根目录运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带-g），它会安全合并进composer.json的repositories字段，Git 可追踪，CI 可复现 - 若项目已有私有仓库配置，别手动编辑
composer.json的repositories数组——先确保它是对象结构再运行命令，否则可能清空原有配置
换源后还卡在 Downloading packagist.org
说明镜像根本没走通，90% 是缓存干扰或项目级配置覆盖：
- 先删掉
vendor/和composer.lock，再跑composer install --no-cache -vvv，盯住日志里真实请求的 URL 是否含国内域名 - 检查项目
composer.json中是否硬编码了"packagist.org": false或自定义repositories，这会完全绕过全局镜像 - 某些私有包用了
git@github.com:xxx/yyy.git这类 VCS 地址，镜像不代理，得单独处理 SSH 或代理配置 - 运行
composer diagnose，确认secure-http: OK和signature verification: OK同时出现；若后者为disabled，说明镜像跳过了签名校验，存在供应链风险
真正麻烦的不是超时值本身，而是网络路径中某一段（DNS、TLS、中间代理、镜像节点）出现非对称延迟——它可能只影响特定包、特定时刻。所以调到 600 还超时，先 curl -v https://mirrors.aliyun.com/composer/ 看卡在哪一环，比继续拉长 timeout 更有效。
