直接修改 composer.json 顶层 minimum-stability 字段（与 require 同级），值为小写 dev/alpha/beta/RC/stable（RC 必全大写），并配 prefer-stable: true；改后需运行 composer update --lock；它仅约束未显式标注稳定性的包版本。
直接改 composer.json 就行，不用插件也不用命令
设 minimum-stability 就是改项目根目录下 composer.json 的顶层字段，和 require 同级。它不是命令行开关，也不是插件配置，写错位置（比如塞进 config 或 extra 里）就完全无效。
-
minimum-stability必须是小写字母：可用值只有dev、alpha、beta、RC、stable（注意RC必须全大写，rc或Rc会被忽略，退回到默认stable） - 改完必须运行
composer update --lock或composer update，否则composer.lock不刷新，新设置不生效 - 它只影响“没显式写稳定性后缀”的包。比如
"monolog/monolog": "^3.0"会受约束；但"monolog/monolog": "^3.0@stable"就完全绕过它
为什么加了 minimum-stability 还报 “Could not find package”
这不是配置没生效，而是 Composer 在按稳定性排序过滤版本时，发现没有一个可用版本满足你设的最低级别——常见于包根本没发布对应标签的版本，或你查错了分支名。
- 先确认包真实有哪些版本：
composer show -a vendor/package-name，看输出里每行末尾括号里的标签，比如v2.0.0-beta1 (beta)或dev-main (dev) - 如果只看到
v1.5.0 (stable)，却写了"vendor/package": "@beta"，那必然失败——beta 版本压根不存在 - 私有包或未同步到 Packagist 的分支（如 GitHub 上刚推的
dev-feature），composer show -a也查不到，得手动加仓库源
prefer-stable: true 不是可选项，是必选项
只设 minimum-stability: "beta" 而不配 prefer-stable: true，Composer 可能选 v3.0.0-beta3 而不是已发布的 v2.9.5 (stable)，哪怕后者完全满足 ^2.0 约束——因为 beta 版本“更新”，它更“符合语义版本优先逻辑”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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的候选版本里，优先挑最稳定的那个” - 它必须和
minimum-stability同时存在才起作用；单独写它没意义 - 典型安全组合：
{ "minimum-stability": "beta", "prefer-stable": true }
比全局设 minimum-stability 更推荐的做法：单包加 @ 后缀
除非你在做原型验证或团队统一升级测试版，否则没必要把整个依赖树的稳定性水位拉低。对单个包加 @beta 或 @dev，精准可控，不影响其他依赖。
- 装 Laravel 最新 beta：
composer require laravel/framework:^11.0@beta - 临时试某个包的主干分支：
composer require phpunit/phpunit:dev-main@dev - 这种写法优先级高于
minimum-stability，哪怕全局是stable，也能拉取指定包的 dev 版本 - 不会触发其他依赖连带升级，
composer update vendor/package-name也能精准控制范围
稳定性不是质量担保，只是发布流程标记。dev 分支可能随时重写历史，beta 版 API 可能变动——用之前，得确认它真含你需要的功能，且团队愿意承担这个风险。
