正确命令是 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，关键点：字段名必须为单数 repo.packagist（非 repos），URL 末尾必须带 /，且末尾需明确指定 composer 类型；还需同步配置 http.timeout 和 process-timeout，并确保未启用 prefer-source 或被项目级 repositories 覆盖。
composer config -g repo.packagist 命令写错就白配
很多人执行了 composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/，结果 install 还是卡在 Downloading https://packagist.org ——根本没切过去。问题出在字段名多了一个 s：repos.packagist 是无效键，必须是单数 repo.packagist。
还要注意三点硬性要求同时满足才生效：
-
repo.packagist字段名不能拼错，也不能写成repositories.packagist.org（那是 Composer 2.2+ 的新写法，但和旧版不兼容） - URL 后必须带
/，https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（否则请求变成/composer/packages.json，404） - 命令末尾的
composertype 标识不能省，漏掉就 fallback 到官方源，且composer diagnose会报Repo is not configured properly
验证是否真生效：运行 composer config -g repo.packagist，输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象，不是字符串、不是空、也不是 null。
http.timeout 和 process-timeout 必须一起调，只改一个没用
镜像解决的是“慢”，timeout 解决的是“断”。腾讯云/阿里云镜像首字节响应偶尔延迟高，http.timeout 默认仅 60 秒，不够用；而 process-timeout 控制整个命令生命周期（含解压、脚本执行），大项目跑 post-install-cmd 很容易超。
这两个参数必须同步设置：
-
composer config -g http.timeout 600（单位秒，覆盖 DNS、TLS 握手、body 下载全过程） -
composer config -g process-timeout 1200（1200 秒 = 20 分钟，足够处理 vendor 解压和 autoload 生成） - 别碰
http-basic.timeout——Composer v2+ 完全不读这个配置；也别信--timeout=600，它只影响命令总时长，对 HTTP 下载阶段无效
CI/CD 环境更需注意：容器每次启动都是干净环境，COMPOSER_HOME 未固化会导致配置丢失，必须在构建脚本开头显式执行上述两条 config 命令。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
prefer-source: true 会让镜像完全失效
镜像只代理 dist 包（ZIP/TAR），不代理 Git 克隆。一旦 composer.json 或全局配置里开了 "prefer-source": true，Composer 就绕过镜像，直连 github.com 或其他 Git 地址——此时报 curl 28 或 The process timed out，跟镜像无关，是 Git 层的问题。
排查和修复方法：
- 检查项目
composer.json是否含"prefer-source": true - 检查全局配置：
composer config -g prefer-source，若输出true就得关掉：composer config -g prefer-source false - 私有仓库（如
git@xxx或自建 Satis）也会 fallback 直连，逐个尝试并重试，拖垮整体耗时；如有私有源，建议设为代理模式而非完全替换默认源
临时验证：加 --prefer-dist 参数强制走 dist 包，如果这时不超时，基本就是 prefer-source 搞的鬼。
宝塔、CI 用户最容易忽略的权限和覆盖问题
宝塔面板里执行一键部署或计划任务，默认用 www 用户运行，但 composer config -g 写入的是 root 的 ~/.composer/config.json，www 根本读不到。
解决办法分两种场景：
- 确认执行用户：
whoami查当前用户，再查对应家目录下是否有.composer/config.json - 让
www用户也用镜像：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 更稳妥的方案是项目级配置：
cd /your/project && composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），它会安全写入项目composer.json的repositories字段，不受用户权限影响
另外，项目 composer.json 中若已定义 repositories 字段，它会**完全覆盖**全局配置——哪怕你全局配了镜像，只要项目里写了 "packagist.org": false 或硬编码了错误 URL，镜像就彻底不生效。这种覆盖静默发生，不报错也不提示。
