minimum-stability 设为 RC 仅降低全局最低稳定性要求，并非强制启用 RC；需在 require 中显式指定如 "^2.0@RC" 或 "1.0.0-RC1" 才能安装 RC 版本。
为什么 minimum-stability 设成 RC 后还是装不到 RC 包？
因为 minimum-stability 只是全局“最低允许稳定性”，不是“强制启用 RC”；真正起作用的是包自身的 version 约束或 require 中是否显式带了 -RC 后缀。比如写 "monolog/monolog": "^3.0"，即使你设了 minimum-stability: RC，Composer 默认仍只找 stable 版本（如 3.0.0），不会自动降级去拉 3.0.0-RC1。
实操建议：
- 必须在
require里明确写出 RC 版本号，例如"symfony/console": "6.4.0-RC1" - 或者用通配符加稳定性后缀：
"symfony/console": "^6.4@RC"（@RC显式要求该包按 RC 稳定性解析） -
minimum-stability设为RC后，所有未显式标注稳定性的依赖，才会把 RC 当作可接受选项 —— 但它不改变版本号匹配逻辑
composer.json 里怎么安全地设 minimum-stability 为 RC
直接改根 composer.json 的顶层字段就行，但要注意它会影响所有依赖，包括你没手动指定版本的那些间接依赖。一旦某个上游包发布了 RC 版，而你的项目又没锁死版本，Composer 就可能自动升级过去 —— 这在 CI 或生产环境容易出问题。
实操建议：
- 只在开发/测试分支中设置：
"minimum-stability": "RC" - 同时加上
"prefer-stable": true，让 Composer 在满足minimum-stability前提下，优先选 stable 版本（比如有3.0.0就不用3.0.0-RC2） - 不要在
composer.lock提交前忽略警告 —— 如果看到Resolving packages... found X versions, using Y-RC，得确认这是你预期的行为
用 composer require 安装 RC 包时的常见错误
最典型的是执行 composer require vendor/package ^2.0 却装了 stable 版，而不是你想要的 RC。这不是 bug，是默认行为。另一个坑是用了 --stability=RC 但没配合版本约束，结果命令失败。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 正确写法：
composer require "vendor/package:^2.0@RC"（引号防止 shell 解析错误） - 错误写法：
composer require vendor/package:^2.0 --stability=RC——--stability参数已被弃用，Composer 1.10+ 不再支持 - 如果包还没发布 RC，但你本地有分支，可用
composer require vendor/package:dev-main#commit-hash临时替代
RC 版本带来的兼容性和锁定风险
RC 是“功能冻结、仅修 bug”的阶段，理论上 API 稳定，但 Composer 不校验语义化版本规则是否被遵守。更麻烦的是：RC 版本号不参与 ^ 或 ~ 的向上兼容计算。比如 "package": "^1.0.0-RC1" 不会匹配 1.0.0-RC2，必须写成 "^1.0.0@RC" 或显式列全。
实操建议：
- CI 流水线里跑
composer install前，务必确认composer.lock已提交且包含目标 RC 版本 —— 否则不同机器可能拉到不同 RC - 避免在
require-dev外使用 RC，尤其不要让生产环境依赖链里混入 RC 包 - RC 包的
autoload或replace配置如果有变更，可能破坏插件机制，建议装完立刻跑composer dump-autoload -o
RC 不是 beta，但也不是 stable；它离正式版只差最后一道人工验证。你设了 minimum-stability，只是打开了门，真正走进去的每一步，都得靠版本字符串和 lock 文件来卡住。
