^ 锁主版本号后首个非零段，~ 锁倒数第二位；^1.2.3 等价于 >=1.2.3 =1.2.3
Composer 的 ^ 和 ~ 到底锁哪一位？
很多人以为 ^1.2.3 是“允许小版本升级”，其实它真正锁的是**主版本号之后第一个非零段**：对 ^1.2.3，它等价于 >=1.2.3 ；但对 ^0.2.3（即 0.x.y 的早期版本），它只锁到 >=0.2.3 —— 因为语义化版本规定 0.x.y 是“不稳定开发阶段”，^ 在这里退化为 ~ 级别。
而 ~1.2.3 始终只放宽最后一位：等价于 >=1.2.3 ；~1.2 等价于 >=1.2.0 。所以 ~ 更可预测，尤其在 0.x 或 1.x 中间过渡期。
- 用
^时，要确认包是否已发布正式版（即主版本 ≥1）；否则它可能意外跳过兼容性不保证的“次版本” - 用
~更适合明确控制升级边界，比如你只信任monolog/monolog的2.9.x系列，就写~2.9.0 -
composer require foo/bar:^2.0在包发布3.0.0后不会自动升级，但若它先发了2.10.0，下次composer update就会拉进来——这未必是你想要的“稳定”
什么时候该用 ==、!= 或固定版本字符串？
当你发现某个 minor 版本引入了破坏性变更（哪怕没改主版本号），或某 patch 版本悄悄改了行为（比如 guzzlehttp/guzzle 7.5.1 修复了一个 DNS 缓存 bug，但 7.5.0 在特定环境下会超时），这时候宽松约束就是风险源。
固定版本是最安全的起点，尤其是上线前锁定依赖：
-
composer require symfony/http-kernel:5.4.38—— 完全确定行为，CI 和生产环境一致 -
"symfony/console": "==5.4.38"写进composer.json，能防止composer update意外升到 5.4.39（哪怕只是文档 typo 修复） - 慎用
!=：它无法阻止新版本发布后被自动安装（比如你排除!=1.2.0，但1.2.1仍可能被^1.2拉入）
composer update 不按预期升级？检查这三件事
你以为 ^2.0 应该装上 2.5.0，结果还是 2.0.1 —— 往往不是约束写错了，而是 Composer 的依赖图在“让步”。
- 运行
composer why-not vendor/package:2.5.0，看哪个其他包硬性要求更低版本（比如laravel/framework锁死了vendor/package:^2.0.0，但它的某子依赖只认） -
composer show vendor/package查当前解析出的实际版本，再对比composer show -t看依赖树里谁在压低它 - 删掉
composer.lock再composer install？别急——先确认这是你真想做的。lock 文件存在就是为了复现，盲目删除等于放弃可重现性
团队协作中怎么避免“在我机器上是好的”？
关键不是统一写法，而是统一“决策依据”。比如你们约定：^ 只用于主版本 ≥1 且有良好测试覆盖率的包（如 psr/log），~ 用于框架插件类（如 doctrine/doctrine-bundle），核心业务依赖一律固定版本。
- 把约束逻辑写进
composer.json的config.platform里没用——它只影响扩展和 PHP 版本模拟，不干预包版本选择 - CI 脚本里加
composer install --no-interaction --prefer-dist --optimize-autoloader，但别漏掉--dry-run阶段验证更新范围 - 最常被忽略的一点：不同 Composer 版本对
^的解析略有差异（比如 2.2 vs 2.5 对0.x的处理），团队必须统一 Composer CLI 版本，用composer self-update --2锁死大版本
