告别不可靠依赖：配置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 时，拉取的还是那个可能已经失效的旧提交。因此，清理工作必须落实到锁文件的内容本身，这才是治本之策。
