^锚定主版本，~锚定最左侧非零段；0.x下二者行为重合但逻辑不同：^因semver视minor升级为breaking而限patch，~因锚点在第二位而限第三位；*在composer中非法。
写错一个符号，composer update 就可能把线上服务拖垮——^ 和 ~ 不是“差不多”，它们锚定的位置根本不同；* 在 Composer 里根本不能用，写了就报错。
为什么 ^1.2.3 会升到 1.12.0，但 ~1.2.3 死卡在 1.2.x
^ 锚定主版本号（MAJOR），~ 锚定最左侧非零段（即你写到的最后一位数字所在层级）。这不是松紧程度差异，是坐标系错位。
-
^1.2.3等价于>=1.2.3 ：允许 <code>1.2.3 → 1.12.0，哪怕中间跳了 10 个小版本 -
~1.2.3等价于>=1.2.3 ：只放行修订号（PATCH）升级，<code>1.2.3 → 1.2.99合法，1.3.0直接被排除 - 常见误判：
~1.2看似模糊，其实等价于~1.2.0，不是>=1.2.0的宽泛匹配，而是明确锁死次版本为2 - 陷阱场景：某包在
1.8.0废弃了一个方法，但你写的是^1.2.3，composer update仍会拉它——^不校验实际变更，只看版本字符串
0.x 版本下 ^ 和 ~ 行为突然“一致”，但原因完全不同
^0.8.2 和 ~0.8.2 都只允许升到 0.8.x，但这不是因为它们变一样了，而是各自逻辑在 0.x 上偶然重合。
-
^0.8.2是因 SemVer 规定：主版本为 0 时，任何 MINOR 升级都视为 breaking，所以自动降级为仅允许 PATCH 升级 -
~0.8.2是因锚点落在第二位（8），自然只放开第三位（2及之后） - 关键区别暴露在
^0.0.3vs~0.0.3：^0.0.3锁死到0.0.3（不接受任何更新），~0.0.3却允许升到0.0.999 - 实操建议：遇到
0.x包（如spatie/laravel-ray:0.25.0），别信^的“兼容”承诺，必须查 CHANGELOG 或 issue 确认变更是否安全
星号 * 在 composer.json 里根本无效，别试
"monolog/monolog": "1.*" 或 "^1.*" 会直接触发 Invalid version string 报错。Composer 不支持 shell 式通配符。
- 想匹配所有
1.x版本？写"^1"，等价于>=1.0.0 - 想匹配所有
1.2.x？写"^1.2"或"~1.2"，不是"1.2.*" -
*唯一合法位置是分支别名（如dev-main），但它不参与语义化版本比较，^/~对其完全无效 - 错误示例：
"monolog/monolog": "^dev-main"→ Composer 解析失败；正确做法是开发用分支，上线前换为稳定标签或提交哈希
真正决定运行时版本的，从来不是 composer.json
composer install 只读 composer.lock，完全忽略 composer.json 里的 ^ 或 ~。约束只在 composer update 时起作用。
- 改了
composer.json的约束却没跑composer update vendor/package？lock 文件仍是旧版，部署时照样装旧版 - 删了
composer.lock或没提交进 Git？composer install会 fallback 成composer update行为，按新约束重算——此时你写的~1.2.3才生效，但已是不可控更新 - 验证是否生效？别只看
composer.json：composer show vendor/package -i显示真实加载版本；composer update --dry-run预览下次 update 会拉什么 - 最稳妥的生产实践：
composer.lock必须提交进 Git，CI/CD 中禁用--no-interaction外的所有自由更新选项
