^锚定主版本号，~锚定次版本号；^1.2.3等价于>=1.2.3 =1.2.3 =0.5.1
^ 和 ~ 的版本范围到底怎么算
很多人以为 ^ 是“宽松更新”，~ 是“保守更新”，其实它们锚点完全不同，不是松紧问题，而是坐标系差异。
^1.2.3 锚定主版本号 1，等价于 >=1.2.3 ；<code>~1.2.3 锚定最左侧非零段 1.2，等价于 >=1.2.3 。
0.x 版本是特例：^0.3.4 实际只允许 >=0.3.4 ，因为 SemVer 明确规定：主版本为 0 时，任何次版本变更都可能破坏 API。所以 <code>^0.3.4 不会升到 0.4.0，哪怕只是加了个新方法。
-
^2.8等同于^2.8.0，不是模糊匹配，它会装2.99.99，但绝不会跨到3.0.0 -
~2.8等同于~2.8.0→>=2.8.0 ，不是 <code>>=2.8.0 （常见误读） -
~0.0.4锚在第三位，允许升到0.0.9，但不会到0.1.0
Git Tag 才是真实版本来源
Composer 本身不生成 Tag，也不管理 Tag，但它只认轻量 Tag（git tag v1.2.3），且必须推送到远程仓库。Packagist 同步后才真正生效。
如果你打了 v1.2.3 却 composer require vendor/package:1.2.3 报错，大概率是以下某个环节断了：
- 用了
git tag -a v1.2.3（Annotated Tag），旧版 Packagist 可能因空 message 解析失败 - 只本地打 Tag，没执行
git push origin v1.2.3 - Packagist 仓库设置里没勾选 “Automatically update the package on new commits?”
- Tag 名含非法字符，比如
v1.2.3+build.1或v1.2.3-beta.1—— Packagist 会跳过这类标签 -
composer.json里写了"version": "1.2.4"，和 Tag 名不一致，导致同步被拒
为什么 composer install 装的不是你写的版本
因为 composer.lock 优先级永远高于 composer.json 中的约束。哪怕你把 "monolog/monolog": "^2.0" 改成 "^3.0"，只要 lock 文件里还记着 2.10.0，install 就只会装那个。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
想让新约束生效，有且仅有两种安全方式：
- 运行
composer update monolog/monolog—— 只更新该包及其依赖子图，保留其他包版本不变 - 运行
composer update --dry-run先看影响范围，确认无误再执行composer update
直接删 composer.lock 再 install 风险极高，尤其在团队协作中——不同人装出的依赖树可能完全不一致。
0.x 包的版本约束要格外小心
0.x 不是“还没发正式版”的客气话，而是 SemVer 定义的「不稳定开发阶段」。这意味着 ^0.5.1 实际等价于 >=0.5.1 ，而 <code>0.5.5 里删一个 public 方法，完全合法，但你的代码可能当场崩。
所以对长期卡在 0.x 的包（比如某些新兴组件或内部工具库），不能只看数字：
- 别盲目信
^，优先查它的 CHANGELOG、GitHub Releases 或 issue 讨论区 - CI 环境建议锁死开发依赖的完整版本，例如
"phpunit/phpunit": "10.4.2" - 生产环境若必须用 0.x 包，考虑用
~替代^，缩小升级范围，比如~0.5.1→>=0.5.1 ，至少比 <code>^0.5.1多一层心理缓冲
真正决定版本是否安全的，从来不是 ^ 或 ~ 的写法，而是包作者有没有守 SemVer —— Composer 只做计算，不替你把关。
