Composer 严格依据 SemVer 语义化版本规则计算兼容性：^ 锚定主版本号（如 ^1.2.3 兼容 1.x.x），~ 锚定最左侧非零段（如 ~1.2.3 兼容 1.2.x，~0.3.4 兼容 0.3.x）。
Composer 不是“猜”版本兼容性，而是严格按 SemVer 三位数字的语义规则做数学计算——主版本变=不兼容，次版本变=兼容新增，修订号变=纯修复。
^ 和 ~ 的锚点逻辑完全不同
很多人以为 ^ 是“激进”，~ 是“保守”，其实它们根本不是同一套坐标系：^ 锚定的是 主版本号（即 M），~ 锚定的是 最左侧非零段（可能是 M，也可能是 M.N）。
-
^1.2.3→>=1.2.3 （锚在 <code>1，允许1.9.9） -
~1.2.3→>=1.2.3 （锚在 <code>1.2，只到1.2.99） -
~1.2等价于~1.2.0→>=1.2.0 ，不是 <code>>=1.2.0 （常见误读） -
^0.3.4→>=0.3.4 （0.x 下 <code>minor也视为 breaking，所以^主动收紧） -
~0.0.4→>=0.0.4 （锚在第三位，能升到 <code>0.0.9，但不会到0.1.0）
0.x 版本是特例，不是 bug 是设计
只要主版本是 0，所有版本都属于“不稳定开发阶段”，SemVer 明确规定：任何 minor 变更都可能破坏 API。Composer 完全尊重这一点。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
^0.5.1≠>=0.5.1 ，而是 <code>>=0.5.1 -
^0.0.1实际只匹配0.0.1本身——改第三位都算 breaking - 如果你依赖一个长期卡在
0.x的包，用^并不能“自动更新”，它比你想象中更窄 - 遇到
0.x包，优先查它的 CHANGELOG 或 issue，别只看数字
版本约束失效的常见原因
不是 Composer 算错了，而是现实没按 SemVer 走。你写的 ^2.8 很安全，但对方发版不守规矩，就白搭。
- 包作者在
2.8.5里删了一个你正在用的 public 方法（违反 SemVer，但 Composer 不拦） - 包没打 Git tag，Composer 靠
composer.json里的"version"字段推断，而这个字段可能手写错误 - 用了
dev-main或*这类无约束写法，直接绕过所有 SemVer 规则 -
composer.lock没提交，导致不同人composer install装出不同版本
真正关键的不是记住 ^ 和 ~ 的换算表，而是理解：Composer 的版本决策永远基于两个事实——你写的约束 + 包声明的 version + 它是否真守 SemVer。三者缺一不可。一旦其中一环松动，再严谨的约束也没用。
