minimum-stability 是 Composer 的稳定性准入门槛，设为 stable 时会拒绝所有 -beta/-dev/-rc 包，即使显式指定版本；需用 @dev 或 as 别名绕过，且 prefer-stable 不可替代其过滤作用。
为什么 minimum-stability 会突然导致包安装失败
它不是“设置版本”，而是告诉 Composer：**低于这个稳定级别的包，默认不准装**。比如设成 stable，那所有带 -beta、-dev、-rc 后缀的包，哪怕显式指定了版本，也会被拒绝——除非你额外加 @dev 这类稳定性标识。
- 常见错误现象：
Could not find package xxx with stability stable，但你明明写了"xxx": "dev-main" - 根本原因：Composer 先按
minimum-stability过滤候选包，再匹配你的版本约束；它不看“你写了什么”，只看“你写的是否符合全局稳定性门槛” - 默认值是
stable，不是dev—— 很多人误以为新项目能直接拉dev-main，其实是被默认值拦住了 - 这个值只影响「未显式标注稳定性」的依赖项；一旦你在版本号后加了
@dev或@rc，就绕过该限制
怎么安全地临时允许 dev 包（不改全局配置）
最常用也最推荐的方式：在 require 里直接写带稳定标识的版本，而不是去调低 minimum-stability。这样既精准，又不影响其他依赖。
- 正确写法：
"monolog/monolog": "dev-main as 2.10.0"或"laravel/framework": "10.x-dev" - 错误写法：把
minimum-stability改成dev，然后写"monolog/monolog": "^2.10"—— 这会让所有没锁死稳定版的包都可能退回到dev分支，风险不可控 -
as别名很重要：它让 Composer 把不稳定分支当成某个稳定版本来解析依赖树，避免冲突 - 注意兼容性：
dev-main没有语义化保证，CI 或不同机器上 install 可能拉到不同 commit，不适合生产环境长期依赖
minimum-stability 和 prefer-stable 的真实关系
这两个配置常一起出现，但作用完全不同：minimum-stability 是“准入门槛”，prefer-stable 是“同版本下的偏好开关”。很多人以为开了 prefer-stable 就能无视 minimum-stability，其实不能。
-
"prefer-stable": true的意思是：如果某个包同时存在2.10.0（stable）和2.10.1-beta1（beta），优先选2.10.0—— 但它不会帮你把2.10.1-beta1升级成稳定版 - 如果
minimum-stability是stable，而你 require 的是"foo/bar": "2.10.1-beta1"，那prefer-stable完全不生效，直接报错 - 真正安全的组合是：
minimum-stability: stable+prefer-stable: true+ 显式用@dev标注个别需要的包
CI 和团队协作时最容易忽略的一点
minimum-stability 是 composer.json 里的配置，但它**不控制 lock 文件生成逻辑**。如果你本地用 dev 装过包、生成了 composer.lock，而别人 minimum-stability 是 stable，他 composer install 时仍会照着 lock 文件还原——哪怕他本地配置更严格。
- 这意味着：lock 文件的存在，会让
minimum-stability在 install 阶段“失效”；它只在composer update或首次install无 lock 时起作用 - 所以团队必须统一
minimum-stability值，并且每次update后提交 lock 文件，否则会出现“本地能跑，CI 报错”或“CI 能过，本地装不上”的情况 - 别依赖 IDE 或文档说“设成 dev 就行”，真正起作用的是 lock 文件 + 当前命令类型（install vs update）+ 你 require 的写法三者叠加的结果
