推荐用 composer outdated 检查更新，再按需使用 –with-dependencies 或 –with-all-dependencies 精准升级；composer update 会重算依赖并修改 lock 文件，而 install 仅按 lock 安装，CI/CD 中误用 update 会导致构建不可重现。
直接运行 composer update 会升级所有包，但不推荐
它默认升级到 composer.json 中允许的最新兼容版本，可能跳过主版本（如从 v2.x 升到 v3.x），也可能因依赖约束卡在旧版。更关键的是：它会修改 composer.lock，且不区分“小修”和“破坏性更新”，容易引发线上问题。
实操建议：
- 先用
composer outdated查看哪些包有新版本、是否含主版本更新（带!标记的需特别注意） - 若确认要全量升级，加
--with-all-dependencies参数：composer update --with-all-dependencies，它会递归更新子依赖，避免部分包被锁死 - 永远在运行前提交当前
composer.lock，或先备份：cp composer.lock composer.lock.bak
想只升指定包（比如只升 monolog/monolog）
命令是 composer update monolog/monolog，但它默认只更新该包本身，其子依赖可能仍卡在旧版，导致兼容性隐患。
安全做法是连带更新它的依赖树：
-
composer update monolog/monolog --with-dependencies（仅更新该包及其直系依赖） - 或更彻底：
composer update monolog/monolog --with-all-dependencies（连带整个依赖图中所有可匹配的包） - 注意：如果该包被其他包硬依赖某个旧版本，
composer会报冲突，不能强制覆盖
composer update 和 composer install 的根本区别
composer install 只按 composer.lock 安装，不读 composer.json 的版本范围；而 composer update 是重新解析 composer.json 并生成新 composer.lock。
常见误操作：
- CI/CD 流程里误用
update而非install，导致每次构建都拉不同版本，破坏可重现性 - 本地开发后忘了提交新
composer.lock，团队其他人install时还原的是旧状态 -
composer update后没跑测试就提交，尤其要注意phpunit、symfony/console等工具类包的 API 变更
升级 laravel 或 Symfony 这类框架时的特殊处理
它们的主版本升级（如 Laravel 9 → 10）不是靠 composer update 自动完成的，官方明确要求手动修改 composer.json 中的版本约束，再执行 update，并配合升级向导（如 laravel-shift 或官方 Migrating 文档）。
例如 Laravel 10 要求：
- 把
"laravel/framework": "^9.0"改成"^10.0" - 同步更新
php版本要求（Laravel 10 需 PHP 8.1+） - 检查并替换已废弃的 Facade 或配置项（如
config/app.php中的providers数组结构） - 不要跳过
php artisan app:upgrade（如可用）或对应框架的升级脚本
真正麻烦的从来不是命令敲得对不对，而是 lock 文件改了之后，哪一行测试突然 fail，或者哪个第三方包悄悄断掉了对新 PHP 版本的支持——这些必须人工验证。