Composer默认只装@stable版本，需同时满足"minimum-stability": "stable"且require中无@dev/@beta等显式降级标记；prefer-stable仅在候选池内排序，不改变准入规则，子依赖的minimum-stability声明可覆盖项目设置。
Composer 默认只装 @stable 版本，所谓“用稳定版”不是靠运气或默认行为兜底，而是靠两层控制同时生效：项目级的 minimum-stability 必须设为 "stable"，且不能在 require 中显式写 @beta、@dev 等降级标记——否则那一个包就直接绕过规则了。
为什么只设 "prefer-stable": true 还是装了 beta 版
因为 prefer-stable 不拦人，只挑人。它只在多个候选版本都满足 minimum-stability 门槛时起作用。比如你没改 minimum-stability（默认就是 "stable"），但 require 里写了 "vendor/pkg": "^2.0@beta"，Composer 就会直接跳过筛选阶段，把 @beta 当作硬性指令执行——prefer-stable 根本没机会干预。
-
prefer-stable单独存在基本无效；必须和minimum-stability配对使用 - 如果某个包的
require条目带@beta，哪怕整个项目设了"prefer-stable": true，它照样装 beta - 想验证是否真走稳定版，运行
composer show vendor/pkg，看输出的versions行是否只含无后缀或-stable的版本
minimum-stability 设成 "stable" 就万事大吉？
不完全是。这个设置只管“没加后缀”的依赖，对子依赖（即你装的 A 包所依赖的 B 包）不强制继承。如果 B 包自己的 composer.json 里声明了 "minimum-stability": "dev"，那它拉进来的 C 包就可能变成 dev-main，哪怕你的项目顶层是 "stable"。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查间接依赖是否“越界”，用
composer show --tree vendor/pkg展开依赖树 - 私有包或 GitHub 仓库若未配置
repositories，即使写了@stable也可能报Could not find package -
composer.lock会固化历史决策：就算你已删掉所有@beta，只要 lock 文件里还锁着2.0.0-beta1，下次composer install就继续装它
怎样确认当前到底装的是不是稳定版
别只信 composer.json 里的文字，得看实际解析结果。最直接的方式是查 composer.lock 里对应包的 version 字段，或者用命令实时验证：
- 运行
composer show vendor/pkg，看versions列表里第一个（通常是默认安装的）是不是无后缀的数字版本，如3.2.0而非3.2.0-beta1 - 运行
composer depends vendor/pkg，确认没有其他包在 require 里偷偷加了@dev或@RC - 检查
composer.lock中该包条目的source字段：type是git且reference是 commit hash，大概率是dev-main；如果是dist且url指向.zip包，基本可判定是 tag 发布版
真正容易被忽略的是子依赖的稳定性声明会覆盖你项目的设置，而且 composer.lock 的固化效应比配置文件更强——改完 composer.json 后不跑 composer update --lock，等于什么都没变。
