Composer默认只装稳定版，无需额外配置；若误装dev版，主因是require中显式声明@dev、子依赖设minimum-stability:dev或composer.lock固化旧版本。

Composer 默认就只装稳定版，不需要额外配置。只要你没动过 minimum-stability，它就会跳过 dev-main、dev-develop、1.2.x-dev 这类开发版本，只选 stable、RC（注意必须全大写）、beta（需显式标注）等明确标记的发布态版本。 但现实中很多人还是装到了 dev 版——问题不在 Composer “失控”，而是你或依赖包主动开了门。

为什么明明没改设置，还是装了 dev 版？

常见源头不是全局配置错误，而是局部“授权”行为：

• 你在 composer.json 的 require 里写了 "vendor/package": "dev-main" 或 "^2.0@dev" —— 这是显式要开发版，Composer 只能照办
• 运行过 composer require vendor/package:dev-main —— 命令本身会把该包写成 dev-main 并改写 composer.json
• 某个依赖包自己的 composer.json 里声明了 "minimum-stability": "dev" —— 它会覆盖你项目的设置，导致你设了 stable 也拉了 dev 版
• CI 脚本用了 composer update --prefer-lowest 或 --with-all-dependencies，却没配 "prefer-stable": true，解析时退选了不稳定版本

怎样真正守住“只装稳定版”这条线？

靠组合策略，不是单点开关。必须同时满足以下三点：

• 删掉或注释掉 composer.json 中的 "minimum-stability" 字段（默认就是 "stable"，显式写反而容易误改）
• 在根级加 "prefer-stable": true（注意：必须和 require 同级，写在 config 或 extra 里完全无效）
• 检查所有 require 条目，确保没有 @dev、dev- 前缀、as 别名指向开发分支

改完后必须运行 composer update --lock，否则 composer.lock 仍锁着旧规则下的版本。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

遇到 dev 版误入，怎么快速定位和清理？

别急着删 vendor，先确认来源：

• 运行 composer show vendor/package 看当前装的是什么版本，带 +git 或 dev- 就是开发版
• 查是谁引入的：composer why vendor/package，输出里带 dev- 的那行就是源头
• 如果源头是另一个包（比如 foo/bar 依赖了 vendor/package:dev-main），就得去约上游改依赖声明

验证是否真生效，最可靠的方式是删掉 vendor 和 composer.lock，再跑一次 composer install —— 因为 composer.lock 有固化效应，哪怕配置已改对，它仍可能继续装旧的 dev 版。

最容易被忽略的其实是 composer.lock 的固化效应

哪怕你已正确配置并运行了 composer update --lock，如果 composer.lock 里还锁着 dev-main，下次 composer install 依然会装它。这不是配置失效，而是锁文件在“忠实地复现上次的结果”。生产环境部署前，务必确认锁文件里没有 dev- 字样。