直接写dev-master会失败，因Composer默认minimum-stability为stable，直接过滤所有dev分支；且GitHub默认分支已改为main，dev-master常不存在，必须改用dev-main@dev才能绕过限制并准确指向当前主分支。
直接写 dev-master 会失败，不是语法错，而是 Composer 默认拒绝不稳定版本
为什么 dev-master 写进去就报错？
Composer 的 minimum-stability 默认是 stable，而 dev-master 是开发分支别名，属于 dev 稳定性级别。即使你写了 "vendor/package": "dev-master"，Composer 也会直接跳过匹配，报错类似：Could not find package vendor/package 或 No matching package found。
- GitHub 新仓库默认分支已是
main，dev-master实际可能已失效（远程没这个分支） - 即使远程还有
master，Composer 也不会自动 fallback，它只认你声明的分支名 -
dev-master不是语义化版本，不带@dev后缀或全局设minimum-stability: dev，它根本不会被解析为有效约束
正确做法：用 dev-main@dev 替代 dev-master
这是目前最健壮、可立即生效的方式，尤其适合临时调试或 CI 中拉最新提交：
- 运行命令：
composer require vendor/package:dev-main@dev - 等价于在
composer.json的require中写："vendor/package": "dev-main@dev" - 该写法绕过全局
minimum-stability限制，仅对这个包生效 - 明确指向
main分支（而非已废弃的master），避免因远程重命名导致锁定中断
如果必须用 dev-master（比如遗留项目强制依赖）
只有两个前提同时满足才可能成功：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 远程仓库确实还存在
master分支（不是重定向或已删除） - 你在
composer.json中显式设了："minimum-stability": "dev"和"prefer-stable": false
即便如此，仍建议改用 dev-main@dev —— 因为 dev-master 已被 Composer 官方文档标记为「不推荐」，且多数现代包不再维护 master 分支别名。
验证是否真的拉到了 Git 提交，而不是 zip 包
执行完 composer require 后，进 vendor/vendor/package/ 目录，运行：
git remote -v
输出应包含类似 origin https://github.com/vendor/package.git (fetch)；如果看到的是 https://api.github.com/... 或压根没 git 目录，说明 Composer 下载的是 zip 归档——那根本不是 dev 分支，只是某个 tagged 版本的镜像。
真正走 Git clone 才能保证每次 composer update 都 fetch 最新提交；否则你所谓“最新”只是缓存里的旧快照。
