镜像优先级由repositories数组顺序严格决定，无其他配置方式；改序无效主因是项目级composer.json覆盖全局配置或未禁用packagist.org导致兜底。
repositories 数组顺序就是镜像优先级，没有其他配置方式。改完不生效，大概率是项目级 composer.json 覆盖了全局配置，或没禁用 packagist.org 导致兜底行为。
为什么改了 repositories 顺序却没走镜像
Composer 不会“智能识别哪个快就用哪个”，它只按 repositories 数组从上到下线性扫描，第一个能返回包元数据的源就锁定使用——但前提是这个源真能响应，且你没被其他配置干扰。
- 检查项目根目录
composer.json是否也定义了repositories：有则优先生效，全局配置（~/.composer/config.json）完全被忽略 - 确认是否显式写了
"packagist.org": false：没写的话，即使阿里云镜像排第一，只要它对某个包返回 404，Composer 就立刻 fallback 到packagist.org，看起来“优先级失效” - 运行
composer config repositories查看当前实际生效的源列表和顺序，别靠猜
type: "composer" 镜像必须提供合法索引文件
不是把 URL 往 repositories 里一贴就完事。国内常用镜像（阿里云、腾讯云）都是完整 type: "composer" 服务，自带 /packages.json 和 /p/{vendor}/{package}.json 等接口。如果你自己搭了个静态 HTTP 目录，只放了 zip 包但没生成索引，Composer 会直接报 Could not find package，连下一个源都不会试。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
curl -I https://mirrors.aliyun.com/composer/packages.json验证能否返回 200 和正确 JSON 结构 - 避免用
type: "vcs"指向 Git 仓库来“模拟镜像”：它不缓存版本列表，每次update都要远程探测 tag，且无法命中dev-main这类分支别名 - 自建镜像务必启用 providers 索引（如 Satis 的
providers选项），否则 Composer 不知道你支持哪些包
多个镜像共存时，404 和超时处理逻辑完全不同
Composer 对错误码的反应不是统一的：遇到 404 会立即跳到下一个源；但 DNS 失败、连接超时（默认 30 秒）、HTTP 500 等，会导致命令卡住甚至失败，根本不会查第二个源。
- 把响应最快、稳定性最高的镜像放在第一位（比如阿里云通常比某些小众镜像更可靠）
- 避免把需要认证的私有源和公开镜像混在同一数组——一旦私有源因
auth.json缺失而卡在 401，整个流程就中断 - 生产环境建议只配一个主力镜像 +
"packagist.org": false，而不是堆砌多个“以防万一”。多源不等于高可用，反而增加不可控延迟
