直接运行 composer update 会破坏 composer.lock 一致性，因其忽略锁文件并重新解析依赖树，导致版本不一致；应使用 composer update vendor/package 精准更新，或 composer install 严格按锁文件安装，PHP 升级后须同步 platform 配置并执行 composer update --lock。
直接运行 composer update 会破坏 composer.lock 一致性
很多人以为 composer update 是“安全更新”，其实它默认会忽略 composer.lock 中已锁定的版本，重新解析整个依赖树，生成新锁文件。只要 composer.json 里某个包的版本约束宽松（比如 "monolog/monolog": "^2.0"），就可能升到 2.10.0 而不是 2.8.0 —— 即使 composer.lock 原本固定的是后者。这会导致团队成员或生产环境执行 composer install 时还原出不同版本，引发难以排查的行为差异。
只更新指定包且不改其他依赖：用 composer update vendor/package
这是最常被误用也最需掌握的操作。当你只想升级 guzzlehttp/guzzle 到最新兼容版，又不想连带更新 symfony/http-foundation 或其子依赖时：
- 运行
composer update guzzlehttp/guzzle，Composer 会保留composer.lock中其他所有包的精确版本 - 如果该包有子依赖（如
psr/http-client）也被其composer.json的 require 约束放宽了，Composer 仍可能顺带升级它们——这是正常行为，因为依赖图必须满足所有约束 - 加
--with-all-dependencies会主动升级它的全部子依赖（含传递依赖），慎用；不加则只升级直接依赖和必要调整的间接依赖 - 想确认改动范围？先加
--dry-run：例如composer update guzzlehttp/guzzle --dry-run
强制重装并严格对齐 composer.lock：用 composer install
当别人提交了新的 composer.lock，或者你本地怀疑依赖状态混乱（比如报 Class not found 但类明明存在），唯一可靠做法是丢弃当前 vendor/ 并完全按锁文件重建：
- 删掉
vendor/目录和composer.lock（仅限你想彻底重来时） - 更常见的是保留
composer.lock，只删vendor/，然后运行composer install -
composer install永远以composer.lock为准，不会读取composer.json的版本约束 - 若
composer.lock和composer.json不匹配（比如你改了composer.json但没 run update），composer install会报错并提示你运行composer update—— 这是保护机制，不是 bug
更新 PHP 版本后必须检查 platform 配置
如果你把项目从 PHP 7.4 升到 8.2，但 composer.json 里还写着：
"config": {
"platform": {
"php": "7.4.33"
}
}那 Composer 会假装自己还在 7.4 环境下解析依赖，可能导致装上不兼容 PHP 8.2 的旧版包（比如 ramsey/uuid v3），运行时报 Deprecated: Array and string offset access syntax with curly braces is deprecated 这类错误。
解决方法很简单：
"config": {
"platform": {
"php": "8.2.15"
}
}然后运行 composer update --lock（注意是 --lock，不是 --dry-run）——这个命令只重写 composer.lock 中的平台信息，不改动任何包版本，是 PHP 升级后最轻量、最安全的同步操作。
真正容易被忽略的点在于：很多人改完 php 版本就直接 composer install，却没意识到 platform 配置像一个“虚拟运行环境声明”，它比实际 PHP 版本还优先影响依赖解析结果。
