最准方式是运行composer config -g repo.packagist获取当前生效镜像地址,空或报错则走官方源;验证需用curl -fssl --max-time 3 https://mirrors.aliyun.com/composer/p2/monolog/monolog.json | jq -e 'has("packages")'测真实元数据接口,而非仅测/packages.json或依赖composer diagnose。

直接用 curl 测真实元数据接口,别信 composer diagnose 或首页 HTTP 状态码。 它们不反映 Composer 实际拉包行为,容易误判“通了但不能用”。
查当前生效的镜像地址
配置可能写了,但不一定真生效。最准方式是读取全局配置:
-
composer config -g repo.packagist—— 输出 JSON 就是当前用的镜像;空或报错Could not find package repo.packagist in global config,说明走官方源https://packagist.org - 漏掉
-g会查项目级配置,容易误判;composer config -l不显示嵌套字段,别指望它列出repo.packagist - 如果项目
composer.json里有repositories段,它会覆盖全局配置——此时得看composer config repositories中"packagist.org"对应的url
测真实请求路径是否可用
镜像站首页返回 200 ≠ Composer 能用。Composer 实际依赖的是 /p2/ 接口返回结构,不是 /packages.json。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论(Discussion)”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性,以及撰写结论。当用户输入以下任一指令时也会自动触发该功能: - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须测:
curl -fsSL --max-time 3 https://mirrors.aliyun.com/composer/p2/monolog/monolog.json | jq -e 'has("packages")' >/dev/null - 超时设
--max-time 3,避免卡住;加-f(失败不输出)和-s(静默)便于脚本判断 - 响应体必须含
"packages"字段且为非空对象/数组;只测GET /packages.json会漏掉 p2 协议异常(比如腾讯云旧源已停用,但根路径仍返回 200) - 某些镜像(如阿里云)要求 URL 末尾带
/,写成https://mirrors.aliyun.com/composer/才稳定,少斜杠可能 404 或降级回官方源
验证请求是否真发往镜像
配置对、接口通,不代表 Composer 正在用它——DNS 污染、缓存未清、UA 被拦截都可能导致请求绕过镜像。
- 先清缓存:
composer clear-cache,否则 Composer 会继续用旧源缓存的元数据 - 加
-vvv看真实请求:composer -vvv require monolog/monolog,日志里找GET https://xxx/composer/packages.json这一行 - 用
curl -v模拟 Composer UA 验证:curl -v -H "User-Agent: Composer/2.7.7 (Linux; ...)" -H "Accept: application/json" https://mirrors.aliyun.com/composer/packages.json 2>&1 | grep "Connected to\|HTTP/",确认输出含Connected to mirrors.aliyun.com - 浏览器打开
packages.json可能被拒(403),因部分镜像只认 Composer UA,所以别用浏览器测
真正难的不是“怎么测”,而是区分“服务通”和“Composer 可用”——前者只要 HTTP 层响应,后者要满足协议路径、JSON 结构、同步时效、SSL 证书、CDN 缓存等全部条件。一个环节断掉,composer update 就卡在 Loading composer repositories,而你看到的错误日志里甚至没有明确提示。










