prefer-stable 单独设为 true 无效，必须与 minimum-stability 配合使用；它仅在满足二者门槛的多个候选版本中优先选更稳定者，且必须运行 composer update --lock 才生效。
prefer-stable 单独设为 true 没效果，必须和 minimum-stability 配合使用，且改完后不运行 composer update --lock 就等于没改。
prefer-stable 不是开关，只影响版本排序
它只在多个满足 require 约束、又都符合 minimum-stability 门槛的版本中起作用。比如你写 "monolog/monolog": "^3.0"，同时有 3.5.0（stable）和 3.6.0-beta1（beta），且 minimum-stability 是 beta，这时 prefer-stable: true 才会让 Composer 选 3.5.0。
以下情况它完全不干预：
- 你在
require里明写"some/pkg": "dev-main"或"some/pkg": "@dev" -
composer.lock已锁死一个dev版本，你只跑composer install - 某个依赖包自己的
composer.json设了"minimum-stability": "dev"，它的子依赖可能绕过你的偏好
正确配置位置和结构
prefer-stable 必须放在 composer.json 的根对象层级，和 require、minimum-stability 并列——塞进 "config" 里就彻底失效。
推荐的最小安全组合是：
{
"minimum-stability": "stable",
"prefer-stable": true,
"require": {
"php": "^8.1",
"monolog/monolog": "^3.0"
}
}
注意："minimum-stability": "stable" 是底线，"prefer-stable": true 是优化策略；漏掉前者，后者基本没意义。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
生效必须靠 composer update --lock
改完 composer.json 后，仅 composer install 不会重算依赖，composer update 也不够保险——必须加 --lock 参数，强制更新 composer.lock 文件。
常见误操作：
- 只改 JSON 就以为完事了
- 运行
composer update monolog/monolog却漏掉其他包，导致部分依赖仍按旧规则解析 - CI 环境没同步这个命令，本地装的是 stable，CI 装的是 dev
验证是否真生效
最可靠方式：删掉 vendor 和 composer.lock，再执行 composer install。看装出来的包有没有 dev-、-beta、-rc 这类后缀。
快速检查已安装包来源：
composer show monolog/monolog
输出里如果带 source 字段且 URL 含 dev- 或分支名，说明 prefer-stable 没拦住——优先查 require 项是否显式写了不稳定标记，再确认 composer.lock 是不是上次用旧配置生成的。
真正容易被忽略的点是：稳定性控制不是单点配置问题，而是 minimum-stability + prefer-stable + require 写法 + composer.lock 状态 四者联动的结果。少一个环节，行为就不可控。
