^1.2.3 等价于 >=1.2.3 =1.2.3 =0.5.1 =1.2.0 =0.0.4

Composer 不“处理”版本号，它只按 SemVer 规则做数学计算——你写的约束、包打的 tag、对方是否真守规矩，三者缺一不可。

^1.2.3 到底允许装哪些版本？

不是“大概兼容”，而是明确的不等式：^1.2.3 等价于 >=1.2.3 。它允许 1.2.4、1.9.9，但拒绝 2.0.0。

• ^1.2 自动补成 ^1.2.0，效果相同
• ^2 等价于 ^2.0.0 → 允许 2.99.99，但不会跨到 3.0.0
• 主版本为 0 时行为突变：^0.5.1 实际是 >=0.5.1 ，连 0.5.2 都可能破坏 API
• 写 ^0.0.1 几乎等于锁死——它只接受 0.0.1，改第三位都不行

~1.2.3 和 ^1.2.3 的锚点根本不在同一维度

^ 锚定主版本号（M），~ 锚定最左侧非零段（可能是 M，也可能是 M.N）。这不是松紧问题，是坐标系错位。

Workflow Decomposer

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

下载

• ~1.2.3 → >=1.2.3 （只放行 patch 升级）
• ~1.2 → >=1.2.0 （和 <code>~1.2.0 完全等价）
• ~0.0.4 → >=0.0.4 （能升到 0.0.9，但卡死在 0.0.x）
• 误写 ~1.2 本想“稳住 1.2.x”，结果它会装 1.2.99，而你以为它只到 1.2.10——这取决于作者怎么发版

为什么 composer install 装的不是你写的版本？

因为 composer.lock 永远优先于 composer.json 中的约束。你改了 "monolog/monolog": "^3.0"，lock 里还是 2.10.0，install 就只装 2.10.0。

• 想让新约束生效：运行 composer update monolog/monolog（精准更新）
• 不确定影响范围？先跑 composer update --dry-run
• 直接删 composer.lock 再 install 是高危操作——团队里不同人会装出完全不同的依赖树
• 用 composer show monolog/monolog -i 查真实安装版本，别信 composer.json 里写的

0.x 包的版本约束必须手动验证，不能靠符号自动兜底

^0.8.2 和 ~0.8.2 行为一致，都只放行 0.8.x。这不是 Composer 的 bug，是 SemVer 对「不稳定阶段」的硬性定义。

• 0.x 下任何 minor 变更都合法地破坏 API，^ 主动收紧就是为此
• 想支持 0.9.x 和 0.10.x？必须显式写 "~0.9.0 || ~0.10.0"，^ 帮不上
• 查一个包是否还在 0.x：看它的最新 stable tag，不是看你写的约束
• 依赖长期卡在 0.x 的包时，composer audit 比版本符号更重要——它能告诉你当前 lock 里有没有已知漏洞

真正容易被忽略的是：Composer 从不校验包作者是否守 SemVer。它只认数字，不读 CHANGELOG。你写的 ^2.8.0 很安全，但如果对方把破坏性变更塞进 2.8.5，Composer 就会照单全收。