^1.2.3 等价于 >=1.2.3 <2.0.0，允许安装 1.2.3 至 1.999.999 的版本；~1.2.3 等价于 >=1.2.3 <1.3.0；~0.5.1 等价于 >=0.5.1 <0.6.0；^1.2.0 等价于 >=1.2.0 <2.0.0；^0.0.4 等价于 >=0.0.4 <0.1.0。
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 就会照单全收。
