composer update 不会重装整个 vendor 目录，而是依据 composer.lock 和 composer.json 更新满足版本约束的包；删 lock 文件后 install 才会重新解析并安装依赖。
composer update 会重装整个 vendor 目录吗
不会自动清空，但行为取决于锁文件和依赖声明。只要 composer.lock 存在且没被删，composer update 默认只更新满足 composer.json 版本约束的包，并复用 lock 文件里记录的精确版本（除非你指定要升级某包）。真正“重装 vendor”的其实是 composer install 在没有 lock 文件时的行为——它会按 composer.json 解析最新兼容版本，结果反而更不可控。
- 删了
composer.lock再跑composer install，等同于一次不受控的update -
composer update不加参数 = 更新所有包到各自约束下的最新版，可能触发级联升级（比如laravel/framework升了，连带symfony/*也升） - Laravel 项目建议始终提交
composer.lock，否则不同环境装出的依赖版本不一致，容易出现本地正常、线上报错
只更新 Laravel 框架本身，不碰其他包
直接锁定范围，避免意外升级第三方包导致兼容问题。Laravel 的主包是 laravel/framework，但它的子依赖（如 symfony/http-foundation）也可能被顺带升级——除非你明确排除。
- 运行
composer update laravel/framework，这是最安全的单点升级方式 - 如果提示冲突，先看错误信息里哪几个包卡住了版本，常见的是
php版本不匹配或symfony/*要求太高；此时可加--with-all-dependencies强制连带升级必要依赖，但务必先确认这些依赖是否被其他包强依赖 - 别用
composer update "laravel/*"，它会误升级laravel/tinker或laravel/sanctum等可选包，破坏稳定性
更新后 php artisan 报错 Class not found 或 Undefined method
典型症状：命令能跑起来，但执行具体指令就崩，比如 php artisan config:clear 报 Class 'Illuminate\Support\ServiceProvider' not found。这不是代码写错了，而是 autoloader 没刷新，或者缓存残留了旧类映射。
- 先删掉
bootstrap/cache/config.php和bootstrap/cache/services.php这两个缓存文件（Laravel 9+ 还有packages.php） - 再跑
composer dump-autoload -o，强制重建 autoload 映射（-o是优化模式，生成静态映射，比默认快） - 如果还报错，检查
config/app.php里的providers数组有没有引用已移除或重命名的类（比如 Laravel 10 移除了App\Providers\BroadcastServiceProvider，但配置里还留着）
为什么 composer update 耗时特别长，甚至卡在 “Resolving dependencies”
Composer 7+ 默认启用并行解析和更严格的依赖检查，遇到复杂约束（尤其是 dev-master、@dev 版本或大量 private repo）时，SAT（布尔可满足性）求解器会反复回溯，CPU 占满但进度不动。
- 临时提速：加
--no-interaction --prefer-dist --no-suggest，跳过交互、强制用压缩包安装、不加载建议包 - 根本解决：检查
composer.json里有没有写死"minimum-stability": "dev"或大量"@dev"，改成"stable"并显式指定版本（如"^10.0"） - 私有包多的项目，确认
repositories配置是否指向可用地址；偶尔 GitHub API 限流也会让解析卡住，可临时加--repository-url=https://packagist.org强制走官方源
