~1.2比^1.2更适合锁小版本，因~1.2等价于>=1.2.0 <1.3.0，仅允许补丁更新；而^1.2等价于>=1.2.0 <2.0.0，允许次版本升级，风险更高。
为什么~1.2比^1.2更适合锁小版本
因为~1.2等价于>=1.2 ，它允许次版本号（如 1.3、1.4）和修订号（如 1.2.1、1.2.99）升级，但绝不会跨到 2.0——这符合语义化版本中“次版本新增功能仍兼容”的假设。而<code>^1.2在 Composer 中实际等价于>=1.2 ，看似一样，但一旦你写的是<code>^1.2.0，它的行为就变成>=1.2.0 ，和<code>~1.2一致；可如果误写成^1.2（缺修订号），Composer 会自动补为~1.2.0，结果仍是安全的。真正危险的是^2.0这种——它允许升到 3.0 前任意版本，而 3.0 往往含破坏性变更。
常见错误现象："monolog/monolog": "^1.2"本地装了 1.25.0，上线后 CI 报Class 'Monolog\Handler\SyslogUdpHandler' not found，因为该类在 1.26.0 中被移除，但^1.2仍允许安装它。
-
~1.2明确表达“只接受 1.x 系列”，视觉上更直白，团队新人不易误解 - 若需进一步收紧（只允许修订号变），改用
~1.2.5，它等价于>=1.2.5 - 不要混用：
~1.2 || ^2.0这类写法会让 Composer 解析器陷入多解困境，容易触发依赖冲突
composer update vendor/package时如何避免连带升级其他包
执行composer update monolog/monolog本意是只动这个包，但如果你的composer.json里还写了"symfony/console": "^5.4"，而 monolog 新版悄悄要求"symfony/console": "^6.0"，Composer 就不得不把 console 也升上去——这不是你想要的“局部修复”，而是被动全量升级。
使用场景：第三方库爆 CVE，你只想降级 monolog 到 1.23.0，但不想动 Doctrine 或 Symfony。
- 先运行
composer depends monolog/monolog，看哪些包直接依赖它；再跑composer show monolog/monolog 1.23.0确认该版本是否满足所有依赖方的约束 - 加
--with-dependencies参数要谨慎：composer update monolog/monolog --with-dependencies会强制升级其所有子依赖，通常不必要 - 更稳妥的做法是：先删掉
vendor/和composer.lock，再执行composer install——它只按 lock 文件还原，完全不动其他包
项目 vs 库：版本约束写法必须反着来
你在写一个 Laravel 应用（项目），和你在写一个可被别人require的 SDK（库），对同一包的版本写法应该相反。这是最容易被忽略的上下文切换点。
例如，你的应用需要symfony/yaml解析配置，而你又刚踩过5.4.12里一个 YAML 锚点解析 bug：
- 作为项目：写
"symfony/yaml": "5.4.11"（精确锁定）或"symfony/yaml": "~5.4.11"（允许修订号更新） - 作为库：必须写
"symfony/yaml": "^5.4 || ^6.0"，否则下游项目用 Symfony 6 时会因约束太窄而装不上你的库 - 错放后果严重：把库该写的宽范围写成死版本，会导致下游项目
composer require your/lib直接失败，报Root composer.json requires your/lib, it is satisfiable by your/lib[dev-main] but your/lib[dev-main] requires symfony/yaml 5.4.11 -> found symfony/yaml[v5.4.11] but the package is fixed to v6.2.0
验证composer.lock是否真生效的三个命令
很多人改完composer.json就以为锁住了，结果部署时还是装错——根本原因是composer.lock没更新，或 CI 脚本绕过了它。
性能影响：composer install比composer update快 3–5 倍，因为它跳过依赖图重解析，直接按 lock 文件下载。
- 查当前装的版本：
composer show symfony/yaml，输出里versions字段必须只有一行，且不含^或~符号，例如5.4.11 - 确认 lock 文件权威性：
composer install --dry-run，看它是否打印Installing symfony/yaml (v5.4.11)而不是Resolving dependencies through SAT - 检查 CI 是否误用缓存：
ls -la composer.lock和git log -n 1 -- composer.lock，确保最近一次提交包含 lock 文件变更，且时间戳新于你的修改
最常被忽略的一点：PHP 版本变化会静默覆盖 lock 文件里的 platform 配置。比如composer.json里"config": {"platform": {"php": "8.1.0"}}，但服务器是 PHP 8.2，Composer 可能自动 fallback 到更高版本的包，导致composer.lock失效——这时必须同步更新config.platform.php。
