composer update 默认更新所有依赖而非单个包，需指定包名如 composer update vendor/package-name 才能精准升级；遇依赖冲突应先用 composer why-not 分析，再查版本兼容性；install 仅按 lock 安装，update 重算依赖树并更新 lock。
composer update 会更新所有依赖，不是升级单个包
很多人以为 composer update 是“升级当前项目”，其实它默认拉取 composer.json 里所有包的最新兼容版本，可能连 PHP 版本约束都触发重装。这在协作项目中极易引发意外行为——比如某个间接依赖升了大版本，接口变了但没报错，测试又没覆盖到，上线就出问题。
真正想升级单个扩展包，必须显式指定包名：
-
composer update vendor/package-name（只更新这个包及其子依赖） -
composer update vendor/package-name --with-dependencies（连带更新它直接依赖的包） - 如果只想升到某版本范围，先改
composer.json里的版本号，再跑composer update vendor/package-name
升级时遇到 “Your requirements could not be resolved” 错误
这是 Composer 最典型的卡点：你指定了一个新版本，但它和现有其他包的版本约束冲突。比如你想升 monolog/monolog 到 ^3.0，但 laravel/framework 还锁在 ^9.0，而后者只允许 monolog:^2.0。
这时候别急着加 --ignore-platform-reqs 硬来，先做三件事：
- 运行
composer why-not vendor/package-name:3.0，看谁在阻止升级 - 检查
composer show vendor/package-name，确认当前版本和可用版本 - 查目标包的 CHANGELOG 或 GitHub Releases，确认是否需要配套升级其他包（比如 Laravel 升级常要求同时升
symfony/*）
composer install 和 composer update 的本质区别
composer install 只按 composer.lock 装，不碰 composer.json；composer update 则以 composer.json 为准，重新算依赖树、更新 lock 文件。
这意味着：
- CI/CD 流水线应该用
composer install（快、确定、可重现） - 本地开发想尝新功能或修 bug，才用
composer update - 如果改了
composer.json但忘了update，install不会生效——因为 lock 文件没变
PHP 版本变化后必须重新 update
Composer 会读取当前 PHP 版本，过滤掉不兼容的包版本。比如把 PHP 从 8.1 升到 8.2 后，某些包的 8.1-only 版本会被跳过，但 composer.lock 里还记着旧版本，导致 install 失败或装错。
安全做法是：
- 确认
composer.json的"platform": {"php": "8.2"}已更新（如有） - 删掉
vendor/和composer.lock - 执行
composer update从头生成兼容的 lock 文件
省略删 lock 这步，很容易让团队成员装出不同版本的依赖，尤其跨 PHP 小版本时特别隐蔽。
