dev-master已基本失效，因GitHub新仓库默认分支为main且Composer严格匹配分支名；必须用dev-main@dev或dev-main#full-hash并配vcs仓库，否则报“No matching package found”。
dev-master 已基本失效，dev-develop 也必须严格匹配远端分支名；不加 --stability=dev 或 @dev 后缀，99% 的情况会报 No matching package found。
dev-master 为什么大多时候根本不起作用
GitHub 新建仓库默认分支已是 main，而 dev-master 是 Composer 对「名为 master 的分支」的硬编码别名。如果远端根本没有 master 分支，Composer 就查不到任何匹配版本，直接报错：Could not find a version of package xxx matching your minimum-stability。
- 不是 Composer bug，是字符串精确匹配失败 —— 它不会自动 fallback 到
main -
dev-Main、Dev-main、dev_master全都不等价于dev-main，大小写和符号必须一致 - 即使你本地
git clone下来有master分支，只要远端仓库已删除或重命名，dev-master就无效
dev-develop 必须与远端分支名完全一致
Composer 不做任何分支名推断或标准化处理。dev-develop 只在远端真实存在名为 develop 的分支时才可解析成功。常见踩坑点：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 远端分支叫
dev，你写dev-develop→ 失败 - 远端分支叫
feature/login，你写dev-feature-login（用短横）→ 失败；必须写dev-feature/login（保留斜杠） - 私有 GitLab 仓库未在
repositories中声明vcs类型，且 URL 缺.git后缀 → 即使分支名对也查不到
require 中写 "vendor/pkg": "dev-develop" 为什么还装不上
因为 minimum-stability 默认是 stable，所有 dev- 开头的约束都属于不稳定版本，被直接过滤掉。必须显式放宽策略：
- 临时安装：用
composer require vendor/pkg:dev-develop --stability=dev（推荐调试用） - 长期协作：在
composer.json根级加"minimum-stability": "dev"，但上线前必须删掉或改回stable - 更安全的单包覆盖写法：
"vendor/pkg": "dev-develop@dev"，只对该包生效，不影响其他依赖稳定性判断
怎么锁定到某次提交，避免下次 update 拉到不可控代码
dev-develop 是浮动引用，composer.lock 虽然记录了当前 commit hash，但 composer update 仍可能拉新提交 —— 尤其当远端 develop 分支被 force push 后，旧 hash 直接失效。
- 显式锁定：把
"vendor/pkg": "dev-develop"改成"vendor/pkg": "dev-develop#abc1234"，再运行composer update vendor/pkg - 验证是否生效：检查
composer.lock中该包的source.reference字段，值应为 7～40 位小写十六进制哈希，不能是develop或HEAD - 强制走 git clone（而非 dist zip）：加
--prefer-source，否则某些镜像源可能忽略#hash
真正可靠的分支引用，从来不是靠猜分支名或依赖默认行为，而是三件事闭环：分支名与远端完全一致 + 显式声明稳定性策略 + 锁定具体 commit hash。漏掉任一环，CI 构建就可能在凌晨三点崩掉。
