Composer安装dev-main失败的根本原因是minimum-stability默认为stable，未加@dev后缀时dev-main被直接过滤；正确写法是dev-main@dev，或通过stability-flags按包授权、删composer.lock强制重算。
Composer 安装开发版，不是它“变懒”或“出错”，而是你没关掉它的默认稳定性闸门——它根本没把 dev-main 当成合法候选。
为什么 composer require vendor/pkg:dev-main 有时还是失败
常见错误现象是命令执行后报 Could not find package 或静默回退到 stable 版。这不是网络问题，也不是包不存在，而是 Composer 在解析前先做了硬过滤：如果项目 composer.json 里 minimum-stability 是 "stable"（默认值），且你没在版本字符串末尾加 @dev，它就会直接跳过所有 dev- 分支。
-
dev-main必须写成dev-main@dev——@dev不是可选修饰，是强制声明“我接受这个包的开发版” - 私有仓库未正确配置 dist 信息时，即使写了
@dev，也可能因无法生成快照而降级失败，此时加-v看详细输出能定位到 “no dist defined” 类提示 - 已存在的
composer.lock会沿用旧解析结果；若之前锁过稳定版，composer require可能不触发重算，需先删 lock 文件再试
minimum-stability 和 prefer-stable 到底谁管安装，谁管排序
minimum-stability 是硬性过滤闸，决定“哪些版本能进候选池”；prefer-stable 是排序偏好，只在多个候选都满足门槛时起作用——它不改变“能不能装”，只影响“选哪个”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 设
"minimum-stability": "stable"→dev-main、2.0.0-beta直接被忽略，连比较机会都没有 - 设
"minimum-stability": "dev"+"prefer-stable": true→ 若同时有2.5.3和dev-main，优先装2.5.3；但若你require里明写"vendor/pkg": "dev-main"，它照装不误 -
prefer-stable写在config对象里完全无效；必须和require同级，作为根字段存在
怎么安全地只为一个包启用开发版
全局改 minimum-stability 风险高，容易让其他依赖也混入 dev 提交，上线时难清理。更稳妥的做法是按包授权：
- 在
require中写"vendor/pkg": "dev-main as 1.0.0"：既绕过稳定性限制，又为该包提供语义化版本锚点 - 或配
"stability-flags": {"vendor/pkg": "dev"}，然后写"vendor/pkg": "dev-main"—— 这种组合下，@dev后缀可省略 - 避免用
composer global config minimum-stability dev：全局设置被 Composer 忽略，执行后看似成功，实际新建项目仍走默认stable
上线前最容易被忽略的残留问题
很多团队在预发布环境用了 dev-develop 测试功能，上线时只改代码，忘了切回稳定约束。结果 composer.lock 里还锁着 "reference": "a1b2c3d"，下次 composer install 依然拉这个 commit —— 即使远程分支已被 force-push 覆盖，也会因 lock 文件锁定而失效或报错。
- 上线前务必运行
composer require vendor/pkg:^2.5（明确指定稳定版约束） - 检查
composer.lock中该包的version字段是否为"2.5.3"这类格式，而非"dev-develop"或带reference的 hash -
prefer-stable不会自动替换已锁的 dev 版本；必须运行composer update vendor/pkg或全量update --lock才会重算
