先记住一个关键点：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 提交。
