composer 不允许绕过稳定性限制，必须显式声明 @dev 后缀才能安装 dev-main 分支；minimum-stability 是硬过滤闸门，prefer-stable 仅影响排序；推荐用 stability-flags 或 inline alias 精准控制单包稳定性，避免全局修改导致 ci 不可重现。
不能“绕过”稳定性限制，只能显式声明接受它——Composer 不是拦着你装 dev-main，而是根本没把它放进候选列表里。
为什么 composer require vendor/pkg:dev-main 总报 “Could not find package”
这不是网络错误，也不是包不存在。Composer 在发起任何远程请求前，就用 minimum-stability 做了硬过滤：默认值是 "stable"，所有 dev- 开头的分支、@alpha、@beta 都被直接跳过，连 Packagist 请求都不发。
- 正确写法必须带
@dev后缀：composer require vendor/pkg:dev-main@dev - 只写
dev-main不够，dev-main@dev才是完整、合法的约束标识 - 私有仓库若没配置
dist信息，即使加了@dev，也会在详细日志里看到Skipped branch或no dist defined提示
如何只为一个包启用开发版，不波及其他依赖
全局改 minimum-stability 到 dev 是最危险的做法——它会让所有依赖都可能降级到不稳定快照，CI 构建不可重现，上线后容易翻车。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 推荐做法：在
require中用 inline alias 锚定语义版本，例如："vendor/pkg": "dev-main as 2.0.0" - 或配
"stability-flags": {"vendor/pkg": "dev"}，再写"vendor/pkg": "dev-main"—— 这种组合下可省略@dev - 避免用
composer global config minimum-stability dev：全局设置对新建项目无效，执行后看似成功，实际无用
minimum-stability 和 prefer-stable 到底谁起作用
minimum-stability 是闸门，prefer-stable 是排序器——两者不互换，也不抵消。
-
"minimum-stability": "stable"→dev-main、2.0.0-beta被直接过滤，prefer-stable根本没机会生效 -
"minimum-stability": "dev", "prefer-stable": true→ 有稳定版时优先选，但你明确写了dev-main，它照样装 -
prefer-stable必须和require同级，写在config对象里完全无效
上线前最容易被忽略的残留问题
预发布环境用了 dev-develop 测试功能，上线时只改代码、删掉 require 行，却忘了把 composer.lock 里残留的 dev 分支记录清理干净——下次 composer install 仍会拉取旧 commit，导致线上行为不一致。
真正安全的做法是：上线前手动删掉该包的 lock 记录（或整个 composer.lock），再用稳定约束重装；或者一开始就用 dev-main#abc1234 锁定具体 commit，避免分支漂移。
