composer update 会重装所有依赖而非增量更新，它根据 composer.json 重新解析依赖树并重装 vendor 目录，除非指定包名或使用 –lock 参数。
composer update 会重装所有依赖，不是增量更新
很多人以为 composer update 只更新有新版本的包，其实它会根据 composer.json 重新解析整个依赖树，删掉 vendor/ 里现有包，再按最新兼容规则安装——哪怕某个包在 composer.lock 里已经锁死，只要没加 --lock 或没指定包名，它也会被“升级”到满足 composer.json 版本约束的最新可用版。
- 想只更新某几个包？用
composer update vendor/package-a vendor/package-b - 想确保不破坏现有行为？先确认
composer.lock已提交，再运行composer update --lock（仅同步 lock 文件，不改 vendor） - CI 环境或生产部署时，应始终用
composer install，而不是update，否则可能引入未测试过的版本
更新时遇到 “Your requirements could not be resolved” 错误
这通常不是网络问题，而是 composer.json 里的版本约束和已有依赖冲突了。Composer 尝试找一个能同时满足所有包要求的版本组合，失败就报这个错。
- 先运行
composer why-not vendor/package:version查具体哪个依赖拦住了升级 - 检查是否误写了
"^2.0"却想升到3.x——大版本跃迁需要手动改composer.json - 临时放宽约束可加
--with-all-dependencies，但别直接合进主干，它可能把间接依赖也强行升级 - 如果只是想升级 PHP 自身要求，改完
config.platform.php后必须删掉composer.lock再update，否则平台配置不生效
为什么 composer update 越来越慢？
Composer 5.6+ 默认启用插件自动发现和哈希验证，加上 packagist.org 的元数据体积增大，本地索引重建耗时明显增加。不是你的网络变差了。
- 加
--no-plugins可跳过插件加载（尤其当你没用hirak/prestissimo这类加速插件时） - 定期清理缓存：
composer clear-cache，旧版本缓存残留会导致解析变卡 - 避免在
require-dev里塞大量工具包（如 phpunit、phpstan），它们参与依赖求解，拖慢整个过程 - 如果项目长期不更新，建议先
composer update --dry-run看会动哪些包，心里有数再执行
真正麻烦的不是命令怎么敲，而是搞不清「到底要更新什么」——是修一个安全漏洞？适配新版 laravel？还是被迫升级 PHP？目标不同，该加的参数、该锁的版本、该查的日志位置，全都不一样。别让 update 成为盲操作。