Composer默认只安装stable版本，需显式加@dev后缀（如dev-main@dev）或配置stability-flags才能安装dev分支；minimum-stability设为dev会全局放宽限制，但推荐按包单独授权以保障生产环境稳定性。
想装 dev 分支、beta 版或 RC 版，却报 “Could not find package”？不是网络问题，是 Composer 默认只认 stable 版本 —— 必须显式告诉它“允许降级到哪个稳定性级别”。
为什么 composer require vendor/pkg:dev-main 还是失败
常见错误现象：明明写了 dev-main，执行后仍提示 Could not find package 或 no matching package found。
根本原因不是包不存在，而是 Composer 在解析这个约束前，先按 minimum-stability 做了一轮过滤。如果项目 composer.json 里没设 "minimum-stability": "dev"，也**没在版本字符串末尾加 @dev**，它就会直接跳过 dev-main 这类候选。
- 正确写法必须带
@dev后缀：composer require vendor/pkg:dev-main@dev -
@dev不是可选修饰，是强制声明：告诉 Composer “我明确接受这个包的开发版” - 若包是私有仓库或未被 Packagist 索引，
dev-main@dev仍可能失败，此时需确认仓库配置是否已加载
minimum-stability 的合法值和实际效果
minimum-stability 是 composer.json 根对象下的配置项，控制所有未显式标注稳定性的依赖的准入门槛。它的值不是“推荐稳定性”，而是“低于这个级别的版本一律不进候选池”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 合法值（从宽松到严格）：
dev→alpha→beta→RC→stable（注意：RC必须全大写，rc或Rc会被忽略，退回到默认stable） - 设为
"minimum-stability": "beta"，则alpha和dev版本不会被考虑，哪怕它们是唯一满足^2.0的版本 - 它只影响“无 @ 后缀”的约束；一旦写了
@alpha或@dev，就绕过该设置
如何安全地只为某个包放宽稳定性限制
改全局 minimum-stability 风险高——它会波及所有依赖，可能导致锁文件里混入大量 dev- 提交，上线时难清理。
更安全的做法是用 stability-flags 单独授权：
- 在
composer.json的根对象中添加："stability-flags": {"vendor/pkg": "dev"} - 然后正常写 require：
"vendor/pkg": "^3.0"—— Composer 会按dev门槛解析这个约束 - 效果等价于
"vendor/pkg": "dev-main@dev"，但更干净，不污染命令行历史或 CI 脚本 - 上线前检查：
grep -q '"version":"dev-' composer.lock可快速发现残留
生产环境上线前必须验证的两个点
很多团队卡在预发布环境用了 dev-develop，上线时只改代码、不碰依赖，结果 composer install 依然拉旧 commit —— 因为 composer.lock 锁死了 reference 字段。
- 上线前务必执行：
composer require vendor/pkg:^2.5（不带@dev），让 Composer 重解并锁定稳定版 - 确认
composer.lock中该包的version字段是类似"2.5.3"，而非"dev-develop"或"dev-main" - CI 流程中建议加校验：
grep -q '"version":"dev-' composer.lock && exit 1，防止误提交
真正麻烦的从来不是怎么装 dev 版，而是怎么确保它只在该出现的地方出现，且能被干净撤出 —— 所有稳定性操作都该以“可逆、可查、可锁”为前提，而不是靠临时 --stability=dev 掩盖配置缺陷。
