composer仓库顺序仅在禁用packagist.org后才生效，否则官方源始终兜底；必须将私有源设为type: "composer"并置于数组最前，再以{"packagist.org": false}关闭默认源，否则顺序无效。
Composer 的 repositories 数组顺序就是实际查找顺序，但仅在禁用默认源后才真正生效；不关掉 packagist.org，再调换顺序也没用。
为什么改了 repositories 顺序却没效果
根本原因是没显式禁用默认源。Composer 默认行为是：只要没写 "packagist.org": false，它就会把官方源当作隐式兜底仓库——无论你把私有源放第几位，只要它没声明支持你要的包，Composer 就直接跳去 packagist.org 查，根本不会看后面的仓库。
- 现象：
composer require myorg/utils还是报Could not find package，即使私有源 URL 已写进repositories - 原因：私有源未在
packages.json中声明myorg/utils，或该源类型为vcs且没打对应 tag - 验证方式：
composer config repositories输出里若还有"packagist.org": true或压根没这行，说明没禁用成功 - 错误写法：
{"packagist.org": false}放在数组最前面——它不是仓库项，必须跟在私有源之后
正确配置 repositories 顺序的写法
顺序生效的前提是：所有目标包都由显式声明的仓库覆盖，且 packagist.org 被关闭。此时 Composer 才会严格从上到下匹配，命中即停。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 私有源必须是
type: "composer"类型（如 Satis、Private Packagist），才能被索引并参与顺序匹配 -
vcs类型仓库不参与“版本列表匹配”，只在require明确指定包时触发克隆，无法靠顺序控制公共包流向 - 正确结构示例：
{
"repositories": [
{
"type": "composer",
"url": "https://internal.example.com"
},
{
"type": "composer",
"url": "https://partner.example.com"
},
{
"packagist.org": false
}
]
}
- 注意：
{"packagist.org": false}是开关语句，不是仓库对象，不能带type或url - 如果还想用公共包（如
monolog/monolog），得手动加回官方源，并放在数组末尾：
{
"repositories": [
{ "type": "composer", "url": "https://internal.example.com" },
{ "type": "composer", "url": "https://partner.example.com" },
{ "type": "composer", "url": "https://packagist.org" }
],
"packagist.org": false
}
常见踩坑点：顺序错 + 类型混 + 认证漏
三个最容易导致“明明配了却拉不到”的组合错误：
-
repositories写成对象而非数组：比如用"a": {...}, "b": {...}，结果只有最后一个 key 生效 - 混用
composer和vcs类型且期望统一排序：前者查packages.json，后者只认 Git tag，逻辑不互通 - 私有源需要认证但
auth.json缺失或域名不匹配：请求卡在401 Unauthorized，日志里只显示“no matching package”，容易误判为配置问题 - 改完
composer.json后直接composer install：lock 文件锁住了旧源信息，必须composer update --lock或删composer.lock重装
调试时怎么看实际走的是哪个源
别猜，用 -vvv 看真实请求路径：
-
composer require myorg/utils -vvv 2>&1 | grep 'GET.*packages.json'能看到最终请求了哪个 URL 的packages.json - 如果输出里反复出现
https://packagist.org/packages.json，说明"packagist.org": false没生效或位置错了 - 如果请求了私有源但返回空
{"packages":{}}，说明该源没生成对应包的元数据，不是 Composer 配置问题，而是服务端没发布
真正复杂的地方在于：顺序只是表象，底层依赖的是每个仓库是否“声明支持该包”。一个仓库即使排第一，若其 packages.json 里没列 myorg/utils，Composer 就当它不存在——这时候顺序再对也没用。
