Composer本身不支持灰度发布，但可通过~2.9.0（仅允许2.9.x补丁更新）、>=2.9（明确灰度起始边界）等精确版本约束，结合灰度/主干分支隔离、独立composer.lock、CI中--no-dev/--no-interaction还原及临时目录+原子mv切换，实现可控灰度升级。
Composer 本身不支持灰度发布，但你能用对版本约束、分支策略和 CI 流程，就等于实现了可控的灰度升级。
composer.json 里怎么写版本号才真正“灰度”
写错一个符号，可能直接跳过你想试的版本，或者升到不兼容的大版本。关键不是“能不能”，而是“怎么写才让 Composer 听懂你的边界”。
-
~2.9.0→ 等价于>=2.9.0 && ，只允许补丁更新（2.9.1、2.9.2），最保守，适合强锁定灰度范围 -
^2.9→ 允许所有 2.x 小版本（2.9.0 到 2.999.999），但不会进 3.0；注意：^0.9不会进0.10，^1.9却可能进1.10，行为不统一 -
>=2.9→ 最直白，无歧义，明确告诉 Composer：“2.9 开始都行，但别低于它”，推荐用于定义灰度起始点 - 避免只写
"monolog/monolog": "2.9"—— Composer 会把它当2.9.0.0处理，且不兼容任何后续补丁，实际锁死一个不存在的版本
为什么 composer update 总是跳过你指定的灰度版本
不是 Composer 故意绕开你，而是整个依赖图在“投票”。某个下游包可能硬性要求 psr/log:^1.0，而你想升到 ^2.1，结果 Composer 只能妥协回退到 1.0.0。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查谁在拉低版本：
composer depends psr/log列出所有依赖它的包及其约束 - 看当前装了啥、还能装啥：
composer show psr/log - 确认关键依赖是否声明兼容：打开
monolog/monolog的composer.json，检查其require是否已支持psr/log:^2.0 - 真正有效的灰度，必须从 root package（你的项目）开始收紧约束，并确保下游包已声明对新版本的兼容
不同环境如何走不同版本策略
Composer 没有 environment: production 这种原生字段，但你可以靠分支 + lock 文件 + CI 步骤组合出效果。
- 灰度分支的
composer.json用宽松约束，比如"vendor/pkg": "^1.2"；主干/生产分支则锁死"vendor/pkg": "1.2.3" - 所有环境都必须提交
composer.lock，但灰度分支的 lock 文件可以也应当和主干不同 - CI 构建生产镜像时，加
--no-dev和--no-interaction，强制只按 lock 文件还原，不被composer.json干扰 - 灰度环境 CI 应运行
composer update vendor/pkg --with-dependencies，而非全量update
上线前最关键的两个动作
灰度成功不等于可以上线。很多团队卡在这两步上：
-
composer install不能直接覆盖线上vendor/—— 它是就地更新，失败时会留下半更新状态，导致Class not found或undefined function错误 - 真正安全的做法是：在临时目录（如
/tmp/myapp-$(date +%s)）下执行composer install --no-scripts --no-plugins --prefer-dist，检查关键文件存在后，再用mv原子切换vendor/ - 灰度分支的
composer.lock必须独立提交，且 CI 构建灰度镜像时，必须确保--no-dev开启，否则require-dev包不会安装，线上根本加载不到你想试的新逻辑
