先确认表名是否带前缀且与DB_PREFIX一致，再检查表名大小写是否匹配Linux环境敏感性，接着验证migration是否真正执行成功，最后排查模型连接配置是否正确。
查表名是否带前缀，且和 DB_PREFIX 配置一致
laravel 默认不会自动加表前缀，但很多项目手动在 .env 里设了 db_prefix=laravel_，而迁移文件或模型里写的是裸表名（比如 users），结果运行时查的是 laravel_users —— 表实际不存在，就报“特定表不存在”。
实操建议：
- 打开
.env，确认是否存在DB_PREFIX，值是否为空或有空格（如DB_PREFIX= laravel_） - 进 phpMyAdmin，看真实表名：是
users还是laravel_users - 如果用了前缀，模型里要显式声明：
protected $table = 'laravel_users';，别依赖自动拼接 - 迁移文件中不要硬写带前缀的表名（如
Schema::create('laravel_users', ...)），应统一用config('database.connections.mysql.prefix') . 'users'或直接靠 Laravel 自动处理
检查 MySQL 表名大小写敏感性（Linux 环境最常见）
Windows 和 macOS 下 MySQL 默认不区分表名大小写，但 Linux 服务器默认开启 lower_case_table_names=0，此时 Users 和 users 是两张不同的表。Laravel 迁移生成的表通常是小写，但模型里写了 protected $table = 'Users';，就会找不到。
实操建议：
- 在 phpMyAdmin 左侧列表里，看清表名真实大小写 —— 是
users还是Users还是USERS - 检查模型中
$table值是否和 phpMyAdmin 显示的**完全一致**（包括大小写） - 不要指望
php artisan migrate自动修正大小写；它只按代码里写的建表，而 Linux 下建出来的就是严格大小写敏感的 - 临时验证：在 tinker 里执行
DB::select('SHOW TABLES LIKE "users"');，看能否命中
确认迁移是否真正执行成功，而非“假成功”
有时候 php artisan migrate 报 “Nothing to migrate”，但其实是因为 migration 文件名格式错（比如多了一个空格、扩展名是 .php.txt）、或 batch 记录异常，导致表根本没建。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 去 phpMyAdmin 刷新后直接看数据库里有没有那张表，别信命令行输出
- 查
migrations表，看对应 migration 的migration字段是否和文件名（不含路径和扩展名）**逐字符一致**，例如文件是2023_01_01_000000_create_users_table.php，那记录里必须是这串字符串 - 如果发现记录存在但表没有，说明 migration 内部出错了（比如字段定义语法错），被静默跳过 —— 此时要翻日志或加
--pretend参数重试 - 删掉
migrations表里对应记录 + 手动删掉已建但不全的表，再跑一次php artisan migrate
查 Eloquent 模型是否误配了连接或数据库名
一个容易被忽略的点：模型里写了 protected $connection = 'pgsql';，但当前环境只配了 mysql 连接；或者 protected $table = 'users' 没问题，但 protected $connection = 'tenant' 指向了一个空数据库。
实操建议：
- 在模型里临时加一行
dd(DB::connection($this->connection)->getDatabaseName());，看连的是不是你认为的那个库 - 确认
config/database.php中对应连接的'database'配置值，和 phpMyAdmin 当前选中的数据库名**完全一致**（注意空格、下划线） - 如果用了多数据库，别假设所有模型都走默认连接；
User::on('mysql')->get()和User::get()可能查的是两个库
大小写、前缀、连接配置、迁移状态——这四个点只要漏查一个，就卡在“表不存在”上。尤其是 Linux 服务器 + 开发本地 Windows，大小写问题几乎必现，但很多人第一反应永远是“是不是 migration 没跑”，反而跳过最该先看的 phpMyAdmin 表名本身。
