升级 Laravel 时“Class not found”错误主因是迁移类命名不匹配或自动加载未刷新，需确保类名与文件名严格一致、继承正确基类，并运行 composer dump-autoload。
升级 Laravel 时 php artisan migrate 报错 “Class not found” 怎么办
这是最常见也最容易误判的问题：不是迁移文件写错了，而是 Laravel 版本升级后自动加载机制或迁移类命名规范变了。
5.8 及以前版本允许迁移类名不带 CreatesUsersTable 这种驼峰格式，6.x 起强制要求类名必须与文件名严格匹配（如 2014_10_12_000000_create_users_table.php 对应 CreateUsersTable），且需继承 Migrator 兼容的基类（Illuminate\Database\Migrations\Migration）。
- 检查迁移类是否仍用
use Illuminate\Database\Schema\Blueprint;而非新版本推荐的完整命名空间引用 - 运行
composer dump-autoload强制刷新自动加载，尤其在从 5.x 升到 6+ 后遗漏这步会导致类找不到 - 如果用了自定义迁移基类，确认它是否实现了
getMigrationName()或兼容新版本的getConnection()返回逻辑
Laravel 9+ 的 Route::apiResource() 和旧版行为不一致
9.0 开始，Route::apiResource() 默认不再注册 create 和 edit 这两个 HTML 表单路由（即不生成 GET /users/create），只保留 RESTful API 约定的 7 个动作。这不是 bug，是语义收敛。
如果你的前端或测试代码还依赖这些路由，会直接 404；而旧项目升级后没改路由声明，就容易卡在这里。
- 需要表单页就改用
Route::resource()，或者显式补全：Route::get('/users/create', [UserController::class, 'create'])->name('users.create'); - 检查中间件是否混用了
web和api组 ——apiResource默认走api中间件组，CSRF、session 等功能默认关闭 - 别在
apiResource里传['except' => ['create']]试图“修复”，它本来就不含这个动作
config/app.php 里的 providers 数组在 Laravel 10 中被废弃了？
没有被废弃，但加载逻辑变了：10.x 默认启用「延迟提供者发现」（Lazy Provider Discovery），providers 数组不再决定哪些服务提供者会被加载，而是由 Composer 的 autoload + laravel/providers 键控制。
直接删掉 providers 里的条目不会报错，但某些包（比如 barryvdh/laravel-debugbar）若没在 composer.json 的 extra.laravel.providers 里声明，就会彻底不加载。
- 升级到 10 后，先跑
php artisan package:discover，再检查bootstrap/cache/packages.php是否包含你依赖的提供者 - 手动维护
providers数组仍有效，但属于“兼容模式”，不推荐 —— 容易和 composer 自动发现冲突，导致重复注册或漏注册 - 第三方包文档若还教你在
app.php手动加 provider，大概率没适配 10+，得查它最新 release note
Blade 模板中 @push 和 @stack 在 Laravel 8–11 的兼容边界
8.x 引入了 @once + @push 组合优化重复注入，但 8.77 之前存在一个关键 bug：嵌套组件中 @push 内容可能丢失，尤其在使用 x-slot 时。这个问题在 9.x 修复，但部分人升级时没注意 patch 版本号，以为“升到 9 就安全了”。
更隐蔽的是缓存行为：Laravel 10 默认开启 Blade 编译缓存，而 @push 的内容是在运行时拼接的，如果缓存未失效，旧内容可能被复用。
- 确保
APP_DEBUG=true下开发时，每次修改@push内容后清空storage/framework/views/ - 避免在循环内无条件用
@push('scripts')，改为@pushOnce('scripts')防止重复插入 - 跨组件传递 JS 初始化逻辑时，优先用
data-属性 + 全局事件，比依赖@push更可控
