stability-flags 是包级显式标记，优先级最高，覆盖全局设置；prefer-stable 是全局安装偏好，仅影响版本选择逻辑，需配合 minimum-stability 生效；二者分别实现“点上突破”与“面上引导”，共同构成完整稳定性策略。
stability-flags 和 prefer-stable 都是 Composer 控制依赖稳定性行为的机制，但作用层级、生效方式和使用场景完全不同。
stability-flags 是包级的显式标记
它写在 require 或 require-dev 的具体包版本后面，只影响那个包本身。常见形式有：
- "monolog/monolog": "2.9.0@beta" —— 强制安装 2.9.0 的 beta 版本
- "vendor/pkg": "@dev" —— 允许安装任意 dev 分支（如 dev-main）
- "vendor/pkg": "dev-main as 1.2.3" —— 把 dev-main 当作 1.2.3 来解析，满足其他包的版本约束
这种写法优先级最高，会覆盖 minimum-stability 和 prefer-stable 的全局设置。适合个别包必须用开发版、又不想放宽整个项目稳定性的场景。
prefer-stable 是全局的安装偏好
它不改变可安装的范围，只影响“选哪个版本”的决策逻辑。启用后（"prefer-stable": true），Composer 在满足所有约束的前提下，会优先选择更稳定的版本。
- 比如 A 包同时有 stable 1.2.0 和 dev-main 可用，且都满足版本约束 → 选 1.2.0
- 但如果只有 dev-main 满足依赖链要求（例如其他包强制要求 >2.0），那仍会装 dev-main
- 它必须配合 minimum-stability 才能起效：若 minimum-stability 是 stable，prefer-stable 就没实际意义
两者常一起用，但角色分明
典型组合是：
- "minimum-stability": "dev" —— 放宽底线，允许加载任何稳定性版本
- "prefer-stable": true —— 默认倾向稳定版，避免意外装 dev
- 再对个别包加 @dev 或 @beta —— 精准控制例外情况
这样既保住了整体稳定性，又保留了必要时引入开发版的灵活性。
基本上就这些。stability-flags 是“点上突破”，prefer-stable 是“面上引导”，搭配 minimum-stability 才构成完整的稳定性策略。
