minimum-stability是硬过滤闸，决定哪些版本能进候选池；默认为stable时，dev-main、beta等直接被跳过，连远程请求都不发，必须写dev-main@dev显式声明才有效。
minimum-stability 是硬过滤闸，不是“偏好”或“建议”。它直接决定哪些版本能进候选池——低于该级别的包（比如 dev-main、2.0.0-beta1）根本不会被 Composer 查看，连远程请求都不发。你看到的 “Could not find package”，往往不是网络问题，而是这个闸门关死了。
为什么 composer require vendor/pkg:dev-main 总失败？
默认 minimum-stability 是 "stable"，而 dev-main 不满足门槛。Composer 解析分两步：先过滤，再匹配。没进池子，@dev 后缀也救不了它。
-
dev-main必须写成dev-main@dev——@dev不是可选修饰，是强制声明“我接受这个包的开发版” - 小写
@rc会被完全忽略，退回到@stable；必须用@RC - 私有仓库若没配
dist，即使加了@dev，也会卡在Skipped branch或报no dist defined - 已存在的
composer.lock会固化旧策略；删掉它再跑composer update vendor/pkg --with-all-dependencies才能重算
prefer-stable 为什么看起来没用？
它只在多个候选都满足 minimum-stability 门槛时起作用。比如设了 "minimum-stability": "beta"，又同时有 2.0.0（stable）和 2.0.0-beta1（beta），prefer-stable 才会让 Composer 选前者。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只设
"prefer-stable": true不设minimum-stability，基本无效——因为默认就是stable，池子里本来就没别的 -
prefer-stable必须写在composer.json根层级，和require同级；写进"config": {...}里完全被忽略 - 它不能降级已安装的不稳定包；想换回稳定版，得显式运行
composer update vendor/pkg或删vendor重装
生产环境怎么锁死只装稳定版？
靠配置组合，不是单点开关。
- 必须同时设
"minimum-stability": "stable"和"prefer-stable": true—— 前者拦住所有非 stable，后者确保不因约束宽松而意外拉到 RC - 所有
require条目都不能带@dev、@beta等显式降级标记，否则会覆盖项目级设置 - 上线前务必检查
composer.lock中目标包的version字段：要是"dev-develop"或"reference": "a1b2c3d"，说明还锁着开发版，得用composer require vendor/pkg:^2.5显式切回 - 镜像源必须全局生效：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/；CI 构建中别信“已配过”，开头加一行重置更可靠
composer.lock 的固化效应——它不看你当前怎么配，只认自己锁住的版本。哪怕你改完 composer.json 并跑了 composer update --lock，如果部署时只执行 composer install，它还是会照装 lock 文件里那个 dev-main 提交。
