minimum-stability 必须写在 composer.json 根对象顶层，与 require、autoload 同级；写在 config 或 extra 中会被忽略，且修改后需运行 composer update --lock 生效。
minimum-stability 写在哪？位置错就完全不生效
它必须是 composer.json 根对象的顶层字段，和 require、autoload 同级。写在 config 里、extra 里、甚至 require 里面，Composer 都会直接忽略。
- ✅ 正确位置：
{<br> "minimum-stability": "beta",<br> "prefer-stable": true,<br> "require": { ... }<br>} - ❌ 常见错误：把
minimum-stability塞进"config": { ... }或"extra": { ... }中 - ⚠️ 改完后必须运行
composer update --lock（或composer update），否则composer.lock仍按旧策略锁版本，新设置形同虚设
设成 beta 后，为什么还是装不上某个包？
minimum-stability 不是“开关”，而是“过滤器”——它只放行稳定性 ≥ 当前值的版本。设为 "beta"，不代表所有包都能自动升到 beta；它只允许 Composer 在解析 "monolog/monolog": "^3.0" 这类无后缀约束时，考虑 v3.0.0-beta1，但前提是该包真有这个标签的版本。
- 先查真实可用版本：
composer show -a monolog/monolog，看输出里有没有带(beta)的行 - 如果只有
v2.10.0 (stable)和dev-main (dev)，那即使minimum-stability是dev，"^3.0"也匹配不到任何东西——因为根本没 v3.x 的发布 - 报错
Could not find a version of package matching your minimum-stability，本质是“有策略、无候选”，不是配置失败
全局设 dev 还是单个包加 @dev？风险差很远
设 "minimum-stability": "dev" 会让所有未加后缀的依赖（比如 "phpunit/phpunit": "^10.0"）都可能拉到 dev-main，哪怕它只是个临时分支。而用 "phpunit/phpunit": "dev-main@dev"，只影响这一个包，其他依赖照常走 stable。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 推荐优先用 per-package 方式：
"laravel/framework": "^11.0@beta"或"spatie/laravel-ray": "dev-main@dev" - 全局设
dev仅适合本地原型验证，上线前务必改回stable并清理 lock 文件 -
@dev和@beta不能混用，如"v2.0.0-beta1@dev"会解析失败；选一个就够了
prefer-stable: true 不是可选项，是稳定性的安全带
不加 "prefer-stable": true，哪怕你设了 "minimum-stability": "beta"，Composer 也可能在 v2.4.0 (stable) 和 v2.5.0-beta3 (beta) 之间选后者——只因它“更新”。这不是 bug，是设计行为。
-
prefer-stable: true的作用是：在满足minimum-stability的前提下，优先挑更稳定的那个可用版本 - 它必须和
minimum-stability同时存在才有效；单独写它没意义 - 线上项目建议固定组合：
"minimum-stability": "stable",<br>"prefer-stable": true
——这样连@beta都得显式写，反而最可控
最容易被忽略的一点：稳定性标签（stable、beta、RC）是 Packagist 上每个版本自己带的元信息，不是你写了 @beta 就能“变出来”的。它取决于包作者是否打了对应 tag 或 push 了对应 branch。所以出问题时，第一反应不该是改配置，而是先 composer show -a 看真实世界里有什么。
