将 Composer 的 minimum-stability 设为 dev 会引入不稳定依赖，导致生产环境出现运行时错误、接口断裂和隐藏缺陷。应设为 stable 并显式声明个别开发包，结合 composer.lock 锁定版本，确保部署可预测与可控。
将 Composer 的 minimum-stability 设置为 dev 意味着项目可以安装开发状态的依赖包，例如带有 dev- 前缀的分支、alpha、beta、RC 版本等。虽然这在开发阶段有助于使用最新功能或修复，但在生产环境中启用此配置会带来显著风险。
1. 使用不稳定版本带来的潜在问题
设置 "minimum-stability": "dev" 会使 Composer 默认接受所有稳定性低于 stable 的版本，包括：
- 未完成的功能：某些包可能尚未完成核心逻辑，导致运行时错误。
- 频繁 Breaking Changes：开发版本常出现接口变更，升级后可能破坏现有代码。
-
缺乏充分测试：开发者可能未对
dev-master进行完整测试，存在隐藏 bug。 - 文档不匹配：文档通常基于稳定版编写，与 dev 版行为不一致。
2. 生产环境应优先使用稳定依赖
为了保障线上服务的可靠性，建议采取以下做法：
- 将
minimum-stability设为 stable，仅允许安装正式发布版本。 - 如需引入特定开发版本，使用
require显式指定，并附加稳定性标识，例如：
{
"require": {
"vendor/package": "dev-main as 1.2.0"
}
}
或通过 @dev 注明个别需求：
"require": {
"vendor/special-package": "^2.0@dev"
}
这样可在整体稳定前提下，精确控制个别包的版本策略。
3. 锁定依赖版本防止意外更新
确保生产部署始终使用经过测试的依赖组合：
- 提交
composer.lock到版本控制。 - 部署时运行
composer install而非update，避免自动拉取新版本。 - 定期手动审查和测试依赖更新，再决定是否升级。
4. 合理配置 stability flags 提高灵活性
若必须使用某些开发包，推荐方式是保持全局稳定，单独标注：
{
"minimum-stability": "stable",
"require": {
"laravel/framework": "^10.0",
"acme/feature-x": "dev-experiment"
}
}
Composer 会自动识别该包的稳定性要求，不影响其他依赖。
基本上就这些。生产环境的核心是可预测性和可控性，盲目开启 dev 稳定性会削弱这两点。合理使用锁文件和精细的版本约束，比降低 minimum-stability 更安全可靠。
