repositories必须是索引数组，不能写成对象；一旦配置，packagist.org默认关闭，需显式添加{"packagist.org": true}并置于末尾以实现fallback。
repositories数组必须是索引数组，不能写成对象
很多人在composer.json里把多个源写成键值对，比如：
{ "repositories": { "private": { "type": "composer", "url": "https://pkg.internal" }, "mirror": { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" } } }结果只有最后一个生效。Composer只认索引数组，每个源必须是数组里的一个独立元素。
正确写法是：
"repositories": [ { "type": "composer", "url": "https://pkg.internal" }, { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" } ]
- 顺序即查找优先级：Composer从上到下线性扫描，第一个返回 404 的才继续查下一个
- 只要某个源返回了包（哪怕只是 200 响应但内容为空），就不会再往下走
- 如果误写成对象，Composer会静默忽略除最后一个外的所有项，debug时很难发现
packagist.org默认被禁用，需手动加回并控制位置
一旦定义了repositories数组，Composer 就隐式设 "packagist.org": false。这意味着你执行composer require monolog/monolog会直接报错：Could not find package monolog/monolog。
要恢复公共包支持，必须显式把官方源加进数组，并放在私有源之后——这样私有包先命中，公共包才 fallback 到官方源：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
"repositories": [ { "type": "composer", "url": "https://pkg.internal" }, { "packagist.org": true } ]
- 别写
{"type": "composer", "url": "https://packagist.org"}，那是错的；官方源专用语法就是{"packagist.org": true} - 如果把它放在第一位，所有包都会优先走 packagist.org，私有源彻底失效
- 全局配置（
~/.composer/config.json）里的repositories会被项目级composer.json完全覆盖，不叠加
type选错会导致包根本找不到或行为异常
type决定 Composer 怎么解析这个源，不是随便填composer就完事：
-
"type": "composer"：适用于 Satis、Private Packagist、Artifactory 等完整元数据服务，支持版本列表缓存和精确匹配，适合主仓库 -
"type": "vcs"：指向 Git/SVN 地址（如"url": "https://gitlab.example.com/myorg/mylib.git"），Composer 每次都远程探测 tag，无法靠repositories顺序控制优先级，只适合单库临时引用 -
"type": "package"：用于声明单个包的静态信息，不支持自动版本发现，必须手写version和dist，慎用
混用vcs和composer类型时，前者永远绕过repositories顺序逻辑——它只在require时按包名硬匹配，不参与源间 fallback。
镜像源和私有源不能共存于同一配置而不显式禁用 packagist.org
常见错误是这么写：
"repositories": [ { "type": "composer", "url": "https://pkg.internal" }, { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" }, { "packagist.org": true } ]结果composer update仍报Could not fetch https://packagist.org/packages.json。
原因在于：Composer 在看到"packagist.org": true之前，已经按顺序尝试了前两个源；而阿里云镜像本身不包含packages.json的完整快照（部分镜像只代理/p/路径），导致请求失败后直接中断，根本不走到最后一行。
- 真正安全的做法是：只保留一个镜像源 +
"packagist.org": true，且把镜像放前面、官方源放最后 - 私有源和镜像源不要混在同一
repositories数组里——它们目标不同：私有源管特定 vendor，镜像源管全部公共包 - 如果私有源也想走镜像加速，得让私有源后端自己 upstream 到镜像，而不是靠 Composer 多源 fallback
repositories数组一旦存在，packagist.org 就默认关闭」这一隐式行为，以及「404 才 fallback，502/超时直接报错」的判定逻辑。这两点不厘清，再多的镜像 URL 都只是摆设。 
