^1.2.3 允许升至 1.99.999 但不跨 2.0.0，因 semver 中 ^ 仅允许 major 不变的 minor/patch 升级；~1.2 限于 1.2.x，~1.2.3 仅从 1.2.3 起补丁升级；0.x 不适用 ~；php 版本同理用 "^8.1" 表示 >=8.1。
别用 ^ 或 ~ 盲目套，先看包本身守不守 SemVer；生产环境必须靠 composer.lock 固化，不是靠字符串“看起来安全”。
为什么 ^1.2.3 会升到 1.99.999 却卡在 2.0.0
^ 的语义是 “允许所有向后兼容的升级”，它按语义化版本（MAJOR.MINOR.PATCH）放行：只要 MAJOR 不变，MINOR 和 PATCH 都可升。所以 ^1.2.3 等价于 >=1.2.3 。
但现实里很多包根本不守规则——比如在 1.8.x 里删掉一个 public 方法，却没升主版本。这时 ^ 就变成隐患。
- 查真实行为：运行
composer show monolog/monolog，看它最近几个 MINOR 版本的 CHANGELOG 是否含BREAKING - 看社区反馈：搜 GitHub issues 里有没有 “1.8 → 1.9 broke X” 这类报告
- 保守策略：若包维护松散，直接写死
"monolog/monolog": "1.8.5"，比^1.8更可靠
~1.2.3 和 ~1.2 的区别到底在哪
~1.2.3 锁死 MINOR=2、PATCH≥3，只允许 1.2.3 到 1.2.999；而 ~1.2 是 >=1.2 ，等价于 <code>1.2.*，允许任意补丁升级。
常见踩坑：写了 "some/pkg": "~1.2.3"，结果该包最新版是 1.2.2 或 1.3.0，Composer 就报 Could not find package —— 因为两者都不满足 >=1.2.3。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
~1.2表示“我验证过整个 1.2.x 都可用” - 用
~1.2.3表示“只有从 1.2.3 开始的那个补丁才修了我遇到的 bug” - 别对 0.x 包用
~：比如~0.9.0不会升到0.10.0，因为 MINOR 从 9 变成 10，已超出范围
PHP 版本约束怎么写才不翻车
PHP 自身版本写法和普通包一样，但影响更底层："php": "^8.1" 表示 >=8.1 ，而 <code>"php": "~8.1.0" 只允许 8.1.x。
关键陷阱在于：Packagist 上已发布的旧包，其 composer.json 里的 PHP 约束无法修改。比如一个 v1.0.0 标签写着 "php": ">=7.0"，那它在 PHP 8.3 下仍可能被装上——哪怕实际跑不通。
- 自己发包时，务必加明确上限：
"php": ">=8.1 ，别只写最低 - 用
composer install --ignore-platform-reqs是临时绕过，不是解决方案 - CI 配置必须和
config.platform.php一致，否则本地能装、CI 报错
生产环境依赖锁定的真实操作点
composer.lock 不是“备份文件”，它是生产部署的唯一可信源。写死版本号、用 ^、还是用 ~，在生产环境都不重要——真正起作用的是 lock 文件里记录的 exact commit hash 或 dist zip URL。
- 必须提交
composer.lock到 Git，且和composer.json的platform配置严格匹配 - 部署脚本里只跑
composer install --no-dev --optimize-autoloader --classmap-authoritative，禁止update - 定期用
composer outdated --direct检查，但升级前必须composer update --dry-run验证子依赖是否连带升级出问题
最常被忽略的一点：composer.lock 里记录的 platform 信息（如 php、ext-zip）如果和线上环境不一致，即使版本号对得上，也可能在运行时报错——比如 json_encode() 行为差异，根源其实是 ext-json 版本浮动，而 lock 文件没锁住它。
