composer install 默认只装 stable 版本，严格按 composer.lock 记录的版本安装，require 下包仅接受 stable，require-dev 则可拉取 beta/dev 版本；需设 "minimum-stability": "stable" 统一约束，且 lock 文件必须提交以保证环境一致。
composer install 默认只装 stable 版本
除非显式指定 --prefer-source、--prefer-dist 或 --dev，否则 composer install 会严格按 composer.lock 中记录的版本安装，且所有包都必须是 stable 状态（即非 dev-、alpha、beta、rc 标签）。这跟“是否启用稳定版偏好”无关，而是 lock 文件本身的约束结果。
require 和 require-dev 的稳定版行为不一致
require 下的包默认只接受 stable 版本；而 require-dev 在执行 composer update 时，会尝试拉取最新可用版本——包括 beta 或 dev-main，只要它们满足版本约束。这不是 bug，是设计使然：开发依赖本就允许更激进的更新策略。
- 若想统一约束 dev 包也只用 stable，需在
composer.json顶层加："minimum-stability": "stable" - 若某个 dev 包确实需要
dev-master（比如正在调试的 fork），可单独设"prefer-stable": true+ 显式版本号："phpunit/phpunit": "dev-main as 10.0.0" - 注意：
"minimum-stability": "stable"不能被require-dev中的dev-版本覆盖，否则composer update直接报错
CI/CD 环境中 --no-dev 会跳过 require-dev，但不影响 stability 判断
composer install --no-dev 只是跳过 require-dev 字段里的包，不会改变 require 部分的解析逻辑。也就是说，即使你在 CI 中禁用了 dev 包，require 里写的 "monolog/monolog": "^3.0" 依然只会装 3.x 的 latest stable，不会因为环境不同就去拉 3.0.0-RC1。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 真正影响稳定性的是
composer.lock是否已提交——它锁死的是具体 commit hash 或 tag，不是“稳定与否”的抽象概念 - 如果 lock 文件没提交，CI 执行
composer install时会 fallback 到composer update行为，这时minimum-stability设置才起作用 - 所以团队协作中，
composer.lock必须 git commit，否则不同机器上 install 结果可能不一致
本地开发时 prefer-stable 和 minimum-stability 的组合容易踩坑
这两个配置常被混用，但作用完全不同：prefer-stable 是“在多个满足约束的版本中优先选 stable”，而 minimum-stability 是“拒绝低于该等级的所有版本”。它们叠加时，行为并不直观。
-
"prefer-stable": true, "minimum-stability": "dev"→ 允许装dev，但有stable就优先选它 -
"prefer-stable": false, "minimum-stability": "stable"→ 只能装stable，且不关心谁更“新” - 最危险的是
"minimum-stability": "dev"却没配prefer-stable：composer update可能直接把laravel/framework拉成dev-main，哪怕你写的是"^10.0"
生产环境部署前务必确认 composer.json 中没有 minimum-stability 设为 dev 或 alpha —— 这种配置在本地测试时可能没问题，上线后却可能导致不可控的代码变更。
