composer查源是“命中即停”：首个返回200+合法json的源被锁定，后续全跳过；仅404触发下一源，超时或5xx直接中断；必须显式配置"packagist.org": false为独立项且置于repositories末尾，否则官方源隐式兜底。
Composer 查源是“命中即停”，不是“失败再试”
Composer 没有调度算法，只有线性查找逻辑：它按 repositories 数组从上到下发起元数据请求（如 /packages.json），**只要某个源返回 HTTP 200 + 合法 JSON（哪怕不含目标包）就立刻锁定该源，后续所有源完全不访问**。这不是“尝试失败后 fallback”，而是“第一个能说话的源说了算”。
常见误解是把镜像堆进数组就能自动选最快的——实际只要阿里云镜像服务正常、返回了 packages.json（哪怕里面没有你要的包），腾讯云或官方源根本不会被触发。
- 404 是唯一会触发下一个源的响应码；超时、502、DNS 失败、500 等全部直接中断命令
- 响应速度差异只影响“谁先抢到说话权”，不改变查找顺序
-
composer config repositories输出的顺序就是真实生效顺序，别靠猜
为什么改了 repositories 顺序却还是连不上镜像
最常踩的坑是没禁用隐式兜底源：packagist.org 默认始终在后台参与查找，哪怕你把它写在数组末尾且设了 "packagist.org": false，也必须确保它是一个独立对象、键名精确、位置在数组末尾——漏掉任一条件，Composer 就会偷偷绕过你的镜像直连原站。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 项目级
composer.json中定义了repositories，全局配置（~/.composer/config.json）完全失效 -
"packagist.org": false必须是repositories数组里的一个单独元素，不能嵌套在其他对象里 - 删掉
vendor/和composer.lock再运行composer install，否则 lock 文件里存的仍是旧源哈希
type: "composer" 镜像必须提供完整索引路径
不是 URL 往 repositories 里一贴就完事。Composer 会依次请求 /packages.json → /p/{vendor}/{package}.json → /dist/{vendor}/{package}/{version}.zip，任意环节返回非 200 或 JSON 格式错误，整个流程就卡住，不会跳下一个源。
- 自建镜像必须启用 providers 索引（如 Satis 的
providers选项），否则 Composer 不知道你支持哪些包 - 用
curl -I https://mirrors.aliyun.com/composer/packages.json验证是否返回 200 和合法 JSON - 别用
type: "vcs"指向 Git 仓库来“替代镜像”——它不缓存版本列表，每次update都要远程探测 tag，且无法匹配dev-main
生产环境别堆砌多个镜像源
加第二个镜像源只在一种场景有用：第一个镜像明确返回 404（包不存在），且你确认该包确实在第二个镜像中存在。但现实中，新包发布后镜像同步有几分钟延迟，此时第一个镜像返回 404，第二个也未必有——结果还是失败。
- 多个源反而增加不可控延迟：Composer 要逐个发起请求，哪怕只用第一个
- 私有源 + 公共镜像混用时，私有源必须放
repositories最前面，否则同名包会被公共源截胡 - 真需要容灾，得靠外部脚本检测镜像可用性（如
curl -o /dev/null -s -w "%{http_code}" URL返回 200 才启用），不是靠 Composer 自身机制
