私有包总拉到老版本的主因是仓库顺序错误和type混用。Composer按repositories数组顺序查询，首个返回元数据的仓库即终止搜索；type为"composer"需packages.json显式声明包，"vcs"则依赖Git根目录composer.json且name严格匹配。
私有仓库版本冲突，90%不是配置没生效，而是 Composer 根本没去你写的那个仓库查——它查了别的源，匹配上了旧版，就直接停了。
为什么私有包总拉到老版本？顺序和 type 决定一切
Composer 查包时，从 repositories 数组第一个元素开始逐个询问：“你支持 myorg/utils 吗？”一旦某个仓库返回了元数据（哪怕只是声明支持），立刻停止后续查询，后面仓库里同名包的更高版本压根不参与比较。
- 顺序错误是唯一主因：比如
legacy-git（含 v1.8）排在internal-satis（含 v2.1）前面 → 永远装不到 v2.1 - 别混用
"type": "composer"和"type": "vcs"在同一个数组里——前者靠packages.json显式声明包，后者靠扫描 Git 仓库根目录的composer.json，机制不同，容易跳过预期源 -
type: "vcs"仓库不会自动识别分支/Tag 下的版本，只认远程仓库根目录的composer.json；且该文件里的"name"必须和require中完全一致（大小写敏感）
“包找不到”或“版本不匹配”，先看 Composer 实际用了哪个源
执行 composer show -a myorg/utils，输出中的 source 行会明确告诉你当前解析用的是哪个 URL。如果显示的是 https://packagist.org 或其他非私有地址，说明你的私有配置被绕过了。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查是否漏了顶层
"packagist": false：它必须是composer.json根对象的直接字段，不能嵌套在repositories里；没有它，packagist.org默认插队到末尾兜底，私有配置只是“补充”而非“替代” - 确认私有仓库
type正确：satis/toran用"type": "composer"，Git 仓库用"type": "vcs"，ZIP 包用"type": "artifact"；类型错会导致元数据无法解析，直接跳过 - 验证包名白名单：对于
type: "composer"私有源，必须在它的packages.json里显式列出"myorg/utils"；type: "vcs"则要求远程 Git 仓库根目录存在有效的composer.json，且"name"字段与require完全一致
多私有源共存时，如何让新版真正胜出？
Composer 不合并版本列表，也不 fallback，所以“让新版胜出”的唯一方式是确保它所在的仓库被优先查到，并且能成功返回元数据。
- 把最可信、最新版最全的那个私有源放在
repositories数组第一位 - 对
type: "package"类型（手动声明单个包），可在version字段用"dev-main as 2.1.0"做别名，但必须满足：右侧是合法语义化版本（如2.1.0，不能是2.1）、name和require完全一致、source.reference可真实拉取 - 运行
composer update --dry-run观察输出：如果看到myorg/utils 2.1.0而不是dev-main，说明别名生效；如果仍显示旧版或报错，重点检查source.url是否可访问、reference是否存在
最容易被忽略的一点：私有仓库的元数据有效性，比网络连通性更重要。即使 URL 能 curl 通，只要 packages.json 缺少对应包声明，或 Git 仓库根目录没有 composer.json，Composer 就当它不存在——连错误都不会报，只会安静地转向下一个源。
