composer 的稳定性等级是硬性过滤规则，严格按 dev

Composer 的 stability 等级顺序是硬性过滤规则，不是“建议”

Composer 按 dev 严格排序，这个顺序决定了哪些版本能被选中安装——它是一道过滤闸，不是推荐列表。你设了 <code>"minimum-stability": "beta"，Composer 就会直接忽略所有 alpha 和 dev 版本，哪怕它们是唯一满足约束的版本。

• 稳定等级越低（比如 dev），代表越不可靠：可能没测试、API 随时重写、分支会被 force push 覆盖
• stable 是唯一默认值；不显式配置时，alpha 及以下版本根本不会进入候选池
• 注意：RC 不等于 stable，即使它看起来只差一个发布动作——Composer 把它当作独立等级，"minimum-stability": "stable" 会排除所有 RC 版本
• 常见错误现象：composer require some/pkg:1.0.0-RC1 在 minimum-stability 为 stable 时失败，报错 Could not find package some/pkg，不是网络问题，是稳定性被直接拦掉了

为什么 prefer-stable 必须和 minimum-stability 搭配使用？

prefer-stable 不改变允许范围，只影响“在合法范围内挑哪个”。单独开它没用；单独设低 minimum-stability 又容易拉到不该用的版本——两者配合才是可控的关键。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 例如："minimum-stability": "beta" + "prefer-stable": true → 当 monolog/monolog 同时有 3.5.0（stable）和 4.0.0-beta2 满足约束，Composer 选 3.5.0
• 但若只设 "minimum-stability": "beta" 且没开 prefer-stable，它可能优先选 4.0.0-beta2，尤其当约束写成 ^4.0 时
• 真实坑点：CI 环境里没开 prefer-stable，本地开发却开了，导致依赖版本不一致，半夜部署突然报错 Class not found（因 beta 版重构了类名）

怎么临时装一个 dev 分支，又不破坏全局稳定性？

别动 minimum-stability，更不要设成 dev——那等于给所有包开绿灯。正确做法是在 require 里加稳定性后缀，精准授权。

• 写法："phpunit/phpunit": "dev-main@dev" 或 "laravel/framework": "dev-develop@dev"
• 原理：这种写法会覆盖项目级 minimum-stability 限制，仅对该包生效
• 注意：@dev 后缀不能省；只写 "dev-main" 会被当成普通版本字符串，Composer 找不到匹配项
• 风险提示：如果该 dev 分支依赖其他包的 alpha 版本，而你没开对应稳定性，仍会失败——Composer 仍会校验整个依赖树的稳定性

私有仓库 + stability 设置，最容易被忽略的冲突点

私有仓库返回的元数据里如果包含 dev- 开头的版本（比如 dev-feature/x），而你的 minimum-stability 是 stable，Composer 会直接跳过这个仓库里的所有版本，哪怕它还有 1.2.0 ——因为整个包的可用版本列表被稳定性过滤清空了。

• 验证方法：运行 composer show vendor/private-pkg -v，看输出里是否列出 stable 版本；如果没有，说明仓库返回的版本全被 stability 规则筛掉了
• 解决思路：要么让私有仓库打 stable tag（推荐），要么在项目里对这个包单独放宽，如 "vendor/private-pkg": "dev-main@dev"
• 关键细节：这个行为和 repositories 顺序无关——不是“没找到才往下找”，而是“找到了但全被过滤，视为无可用版本”

事情说清了就结束。稳定性不是软性偏好，是 Composer 解析依赖时的第一道硬过滤；改它之前，先想清楚你到底要放开什么、守住什么。