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 最关键的可重现能力。
