默认情况下 composer update 会按 composer.json 版本约束安装最新兼容版本，包括次要和修订版本但不跨主版本；强制只升次要版本需将 "^2.3.0" 改为 "2.3.*" 并执行 composer update --with-all-dependencies。
composer update 默认升级哪些版本
默认情况下 composer update 会按 composer.json 中的版本约束（如 "^2.3.0" 或 "~2.3.0"），尽可能安装最新兼容版本——这包括次要版本（minor）和修订版本（patch），但不跨主版本（major）。比如 "^2.3.0" 允许升级到 2.9.5，但不会升到 3.0.0。
但要注意：如果某包在 composer.lock 中锁的是 2.3.0，而仓库已有 2.8.1，composer update 就会直接跳过去——它不区分“只升 minor”还是“只升 patch”，只要符合约束就全量更新。
如何强制只升级次要版本（不升修订版）
Composer 本身没有 --only-minor 这类开关，但可以通过组合约束 + 锁定策略实现效果。核心思路是：让所有依赖显式锁定在次版本号层级，同时禁用 patch 级自动漂移。
- 把
composer.json中的"^2.3.0"改成"2.3.*"—— 这表示允许2.3.0到2.3.999，但不会跨到2.4.0 - 运行
composer update --with-all-dependencies（或逐个指定包名）来刷新 lock 文件，确保新约束生效 - 之后再执行
composer update vendor/package，就只会匹配2.3.x范围内的最新版（如从2.3.1升到2.3.7）
注意："2.3.*" 在语义化版本中等价于 >=2.3.0 ，它比 <code>~2.3.0 更严格（后者等价于 >=2.3.0 ）。
为什么不用 ~2.3.0 实现“只升 minor”
~2.3.0 实际含义是“允许升到下一个次版本前的任意修订版”，即 >=2.3.0 —— 它确实能限制在 <code>2.3.x，但问题在于：如果你原本装的是 2.3.0，而 2.4.0 已发布，~2.3.0 不会升；可一旦你手动装过 2.3.5，下次 update 就可能升到 2.3.9，这仍是 patch 升级，不是你想要的“仅 minor”控制粒度。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
真正想“只升 minor”，本质是要把修订版升级行为交给人工决策。所以更稳妥的做法是：
- 开发阶段用
"2.3.*"锁定次版本 - 需要升 minor 时，手动改
"2.3.*"为"2.4.*"，再composer update - CI/CD 流程中禁止无约束的
composer update，全部走显式版本变更 + PR 审核
常见误操作与报错提示
直接运行 composer update --minor-only 会报错：Command "minor-only" is not defined. —— 这个参数根本不存在。
另一个典型错误是混用约束：比如写成 "^2.3"（缺补零），Composer 会解析为 "^2.3.0"，仍可能升到 2.9.x；而 "2.3"（无符号）会被当作精确版本，导致 composer update 不做任何升级。
最易忽略的一点：子依赖（transitive dependencies）不受你主 composer.json 约束直接影响。即使你写了 "2.3.*"，若某个上游包声明了 "monolog/monolog": "^3.0"，它仍可能带入 3.x。这时需用 composer prohibits monolog/monolog 查依赖链，再用 replace 或 conflict 段干预。
