Composer 的 ^ 版本约束不锁小版本，仅限制主版本不变且次版本不降级，如 ^2.3.1 允许 2.3.9、2.4.0，但禁止 3.0.0 或 2.2.0；其依据语义化版本规则，但因部分包未严格遵循，小版本升级易引发兼容性问题。
Composer 的 ^ 版本约束到底锁不锁小版本？
它**不锁小版本**，但会严格限制主版本和次版本的升级范围。比如 ^2.3.1 允许安装 2.3.9、2.4.0，但不会装 3.0.0 或 2.2.0。
这个行为叫“兼容性语义化版本”，核心逻辑是：只要主版本号不变，且次版本号没降级，就认为 API 向前兼容。但现实里很多包并不严格守 semantic versioning，所以 ^ 带来的小版本升级常引发意外 break。
-
^1.0.0等价于>=1.0.0 -
^0.5.0等价于>=0.5.0 （0.x 系列更保守） -
^0.0.1等价于>=0.0.1 （零点零系列只允许补丁级更新）
怎么彻底禁用 ^ 自动升级？
最直接的办法是改写版本号为精确匹配，去掉脱字号。但要注意：Composer 默认生成的 composer.json 会自动加 ^，除非你手动干预。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 安装时加
--no-dev不影响，关键在--prefer-dist和--ignore-platform-reqs也无关 - 正确做法是：用
composer require vendor/package:1.2.3（不带^），Composer 会存成"vendor/package": "1.2.3" - 如果已存在
^1.2.3，直接编辑composer.json把它改成"1.2.3"，再运行composer update vendor/package - 批量去脱字号？别用 sed 直接扫，
composer.json是 JSON，结构敏感；推荐用composer normalize配合人工校验
composer.lock 能不能代替版本号锁定？
能，但只对当前项目生效，且依赖你提交并维护它。一旦删掉 composer.lock 或在没 lock 的机器上运行 composer install，就会按 composer.json 里的约束重新解析版本 —— 此时 ^ 又开始起作用。
-
composer install严格按composer.lock安装，不管composer.json写了什么约束 -
composer update会忽略 lock，重新走版本解析逻辑，^约束立刻生效 - CI/CD 中漏传
composer.lock是常见翻车点，尤其私有镜像源未同步新 tag 时，可能装出本地没测过的组合
为什么有些团队坚持用 ~ 而不是 ^？
因为 ~ 锁得更死：~1.2.3 等价于 >=1.2.3 ，连次版本都不让升；而 <code>^1.2.3 是 >=1.2.3 。对强依赖稳定性、又不想手动 pin 每个小版本的项目，<code>~ 是折中选择。
-
~1.2→>=1.2.0 -
~1→>=1.0.0 （此时和 <code>^1效果一样） - PHP 8+ 项目中，某些扩展（如
ext-gd）的 minor 升级可能引入函数弃用警告，~能规避这类非破坏但烦人的变更
真正难处理的从来不是符号本身，而是团队对“谁该负责版本兼容性”的默认假设不一致 —— 开发者觉得包作者守 semver，运维觉得所有小版本都该测试，而 Composer 只是把这层张力原样暴露出来。
