直接写"vendor/pkg": "dev-main"会静默回退到stable版，因minimum-stability默认为stable，dev-main属@dev级别被直接过滤；必须配--stability=dev或@dev后缀才能生效。
直接发布 Composer 包的特定分支（如 dev-main 或 dev-feature/login）不是“发布”动作，而是让 Composer 能识别并安装它——关键在于仓库配置、版本约束写法和稳定性策略三者对齐。不改 composer.json 的 minimum-stability，光写 "vendor/pkg": "dev-main" 会静默回退到 stable。
为什么 composer require vendor/pkg:dev-main 没反应？
Composer 默认只接受 @stable 版本，dev-main 属于 @dev 级别，被直接过滤。它不会报错，也不会提示“找不到”，而是悄悄跳过，去选一个满足 minimum-stability: "stable" 的旧版。
- 检查当前项目
composer.json是否含"minimum-stability": "stable"（默认值，等效于没写） -
dev-main不是任意字符串——必须对应 Git 仓库真实存在的分支名（main、master、develop均可，但大小写和拼写必须一致） - 私有仓库需在
repositories中声明为"type": "vcs"，且 URL 是可git clone的地址（如https://github.com/you/pkg.git），不能是网页链接 - 执行后用
composer show vendor/pkg确认输出中versions字段是否含dev-main，而非仅显示^1.0或v1.2.3
dev- 分支 vs @beta 版本：别混用
dev-main 和 2.5.0-beta1 是两类东西：前者指向分支最新提交（持续变动），后者绑定 Git tag（固定快照）。它们的安装逻辑、锁文件记录方式、CI 可重现性完全不同。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
dev-main安装后，composer.lock记录的是具体reference（commit hash），下次composer install会复用该 commit；但若远程分支已更新，不update就不会拉新代码 -
2.5.0-beta1@beta安装后，lock文件记录的是完整版本号和稳定性标签，只要 tag 存在，就确定可重现 - 错误组合如
"vendor/pkg": "dev-main@beta"会直接报错：Invalid version string——@后缀不能叠用 - 想长期集成某分支的迭代成果，用
dev-main；想验证某个功能切片是否稳定，打 tag 并用2.5.0-beta1更可靠
测试版（Beta）发布的最小可行配置
临时试用一个 beta 版本，最安全的做法是不碰项目全局配置，只靠命令行参数驱动：
- 运行
composer require vendor/pkg:2.5.0-beta1 --stability=beta—— 这会临时把本次解析的最低稳定性设为beta，且只作用于该包 - 版本字符串必须与包仓库的 Git tag 或其
composer.json中"version"字段完全一致：2.5.0-beta1✅，2.5.0-beta❌（缺数字），2.5.0.BETA1❌（大小写/分隔符错） - 装完立刻验证：
composer show vendor/pkg输出应明确带(beta)标识；进vendor/pkg/目录看其composer.json的"version"是否真为"2.5.0-beta1" - 如果后续要回退，改
require为"^2.5"再跑composer update vendor/pkg，别只改composer.json就install——lock文件不更新，一切白搭
真正容易被忽略的点是 composer.lock 的残留控制力：它比 composer.json 优先级高，哪怕你删了整行 require，只要 lock 里还存着旧条目，install 就仍会装那个旧版本。每次调换分支或 beta 版本前，先看一眼 lock 文件里对应包的 version 和 reference 字段是否已同步更新，比反复重试更省时间。
