最干净的方式是在 require 字段中为特定包添加稳定性标记（如@beta、@dev、@rc），而不修改 minimum-stability 全局配置；@beta 兼容 alpha/beta，@dev 必须显式书写，@rc 大小写敏感且向下兼容，子依赖的 minimum-stability 可能覆盖父项目设置。
直接在 require 里写 @beta 或 @dev 就行，不用改全局配置
想只让某个包装 beta 版，其他包照常走 stable，最干净的方式就是不碰 minimum-stability，只在 require 字段里给它加稳定性标记。比如：
"require": {
"monolog/monolog": "^3.0@beta",
"symfony/console": "^6.4"
}
这里 monolog/monolog 会去匹配所有满足 ^3.0 的 -beta、-alpha 标签（因为 @beta 自动向下兼容），而 symfony/console 仍受默认 minimum-stability: stable 约束，只装正式版。
-
@beta不是“只装 beta”，而是“beta 及更不稳定的都可”——所以3.0.0-alpha1也会被接受 - 如果只想锁死某一个 beta tag，得写全：比如
"monolog/monolog": "3.0.0-beta2@beta" - 写了
@beta后，minimum-stability的值就完全不生效了——哪怕它是"stable"，也不拦这个包
dev-main@dev 必须带 @dev 后缀，否则一定失败
很多人写 composer require vendor/pkg:dev-main 报 No matching package found，根本原因不是包不存在，而是 Composer 在解析前先按 minimum-stability 过滤候选版本，而 dev-main 属于 dev 级别，默认被踢出候选池。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 正确写法只有这一种：
composer require vendor/pkg:dev-main@dev -
@dev是强制声明，不是可选修饰；漏掉就等于没授权 - 分支名本身（如
dev-main）只是定位依据，真正起放行作用的是末尾的@dev - 私有包或未索引包即使加了
@dev也可能失败，需确认repositories已正确定义
避免子依赖偷偷拉 dev 版的坑
你明明只给自己的 require 加了 @beta，结果 composer install 后发现锁文件里多了好几个 dev- 提交——大概率是某个子依赖（比如 vendor/pkg 的依赖）自己在 composer.json 里写了 "minimum-stability": "dev"，它会覆盖你项目的设置。
- 用
composer show -t vendor/pkg查看它的依赖树，重点扫一眼子依赖的composer.json内容 - 这种覆盖无法被父项目的
prefer-stable拦住，prefer-stable只影响“多个同级候选时选谁”，不阻止“把 dev 版放进候选池” - 临时解法：加
--with-all-dependencies更新时显式指定该包，缩小污染范围 - 长期建议：在 CI 中加检查，扫描
composer.lock里是否出现意外的dev-提交哈希
@RC 必须全大写，小写 @rc 直接被忽略
这是最容易踩的格式陷阱。@RC 是唯一要求大小写敏感的 stability flag。写成 @rc 或 @Rc，Composer 会当它不存在，退回到默认 @stable 行为，导致你以为开了闸门，其实什么都没放进来。
- 正确示例：
"some/pkg": "2.5.0-RC1@RC"或"some/pkg": "@RC" -
@RC向下兼容@beta和@alpha，所以2.5.0-beta2也能装上 - 错误写法：
"some/pkg": "2.5.0-rc1@rc"→ 静默 fallback 到 stable，可能装上2.4.0而不是你想要的 RC 版 - 验证是否生效：运行
composer show -a some/pkg | grep -i rc，看输出里有没有带-RC的版本行
minimum-stability 覆盖行为——它不报错、不警告，只默默把 dev- 提交塞进 composer.lock，上线前才暴露问题。
