告别不可靠依赖：配置Composer稳定性过滤标签屏蔽开发版

告别不可靠依赖：配置Composer稳定性过滤标签屏蔽开发版

生产环境必须屏蔽开发版，但这事儿，光靠全局设置 minimum-stability 为 stable 远远不够——它更像一个“准入标准”，却管不了那些“持证插队”的。真正要筑起防线，得靠 prefer-stable: true 加上显式约束的组合拳，否则，dev-main 这类开发分支，随时可能被某个依赖悄悄带进你的项目。

为什么 minimum-stability 设成 stable 还会装上 dev-main

问题的核心在于，很多人误把 minimum-stability 当成了“最高限制”，其实它只是个“最低门槛”。什么意思呢？只要某个包在依赖声明里白纸黑字地写了 "vendor/pkg": "dev-main" 或者 "vendor/pkg": "^2.0@dev"，Composer 就会认为这是你的明确意图，从而照单全收，完全无视你全局设的那个 stable。

• minimum-stability 只对那些“没把话说死”的约束有效，比如只写了 "vendor/pkg": "^2.0" 的。
• 一旦任何地方出现了 @dev、dev-main 这类显式标记，对应的包就直接获得了“免检通行证”。
• 更隐蔽的威胁来自传递依赖：你自己没写 dev，但你依赖的A包，可能在它自己的 composer.json 里声明了 "minimum-stability": "dev"，那么它引入的子依赖B，就很可能以开发版的形式混进来。

如何真正屏蔽所有 dev 分支包（包括传递依赖）

很遗憾，没有一键解决所有问题的魔法开关。但别担心，一套可落地的三层拦截策略，足以构建稳固的防线：

• 基础防线：保持根目录 composer.json 中的 "minimum-stability": "stable"（即使不写，默认也是它）。这是第一道关。
• 主动拦截：在 config 段加 "platform-check": false 对屏蔽开发版无效。真正有效的方法，是针对已知的问题包，使用 replace 声明进行“占位”。例如：

  "replace": {
    "vendor/pkg": "*"
  }

  再配合 composer update --with-dependencies 来触发冲突检测（此方法需谨慎，仅适用于明确要排除的特定包）。
• 最终防线：在CI/CD流程中加入硬性检查。一句简单的命令：grep -q '"version":"dev-' composer.lock && exit 1，就能确保一旦发现开发版踪迹，构建直接失败，从根本上杜绝其上线可能。

composer show -a 查出来的 dev-main (dev) 能不能信

能查到，绝不等于能安全安装。这个命令的输出，仅仅说明Packagist的索引里存在这个分支。它能否被成功引入，还得看下面三件事：

• 该分支的 composer.json 文件语法是否完全合规（缺少 autoload 或 name 等关键字段，Packagist可能会静默跳过）。
• 代码仓库是否公开，或者你的 auth.json 是否配置了正确的访问令牌（私有GitLab/GitHub仓库最容易卡在这一步）。
• 该分支自身的 composer.json 是否用 minimum-stability 限制了自己（比如它自己设成了 "minimum-stability": "beta"，那 dev-main 反而不会被识别为有效候选版本）。

所以说，composer show -a 只是个侦查起点，远非最终结论。看到 dev-main (dev) 后，务必再执行一次 composer require vendor/pkg:dev-main --dry-run --stability=dev 来验证依赖解析能否真正成功。

上线前清理 dev 包的实操步骤

清理工作，切忌只动代码。锁文件 composer.lock 里记录的提交哈希，才是更顽固的存在。按这个步骤来，才能彻底清理：

• 确认现状：运行 composer show vendor/pkg，仔细查看输出中的 versions 行是否包含 dev- 前缀，或 reference 字段（这指向具体提交）。
• 强制切换：执行 composer require vendor/pkg:^2.5（注意，不要带 @dev 后缀，也不加 --stability 参数），强制将其约束到稳定的语义化版本。
• 检查锁文件：打开 composer.lock，搜索 "vendor/pkg" 段落，确认其中的 version 字段已经变成了类似 "2.5.3" 的版本号，而不是 "dev-main" 或带着一长串 "reference": "a1b2c3d"。
• 最终安装：执行 composer install --no-dev --optimize-autoloader，确保 vendor 目录里没有混入任何开发版的代码。

这里有个极易被忽略的关键点：composer.lock 里锁定的，是精确的提交哈希，而不是分支名。这意味着，即使远程仓库的 dev-main 分支被强制推送（force-push）覆盖了，你锁文件里旧的哈希记录依然有效，下次执行 install 时，拉取的还是那个可能已经失效的旧提交。因此，清理工作必须落实到锁文件的内容本身，这才是治本之策。