在require中为特定包添加@beta或@dev是唯一可靠方式，可绕过minimum-stability全局限制；@beta兼容alpha/beta/RC，@dev必须显式书写，@RC大小写敏感，精确锁定需写全版本号如"3.0.0-beta2@beta"，子依赖自设minimum-stability会覆盖父项目配置。
require里加@beta/@dev是唯一可靠方式
全局设置minimum-stability会影响所有包，容易误伤；真正想只让某一个包走非稳定版，必须在require字段里直接写"monolog/monolog": "^3.0@beta"。这样Composer会跳过minimum-stability检查，只对该包启用宽松匹配。
常见错误现象：composer require vendor/pkg:dev-main报No matching package found——根本原因是没加@dev后缀，解析器提前过滤掉了候选版本。
-
@beta实际兼容alpha、beta、RC，不是“仅beta” -
@dev必须显式写出，dev-main本身不带放行权限 -
@RC大小写敏感，@rc无效
锁死某个具体预发布版本要写全
如果只想用3.0.0-beta2，不能只写"monolog/monolog": "^3.0@beta"，否则3.0.0-alpha1也可能被选中。必须写成"monolog/monolog": "3.0.0-beta2@beta"，用精确版本号+稳定性标记双重锁定。
这种写法下，Composer不会尝试升级，composer update monolog/monolog也不会改变它，连composer outdated提示的更新也不会应用——这是预期行为，不是bug。
子依赖可能偷偷引入dev版
你只给自己的require加了@beta，结果composer.lock里冒出一堆dev-提交？大概率是某个子依赖（比如vendor/pkg）自己在composer.json里写了"minimum-stability": "dev"，它会覆盖你项目的设置。
排查方法：composer show -t vendor/pkg看依赖树，重点扫子依赖的composer.json内容。
-
prefer-stable拦不住这种覆盖，它只影响“多个同级候选时选谁” - 临时解法：更新时加
--with-all-dependencies缩小污染范围 - 长期建议：CI中加脚本扫描所有
composer.json里的minimum-stability
私有包或未索引包加@dev仍可能失败
@dev只是告诉Composer“允许这个包走不稳定通道”，但不保证包存在。如果包没在Packagist注册，或你没在repositories里正确定义源，依然会失败。
典型场景：公司内部GitLab私有仓库的dev-main分支。
- 必须确保
repositories已声明，且type正确（如vcs） - URL路径需指向仓库根，不是某个子目录
- 首次安装建议加
--prefer-source，避免压缩包缓存干扰
minimum-stability，父项目就基本失去控制权。 
