根本原因是packagist.org默认隐式启用并插队到末尾匹配，必须在composer.json根级显式配置"packagist": false才能让私有仓库真正优先生效，否则所有私有配置仅作补充而非替代。

为什么私有包总是从 Packagist 下载，而不是我的私有仓库？

根本原因不是仓库“没生效”，而是 packagist.org 默认拥有兜底特权——哪怕你把它写在 repositories 数组第一位，只要没显式禁用，默认源仍会插队到末尾执行匹配。

必须在 composer.json 顶层加 "packagist": false，否则所有私有仓库配置都只是“补充”，不是“替代”。

• 检查是否漏了 "packagist": false：它必须是 composer.json 根对象的直接字段，不能嵌套在 repositories 里
• 确认私有仓库 type 正确：私有 Satis/Toran 用 "type": "composer"；Git 仓库用 "type": "vcs"；预打包 ZIP 用 "type": "artifact"——类型错会导致元数据无法解析，直接跳过
• 验证包名是否完全匹配：私有仓库若声明 "packages": {"myorg/utils": {"version": "1.0.0"}}，则 require: "myorg/utils" 才命中；写成 myorg/utils-dev 或大小写不一致都会失败

多个私有仓库共存时，为什么总拉到旧版本？

Composer 不合并版本列表，也不 fallback：它从 repositories 数组第一个元素开始查，遇到第一个能返回该包元数据的仓库就立刻停止，后面仓库的同名包版本压根不参与比较。

顺序错误是版本拉错的唯一主因。比如你有两个私有源：internal-satis（含 v2.1）和 legacy-git（含 v1.8），但 legacy-git 在数组前面 → Composer 永远看不到 v2.1。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 确保高优先级仓库（如最新版 Satis）排在 repositories 数组最前面
• 避免混用 type：不要把 "type": "composer" 和 "type": "vcs" 写在同一数组中做“权重调节”——它们的元数据发现机制不同，可能导致预期外的跳过
• 用 composer show -a myorg/utils 查看实际被选用的仓库来源；输出里 source 行会明确标出 URL

执行 composer update 时提示 “Could not find package … in a version matching …”

这不是网络或权限问题，而是 Composer 根本没去你期望的仓库查——它遍历 repositories 时，每个仓库都需通过包名白名单、pattern 或完整 packages 声明来“自我申报支持范围”。没申报 = 不查询。

尤其注意 type: "vcs" 仓库：它默认只支持该 Git 仓库下所有子目录（即所有 composer.json），但不会主动扫描分支/Tag；而 type: "composer" 仓库必须在自身 packages.json 中显式列出该包，否则视为不支持。

• 对 vcs 类型，确认远程仓库根目录存在有效的 composer.json，且 "name" 字段与 require 完全一致
• 对 composer 类型（如 Satis），检查其生成的 packages.json 是否包含目标包条目；可直接 curl -s your-satis-url/packages.json | jq '.packages["myorg/utils"]' 验证
• 临时加 "verbose": true 到 composer.json，再跑 composer update -v，观察日志中 “Reading packages.json from …” 是否出现你期望的私有源 URL

清缓存、删 vendor 后还是拉错包，怎么办？

缓存不是罪魁祸首。真正卡住的是 composer.lock 里已锁定的 source 信息：它记录了具体 URL 和 commit hash，下次 install 会直接复用，完全绕过仓库匹配逻辑。

更隐蔽的问题是：composer.lock 可能来自别人机器，里面锁的是 Packagist 的 dist URL，而你本地已禁用官方源——这时 install 会静默失败或报错，但不会自动重走仓库查找流程。

• 先运行 composer update --lock 强制重新解析依赖并更新 lock 文件（不改 vendor）
• 如果要彻底重来，删掉 composer.lock + vendor/，再执行 composer install ——但前提是确保 composer.json 的 repositories 和 "packagist": false 已正确配置
• 永远别信 composer clear-cache 能解决优先级问题：它只清本地 ~/.composer/cache，不影响 lock 文件或仓库匹配逻辑

实际排查中最容易被忽略的点是：你以为改了 repositories 就生效了，但 composer.lock 里还钉着旧源地址；或者你禁用了 packagist，却忘了手动把 packagist.org 作为普通仓库加回来——结果所有非私有包直接报错，而不是安静兜底。