Composer不支持自动选最快镜像，需通过外部脚本动态切换源；推荐使用composer-mirror-switcher工具或自定义测速脚本实现项目级临时覆盖。
不需要手动为每个项目配置镜像源——Composer 本身不支持“按项目自动切换最快镜像”，但可以通过全局配置 + 脚本化探测实现近似效果，核心在于绕过 Composer 原生限制，用外部逻辑接管源选择。
为什么 composer config 无法自动匹配最快镜像
Composer 的 config 命令只支持静态设置（如固定写死 https://mirrors.aliyun.com/composer/），不提供运行时测速、DNS 解析延迟判断或地理位置路由能力。所有“自动选最快”的方案，本质都是在 composer install 或 composer update 执行前，先运行一段外部脚本动态改写当前项目的 composer.json 或全局 repo.packagist 配置。
推荐做法：用 composer-mirror-switcher 工具做项目级临时覆盖
这是一个轻量 CLI 工具，会在当前目录下检测网络环境，从预设列表中选出响应最快的镜像源，并仅对本次命令生效（不污染全局配置）。适合 CI/CD 或多地域开发团队。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 安装：
curl -sS https://raw.githubusercontent.com/hirak/php-composer-mirror-switcher/master/install.sh | bash - 使用：
composer-mirror-switcher && composer install—— 它会临时修改COMPOSER_REPO_PACKAGIST环境变量，优先级高于composer.json和全局 config - 注意：它默认只测国内几个主流镜像（阿里云、腾讯云、华为云），若你在海外，需手动编辑其内置的
mirrors.json文件，加入https://packagist.org或欧洲镜像如https://packagist.jp
更可控的方式：用 shell 脚本 + curl -o /dev/null -s -w '%{time_total}' 测速
如果你需要完全自定义策略（比如按 IP geolocation 或 AS number 决策），直接写一个测速脚本比依赖第三方工具更可靠，也避免引入额外依赖。
- 原理：对多个镜像源的
/packages.json发起 HEAD 请求，记录time_total，取最小值 - 示例片段（保存为
choose-mirror.sh）：#!/bin/bash MIRRORS=("https://mirrors.aliyun.com/composer/" "https://mirrors.tencent.com/composer/" "https://packagist.org/") BEST="" MIN_TIME=999 for url in "${MIRRORS[@]}"; do TIME=$(curl -o /dev/null -s -w '%{time_total}' "$url/packages.json" 2>/dev/null) if (( $(echo "$TIME < $MIN_TIME" | bc -l) )); then MIN_TIME=$TIME BEST=$url fi done echo $BEST - 配合使用：
export COMPOSER_REPO_PACKAGIST=$(./choose-mirror.sh) && composer install - 坑点：
curl测速受本地 DNS 缓存影响，建议加-H 'Cache-Control: no-cache'；某些镜像（如华为云）可能对未带User-Agent的请求限速，需补上-H 'User-Agent: curl'
别踩的坑：不要动 ~/.composer/config.json 的 repositories 字段
很多人试图在这里写多个镜像并设 "packagist": false，再手动添加多个 packagist-mirror 类型仓库——这会导致 Composer 启动时依次尝试所有镜像，失败才 fallback，实际是“串行容灾”而非“自动选最快”，且严重拖慢首次加载速度。
- 错误示范：
"repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}, {"type": "composer", "url": "https://packagist.org/"}] - 后果：只要第一个镜像返回 404 或超时，就会等满 timeout（默认 300s）再试下一个，不是并发测速
- 真正生效的只有第一个可用源，其余形同虚设
真正的“自动匹配最快”永远发生在 Composer 外部——要么靠一次性的环境变量注入，要么靠每次执行前的测速脚本。没有一劳永逸的配置项，只有可重复的决策逻辑。测速精度、缓存策略、镜像健康检查，这些细节才是落地时最花时间的地方。
