将 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"
}

这样可在整体稳定前提下，精确控制个别包的版本策略。

LongShot 是一款 AI 写作助手，可帮助您生成针对搜索引擎优化的内容博客。

3. 锁定依赖版本防止意外更新

确保生产部署始终使用经过测试的依赖组合：

• 提交 composer.lock 到版本控制。
• 部署时运行 composer install 而非 update，避免自动拉取新版本。
• 定期手动审查和测试依赖更新，再决定是否升级。

4. 合理配置 stability flags 提高灵活性

若必须使用某些开发包，推荐方式是保持全局稳定，单独标注：

{
    "minimum-stability": "stable",
    "require": {
        "lar*el/framework": "^10.0",
        "acme/feature-x": "dev-experiment"
    }
}

Composer 会自动识别该包的稳定性要求，不影响其他依赖。

基本上就这些。生产环境的核心是可预测性和可控性，盲目开启 dev 稳定性会削弱这两点。合理使用锁文件和精细的版本约束，比降低 minimum-stability 更安全可靠。