Composer如何更新项目中的所有依赖？（命令详解）

composer update 根据 composer.json 的版本约束重新计算并安装满足条件的最新可用版本，而非简单升级到最新版；它会更新所有或指定包及其依赖，影响可重现性，需同步提交 composer.lock。

直接运行 composer update 就行，但默认会重装全部依赖

它不是“升级到最新版”，而是根据 composer.json 的约束（比如 "^2.0" 或 "~3.1"），重新计算并安装满足条件的最新可用版本。这意味着：如果某包有 3.1.0、3.1.1、3.2.0 三个符合约束的版本，composer update 会选 3.2.0 —— 即使你本地装的是 3.1.1。

常见错误现象：composer update 后 CI 突然失败、本地功能异常，往往是因为某个次要版本引入了不兼容变更（比如 laravel 10 升到 11 的中间件签名变化）。

• 想只更新特定包？用 composer update vendor/package-name
• 想跳过 dev 依赖（如 phpunit）？加 --no-dev
• 想保留 composer.lock 中已锁定的版本？别用 update，改用 composer install

composer update 和 composer upgrade 是同一个命令

没有 composer upgrade 这个命令。有人输错后看到 “Command ‘upgrade’ is not defined” 才意识到，但更常踩的坑是误以为它存在，然后在 CI 脚本或文档里写错，导致流程中断。

Composer 官方只提供 update 和 install 两个核心依赖管理动作。所谓“升级”，只是 update 在宽松版本约束下的自然结果。

• composer update --dry-run 可预览哪些包会被改，不实际执行
• composer update --with-dependencies 强制连带更新指定包的子依赖（慎用，易引发冲突）
• 若项目用了 platform-check 或 PHP 版本约束，update 会自动跳过不兼容的候选版本

为什么 composer update 有时特别慢，甚至卡住？

它要解析整个依赖图、查询 Packagist 元数据、比对版本可用性，还可能触发大量 http 请求。尤其当 composer.json 里写了模糊约束（如 "*" 或 "dev-main"），或启用了 minimum-stability: dev，就会拉取大量开发分支元数据。

性能影响明显：在 CI 上跑一次完整 update 可能比 install 慢 3–5 倍；本地首次运行还可能因 DNS 或镜像源问题卡在 “Loading composer repositories”。

• 国内用户优先配置阿里云镜像：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• 避免在生产环境直接跑 update；CI 应基于 composer.lock 执行 install
• 如果只是想升一个包的小版本（如 2.3.1 → 2.3.2），用 composer update vendor/package --with-dependencies 比全量 update 更准更快

更新后 composer.lock 改了，但 git 提交时漏掉它

这是最隐蔽也最常出事的一环。composer.lock 不提交，等于把依赖状态“藏起来”——别人 composer install 装出来的包，可能和你本地完全不一样，连 bug 都复现不了。

错误现象包括：本地正常，测试环境报 class not found；或者 vendor/autoload.php 加载失败，但查路径又没错。

• 检查是否被 .gitignore 错误屏蔽（标准模板不该忽略它）
• CI 构建前务必确认 composer.lock 已纳入版本控制，且与 composer.json 时间一致
• 团队协作中，只要动了 composer.json（增删改 require），就必须跑一次 composer update 并提交生成的 composer.lock

锁文件本质是“确定性快照”，它比 composer.json 的声明更权威。忽略它，就等于放弃 Composer 最关键的可重现能力。