Composer中文镜像结合镜像测速工具选择最佳源的指南-composer-PHP中文网

阿里云镜像当前最稳，因其同步延迟低（2–5分钟）、https响应一致、dns解析可靠；composer无自动选最快机制，不测速、不切换、不fallback，所谓“最快”仅是受本地网络、dns、cdn等影响的瞬时状态，生产环境应固定源而非依赖测速脚本。

composer中文镜像结合镜像测速工具选择最佳源的指南

阿里云镜像当前最稳，不是因为它永远最快，而是同步延迟低（2–5分钟）、HTTPS响应一致、DNS解析可靠；测速脚本结果只能反映瞬时状态，不能替代固定源配置。

为什么不能依赖“自动选最快”

Composer 本身不测速、不 fallback、不切换源。所谓“哪个源最快”，每次都是临时状态：受你本地网络、DNS 解析、CDN 节点、镜像同步延迟共同影响。清华源偶尔返回 403，腾讯云在部分教育网段有 DNS 解析失败，这些都不是速度问题，而是可用性问题。

别拿一次 curl 测速结果定终身——它只测 /packages.json 响应时间，不模拟真实下载并发、磁盘 I/O 或杀软拦截。生产环境必须固定一个源，而不是每小时换一次。

composer install 卡住 ≠ 镜像慢，可能是 TLS 握手失败或 DNS 缓存未清
测速脚本里 -m 10 是防卡死，但实际 Composer 默认超时是 300 秒，行为不等价
镜像同步延迟比响应时间更重要：一个 0.2s 但落后 1 小时的源，会装错包或报 package not found

如何用 shell 脚本实测几个镜像的响应时间

你可以用这个轻量脚本快速暴露 DNS 或 TLS 握手瓶颈，但仅作辅助判断：

#!/bin/bash
urls=(
  "https://mirrors.aliyun.com/composer/packages.json"
  "https://mirrors.tuna.tsinghua.edu.cn/composer/packages.json"
  "https://mirrors.cloud.tencent.com/composer/packages.json"
)
for url in "${urls[@]}"; do
  time=$(curl -o /dev/null -s -w '%{time_total}\n' "$url" -m 10 2>/dev/null | head -1)
  if [[ -n "$time" && "$(echo $time | bc -l 2>/dev/null)" > 0 ]]; then
    echo "$url → ${time}s"
  else
    echo "$url → timeout or error"
  fi
done | sort -k3 -n

要点：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

只测 /packages.json，这是 Composer 启动时必读的元数据入口，比测 ZIP 包更轻量、更具代表性
-m 10 设定单次超时为 10 秒，避免脚本卡死
建议每天早/晚各跑一次，观察趋势，而非单次决策

全局配置必须写对这三处，否则静默失效

90% 的“配了还是慢”问题，都出在这三个硬性要求上，缺一不可：

键名必须是 repo.packagist（注意是 repo 单数，不是 repos.packagist 或 packagist.org）
必须显式传入 composer 作为 type 值：漏掉它，Composer 2.x 会直接 fallback 到官方源
URL 必须是 HTTPS 且末尾带斜杠：https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（少斜杠会导致拼成 /composerpackages.json，404）

正确命令：

composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/

验证是否生效，只看这一条命令输出：composer config -g repo.packagist。必须返回类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON；空、null、或仍是 https://repo.packagist.org，说明根本没写进去。

项目级配置比全局更可靠，尤其在 CI 和团队协作中

全局配置容易被覆盖或权限不一致（比如宝塔用 www 用户执行，而 -g 配的是 root），项目级配置写进 composer.json，拉代码即生效，行为可预期：

进项目根目录，运行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加 -g）
该命令会自动向 composer.json 的 repositories 字段追加 "packagist" 条目，不会清空已有私有源
改完后务必运行：composer update --lock，让 composer.lock 记录新源地址

换源后仍卡在 Resolving dependencies？和镜像无关。镜像只加速下载环节，不参与依赖解析。如果卡在这里超过 10 秒，大概率是 composer.json 里 PHP 版本约束太宽、存在大量 dev- 分支依赖，或 require-dev 里塞了废弃插件。