composer通过^和~划定版本合法区间而非禁止更新，^2.1.0允许2.x.x但不跨3.0.0，~2.1.0仅限2.1.x，~2.1等价于>=2.1.0
用 ^ 和 ~ 控制升级边界，不是“禁止更新”而是“划定合法区间”
Composer 本身没有“禁止更新某包”的开关，它只做依赖图求解。所谓“限制升级范围”，本质是告诉 Composer：“在这个区间里找最新版，别跨出去”。^ 和 ~ 是最常用也最易误读的两个符号：
-
^2.1.0允许升到2.x.x中任意版本，但绝不会到3.0.0；但如果当前 lock 文件里是2.0.5，而你写的是^2.1.0，Composer 会直接跳到2.1.0（哪怕中间有2.0.9）——它按约束重算，不是“从当前版本往上爬” -
~2.1.0等价于>=2.1.0 ，只允许补丁升级；<code>~2.1则等价于>=2.1.0 ，比 <code>^2.1更松？不，它其实更窄：前者允许2.9.0，后者只到2.1.x -
^0.3.2在 0.x 阶段行为特殊：它只允许补丁升级（即0.3.x），因为语义化版本规定 0.x 不保证兼容性，Composer 默认收紧策略
为什么 composer update monolog/monolog 还是拉了 symfony/console？
这不是失控，是依赖图强制一致性的结果。当你运行 composer update monolog/monolog，Composer 并不是“只动这个包”，而是以它为起点，重新求解整个子图中所有满足其 require 的版本组合。
- 查清楚目标包真正依赖什么：
composer show monolog/monolog输出它的requires列表，比如含"symfony/console": "^6.2" - 如果你 lock 文件里
symfony/console是6.1.0，而monolog/monolog新版要求^6.2，那必须升 —— 否则依赖不成立 - 想拦住它？在根
composer.json的require里显式写死："symfony/console": "6.1.0"或"symfony/console": "=6.1.0"，这会成为全局约束，压过子依赖声明
composer update 不加参数就危险，必须养成显式指定的习惯
全量 composer update 是最大风险源，尤其在 CI/CD 或多人协作中。它会无视你精心写的 ^ 约束，只要存在更高兼容版本就升 —— 而且可能因传递依赖冲突，倒逼其他包降级或跳版本。
- 只更新一个包：
composer update monolog/monolog（注意必须带 vendor 前缀，monolog会静默 fallback 全量） - 只更新一类包：
composer update laravel/*，匹配所有 Laravel 官方包，其余不动 - 验证再执行：
composer update monolog/monolog --dry-run先看终端输出列了哪些变更，确认无意外连带升级再回车 - CI 脚本里禁用全量更新：用
composer install --no-interaction --no-progress --prefer-dist，确保只装 lock 文件里的版本；若需更新，必须明确列出包名
真正锁定版本，得靠 = + 提交 composer.lock
“限制范围”是柔性控制，“锁定版本”才是硬性保障。很多团队翻车，是因为只改了 composer.json 却没提交 composer.lock，或者 CI 里漏了 --no-updates。
- 精确锁定写法：
"phpunit/phpunit": "=9.6.13"—— 等号开头，无视所有语义规则，连9.6.14都不认 - 仅写
"phpunit/phpunit": "9.6.13"也有效，但不如=显式，且某些旧版 Composer 对裸版本解析略有差异 -
composer.lock必须纳入 Git：它才是实际安装依据；一旦缺失或未更新，composer install就退化为update - Docker 构建时，
COPY composer.lock .必须在composer install之前，且命令末尾加--no-updates防止自动刷新 lock
require、每一个 ^、每一次 update 命令，都在参与这个求解过程。所谓“局部控制”，只是用更细的锚点把解空间钉死。
