composer install 才是真正的“批量同步依赖”操作，它严格按 composer.lock 安装，不升级、不重算依赖树，确保 vendor/ 与 lock 文件完全一致。
直接更新所有已安装的 Composer 扩展，用 composer update 就行；但“批量同步依赖”不是标准操作，本质是统一拉齐 lock 文件与实际安装状态——多数人真正要的是后者，且常因理解偏差导致误操作。
为什么 composer update 不等于“同步”，而容易翻车
很多人以为 composer update 是把本地已装包“对齐到 composer.json”，其实它会重新解析全部依赖树、升级到满足约束的最新版本（哪怕没改 composer.json），并重写 composer.lock。这和“同步”（即：让已安装包和 lock 文件一致）完全相反。
- 常见错误现象：
composer install报错 “Your requirements could not be resolved”，但composer update却能过 —— 说明本地装的包和 lock 文件不一致，而非composer.json有问题 - 正确做法是先运行
composer install，它才严格按composer.lock安装，不升级、不重算 - 如果本地已有包但 lock 文件缺失或损坏，
composer install会失败；此时应先composer update --lock（仅重生成 lock，不重装包），再composer install
composer install 才是真正的“批量同步依赖”操作
所谓“同步”，就是让 vendor/ 目录内容和 composer.lock 完全一致。这个动作由 composer install 完成，且默认只做这件事，不碰 composer.json 的版本约束。
- 使用场景：CI 构建、团队新成员首次拉代码、部署服务器时确保环境和开发环境完全一致
- 关键参数：
--no-dev跳过require-dev包（生产环境常用）；--prefer-dist（默认）优先用压缩包而非 Git 克隆，更快更稳定 - 性能影响：比
update快得多，因为它跳过依赖解析，只校验 hash 并解压/软链 - 兼容性注意：若
composer.lock是高版本 Composer 生成的（如 2.5+），低版本（如 1.x）可能无法读取，报错Unsupported version constraint format
想“安全更新全部扩展”？别无脑 composer update
真要批量升级所有包，必须意识到：这不是原子操作，可能引入破坏性变更。Composer 默认不会跨主版本升级（如从 v1.x 到 v2.x），但子版本（v1.2 → v1.9）仍可能有 BC break。
- 推荐流程：
composer update --dry-run先看会动哪些包；再composer update vendor/package-name逐个升，留痕可控 - 如果坚持全量更新，加
--with-all-dependencies确保传递依赖也跟着升（否则可能卡在旧版本） - 容易踩的坑：升级后
phpunit或symfony/console行为变化，测试突然 fail；或者monolog升级后日志格式变，监控告警失效 - 示例：
composer update --with-all-dependencies --dry-run输出类似：Updating monolog/monolog (1.26.0 => 2.10.0)—— 这里主版本跳变，就得手动确认是否允许
最常被忽略的一点：很多人删了 vendor/ 和 composer.lock 后直接 composer install，结果装了一堆新版包——因为没 lock 文件时，install 会自动退化为 update 行为。真要干净重建，得先 composer update --lock 再 install。
