Composer忽略不稳定包的原因及稳定版与镜像设置

先记住一个关键点：minimum-stability 是硬性过滤闸门，并非“偏好”或“建议”。它直接决定哪些版本能进入候选池——低于该稳定级别的包，例如 dev-main、2.0.0-beta1，根本不会被 Composer 扫描，连远程请求都不会发起。你看到的 “Could not find package” 错误，通常不是网络问题，而是这个闸门已经被彻底关闭。

通俗来说，这个过滤器默认设置为 stable 级别，而 dev-main 这类开发分支连门槛都摸不到。Composer 解析依赖分两步进行：先过滤，再匹配。如果包没有进入候选池，即使你在版本号后加上 @dev 后缀也无法挽救。

为什么 composer require vendor/pkg:dev-main 总是失败？

默认情况下 minimum-stability 为 "stable"，而 dev-main 不满足该门槛。Composer 解析过程分为两步：先过滤，再匹配。如果包未进入候选池，@dev 后缀也无法帮它通过。

• dev-main 必须写成 dev-main@dev —— @dev 不是可选修饰符，而是强制声明“我接受这个包的开发版本”
• 小写 @rc 会被完全忽略，回退到 @stable；必须使用 @RC 才会被正确识别
• 私有仓库若未配置 dist，即使添加了 @dev，也会卡在 Skipped branch 或报 no dist defined
• 已存在的 composer.lock 会固化旧策略；删除它再执行 composer update vendor/pkg --with-all-dependencies 才能重新计算依赖

prefer-stable 为什么看起来不起作用？

它只在多个候选版本都满足 minimum-stability 门槛时才会生效。例如，将 "minimum-stability": "beta" 设置后，同时存在 2.0.0（stable）和 2.0.0-beta1（beta），prefer-stable 才会让 Composer 优先选择前者。

• 仅设置 "prefer-stable": true 而不调整 minimum-stability，基本无效——因为默认值已经是 stable，候选池里本来就没有其他版本
• prefer-stable 必须写在 composer.json 的根层级，与 require 平级；如果错误地写入 "config": {...} 中，该配置会被完全忽略
• 它不能降级已安装的不稳定包；想要切换回稳定版，必须显式运行 composer update vendor/pkg 或删除 vendor 目录重新安装

生产环境如何锁定只安装稳定版本？

需要依靠配置组合来实现，而不是单一开关。

• 必须同时设置 "minimum-stability": "stable" 和 "prefer-stable": true ——前者拦截所有非 stable 版本，后者确保即使约束宽松也不会意外拉取到 RC 版本
• 所有 require 条目都不能带有 @dev、@beta 等显式降级标记，否则会覆盖项目级设置
• 上线前务必检查 composer.lock 中目标包的 version 字段：如果显示为 "dev-develop" 或 "reference": "a1b2c3d"，说明仍锁定的是开发版本，需要使用 composer require vendor/pkg:^2.5 显式切回稳定版
• 镜像源必须全局生效：执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/；在 CI 构建中不要轻信“已经配过”，建议在脚本开头加一行重置命令更可靠

真正容易被忽略的是 composer.lock 的固化效应——它不关心你当前的配置，只认自己锁定的版本。即使你修改了 composer.json 并执行了 composer update --lock，如果部署时只运行 composer install，它仍然会安装 lock 文件中记录的 dev-main 提交。