不能只靠composer update laravel/framework升级框架，因其仅更新主包，不自动处理PHP版本要求（如Laravel 10需PHP≥8.1）、illuminate/配套组件同步、以及被其他包硬锁定的symfony/等子依赖，易致Class not found等错误。
直接改 composer.json 里的约束，再跑 composer update 指定包，不是“一键升级”，而是必须手动对齐版本、环境和迁移动作。
为什么不能只靠 composer update laravel/framework 升框架？
这个命令确实会升 Laravel 主包，但不会自动处理三类关键依赖：PHP 版本要求（如 Laravel 10 要求 PHP ≥8.1）、配套组件（illuminate/* 必须同步）、以及被其他包硬绑定的子依赖（比如 symfony/console 被 phpunit/phpunit 锁在 v5.x，而 Laravel 10 需要 v6+）。结果就是报错退出，或升完 php artisan 直接 Class not found。
- 运行前先确认当前 PHP 版本满足目标框架最低要求，用
php -v和官方文档交叉核对 - 升 Laravel 时，必须连带更新所有
illuminate/*包：composer update laravel/framework illuminate/* - 如果报
symfony/*冲突，别硬加--with-all-dependencies，先用composer why-not symfony/http-kernel:^6.4查谁在拦着
composer outdated --direct 是升级前唯一可信的起点
它能暴露你声明的框架约束是否已实际落后——比如 laravel/framework 显示 9.52.15 → 10.38.1，但如果你的 composer.json 还写着 "^9.0"，那 outdated 就不会标出主版本跳变，除非你临时改成 "^10.0" 再跑一次。很多团队卡在这里，以为没更新可做，其实是约束本身挡住了检测。
- 加
--direct只看你自己显式 require 的包，避免被monolog/monolog这类传递依赖干扰判断 - 如果
outdated没输出，检查composer.json是否设了"minimum-stability": "stable"+"prefer-stable": true，它们会过滤掉预发布版，导致漏报 - CI 中建议每日跑
composer outdated --minor-only，避开主版本干扰，只盯小修小补
升完框架后，php artisan 报错不是代码问题，是缓存和配置残留
典型症状是命令能启动，但一执行具体指令就崩，比如 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，强制重建映射；-o不是可选项，没它加载会慢且可能漏类 - 检查
config/app.php的providers数组，Laravel 10 已移除BroadcastServiceProvider，但老配置可能还留着
composer.lock 不是副产品，是升级成败的锚点
删了它再 install，等于放弃控制；不提交它就 update，等于让团队其他人装出完全不同的依赖树。真实项目里，composer.lock 提交前必须和 composer.json 版本约束严格对齐，且每次 update 后都要 git diff composer.lock 看改了哪些包的 commit hash 和 PHP 扩展要求。
- 生产部署脚本里绝不能出现无参数的
composer update，CI 流水线一旦出错，回滚成本远高于预防 - 跨大版本升级（如 Laravel 9→10）后首次
composer install报The lock file does not contain require-dev information，说明 Composer 版本已升到 v3，需删composer.lock重建 - 如果用了
config.platform（比如模拟 PHP 8.1），outdated可能漏报——它按平台声明算，不是按你真实服务器环境
