执行 composer update 会按 composer.json 约束和 composer.lock 状态，更新所有允许的包至最新兼容版本；它不是升级到绝对最新版，也非重装依赖。
直接说结论：执行 composer update 会更新所有锁文件中允许的包到最新兼容版本，不是“升级到最新版”，更不是“重装依赖”——它受 composer.json 中的版本约束和 composer.lock 的当前状态共同影响。
为什么 composer update 没更新到你想要的版本？
根本原因在于 Composer 的版本解析逻辑：它只在 composer.json 声明的约束范围内找满足条件的最新可用版本，同时尊重 composer.lock 中已锁定的次要/补丁版本（除非显式要求跳过）。
- 比如
"monolog/monolog": "^2.0"，update不会装 v3.x，哪怕 v3 已发布 - 如果
composer.lock里记着"monolog/monolog": "2.8.0"，而 v2.9.0 已发布且符合 ^2.0，update才可能升到 2.9.0 - 若本地有修改过的
composer.lock（比如手动改过 hash），Composer 可能拒绝更新并报错The lock file is not up to date
想批量更新但又不破环兼容性，该加什么参数？
默认 composer update 会尝试升级所有包，包括 dev 分支依赖、插件、甚至 platform 配置。实际项目中多数人需要的是「安全更新」——只升补丁、不碰主次版本。
- 用
composer update --with-dependencies确保子依赖也同步适配（尤其当你只 update 某个包时） - 用
composer update --dry-run先看计划更新哪些包、升到哪个版本，避免盲操作 - 用
composer update --prefer-stable避免意外拉取-dev或-alpha版本（尤其 CI 环境必须加） - 慎用
--ignore-platform-reqs：它绕过 PHP/扩展版本检查，可能导致运行时报错，仅调试时临时用
composer update 后 vendor 和 lock 文件对不上怎么办？
典型现象是 composer install 报错 Package xyz has a PHP requirement incompatible with your PHP version，或 CI 构建失败，但本地 update 成功了——说明 lock 文件记录的包与当前环境不匹配。
- 先确认 PHP 版本和
config.platform.php是否一致（composer config platform.php 8.1.0是常见坑点） - 删掉
vendor/和composer.lock再composer install并非正解；应先git checkout composer.lock回退，再composer update并提交新 lock - 多人协作时，
composer.lock必须提交进 Git；忽略它等于放弃依赖一致性 - CI 环境务必用
composer install（不是 update），否则每次构建都可能产生不同依赖树
最常被忽略的一点：Composer 的「更新」本质是重新解析整棵依赖树，不是单个包的增量升级。哪怕你只想升一个包，整个依赖图都可能重排——所以别在生产分支上直接 update，先在 feature 分支验证，再合入 lock 文件。
