Composer默认update会按版本约束（如^2.0）升级至最新兼容版，可能跨次版本；应使用精确版本（如"2.9.2"）锁死，或tilde约束（如~1.2.3）限制次版本边界。
Composer依赖升级为什么总是超出预期？
因为默认的 composer update 会按 composer.json 中定义的版本约束（如 ^2.0 或 ~1.5）拉取最新兼容版本，不是“只升补丁”，而是可能跨次版本甚至主版本——尤其当包作者发布 2.1.0 时，^2.0 就会装它，哪怕你本意只想用 2.0.x 系列。
用 exact version 锁死具体小版本（最简单有效）
直接写死带三位数字的版本号，比如 "monolog/monolog": "2.9.2"，Composer 就不会做任何升级，连 composer update monolog/monolog 也不会动它——除非你手动改这个字符串。
- 适合生产环境关键依赖，或已确认某 patch 版本修复了你遇到的 bug
- 注意：写死版本后，安全更新（如 CVE 修复）不会自动生效，得靠人工检查和手动更新
- 别写成
"2.9.2 as 2.9.0"这类 alias，它不阻止升级，只影响 autoloading
用 tilde ~ 或 pessimistic constraint 限制次版本边界
~1.2.3 等价于 >=1.2.3 ，即允许升到 <code>1.2.x 任意版本，但绝不跨 1.3；~2.0 则等价于 >=2.0.0 —— 这是控制“不破兼容性”的常用手段。
- 比
^更保守：^2.0允许升到2.9.9甚至2.10.0，而~2.0只到2.9.9 - 如果包遵循语义化版本但次版本间有行为差异（比如 Laravel 的
9.x中某些 helper 函数在9.5加入），~9.4能避免意外引入 - 不要对主版本用
~：写~1是错的，应写~1.0或>=1.0
用 composer update --with-dependencies 避免间接升级失控
有时你只运行 composer update foo/bar，但 Composer 为满足其新版本的依赖要求，会顺手升级 symfony/console 等传递依赖——这常导致测试失败却找不到原因。
- 加
--with-dependencies参数会让 Composer 显式列出所有被牵连升级的包，方便你核对 - 更稳妥的做法是：先
composer update foo/bar --dry-run，看输出里有哪些“also updating”项 - 若发现不该升的传递依赖，可临时在
composer.json中显式锁定它，例如加一行"symfony/console": "5.4.33"
真正难控的从来不是主版本号，而是那些没被显式声明、却因某个上游包升级而悄悄溜进来的次版本变更——盯住 composer.lock diff 比背熟所有约束符更重要。
