设置 minimum-stability 为 dev 是允许安装开发分支包的最简方式，但会令所有未显式指定版本的依赖降级拉取不稳定快照，易引发兼容性、稳定性及性能问题；安全做法是按需使用 require 中带 @dev 后缀的版本约束局部覆盖。
直接说结论：设置 minimum-stability 为 dev 是允许安装 dev-master、dev-feature/x 这类开发分支包的最简方式，但不推荐全局设为 dev —— 它会让所有依赖（包括你没明确指定版本的包）都降级去拉不稳定快照，极易引发兼容性问题。
为什么 minimum-stability: dev 很危险
Composer 默认是 stable，只装 1.2.0、v2.0.0 这类带 tag 的正式版。一旦你在 composer.json 根级别写上 "minimum-stability": "dev"，所有未显式指定版本约束的依赖，都会自动 fallback 到最近的 dev- 分支（比如 dev-main），哪怕对方主干正在重构、CI 还没过、API 已经 break。
- 常见错误现象：
composer install突然失败，报错类似Could not find package vendor/name with stability dev（其实是某依赖的 dev 分支被删了或权限变了） - 更隐蔽的问题：项目跑起来了，但某天
composer update拉了个新dev-main，导致数据库迁移命令崩掉、或者前端 API 返回结构突变 - 性能影响：dev 分支通常没做优化，autoload 生成慢，且每次 update 都要重新解析大量分支指针，比 stable 版本慢 2–3 倍
真正安全的「尝鲜」做法：按需覆盖，不改全局
想用某个包的最新开发版？别碰 minimum-stability，用 require 里带 @dev 后缀的版本约束，它会局部覆盖稳定性策略，且只作用于那个包。
- 正确写法：
"vendor/package": "dev-main as 1.0.0"或"vendor/package": "dev-feature/login-flow@dev" - 如果对方没打任何 tag，又没公开
dev-main，可强制指向 commit："vendor/package": "dev-main#abc1234 as 1.0.0" - 注意：
@dev必须和分支名一起用，单独写"vendor/package": "@dev"会报错 —— Composer 不知道你想拉哪个分支 - 这种写法下，其他所有包仍走默认
stable策略，不会被波及
什么时候才该动 minimum-stability？
极少数场景：你正在搭建一个内部工具链，所有包都由你团队维护，全部走 dev-main，且 CI/CD 能保证每次合并都通过全量测试。即便如此，也建议配合 prefer-stable: true 来兜底。
-
"minimum-stability": "dev"+"prefer-stable": true= 优先找 stable 版，找不到再退到 dev 分支 - 必须同时加
"stability-flags"控制特定包的稳定性，否则还是失控："stability-flags": {"vendor/package": "dev"} - 千万别在生产环境的
composer.json里留着minimum-stability: dev—— 它不像注释，不会自己失效
最常被忽略的一点：即使你只给一个包加了 dev-main，它的 子依赖（即它 composer.json 里写的 require）依然受你项目的 minimum-stability 控制。所以，真要尝鲜，得确认上游包本身也没把它的子依赖写成不稳定的模式。
