直接查 migrations 表即可查看 Laravel 迁移记录，它存储每次迁移的文件名、batch 编号和执行时间；表不存在说明迁移系统未启动，表中有记录但表未生成属“假成功”，需核对文件、语法及日志。
直接查 migrations 表就能看到 Laravel 迁移记录
只要迁移执行过，laravel 就会把每次迁移的 file 名、batch 编号和执行时间写进数据库里的 migrations 表。它不依赖 phpmyadmin 特性，也不需要解析文件——打开 phpmyadmin，选中你的 laravel 数据库，点开 migrations 表，直接看内容就行。
常见错误现象：执行 php artisan migrate 没报错，但表没生成；或者反复执行提示 “Nothing to migrate”。这时先别翻代码，立刻去 phpMyAdmin 查 migrations 表里有没有新增行，有没有重复的 batch 值，有没有 id 跳变——这些比日志更真实。
表不存在？说明迁移根本没跑成功或被跳过了
migrations 表本身是 Laravel 第一次运行迁移时自动建的。如果连这张表都没有，基本等于整个迁移系统没启动：
- 确认
APP_KEY已配置（部分旧版 Laravel 在 key 缺失时静默跳过迁移） - 检查
config/database.php里'default'对应的连接是否真实可用（比如 MySQL 用户没权限建表） - 运行
php artisan migrate:status看命令行反馈——如果报Base table or view not found: 1146 Table 'xxx.migrations' doesn't exist，就是这问题 - 不要手动建
migrations表，用php artisan migrate:install（Laravel 8+ 已弃用，5.8–7.x 仍有效）或先执行一条最简单的迁移来触发建表
migrations 表里有记录，但对应数据表没生成
这是最典型的“假成功”场景：迁移逻辑被加载、SQL 也发给了数据库，但中途出错导致回滚，而 migrations 表却写入了（旧版 Laravel 存在此 bug，尤其在 MySQL strict mode 关闭时）。
排查重点不是看有没有记录，而是看记录和实际表状态是否一致：
立即学习“PHP免费学习笔记（深入）”；
- 对比
migrations表最后一行的migration字段（如2014_10_12_000000_create_users_table）和磁盘上database/migrations/下对应文件是否存在、是否被改名 - 检查该迁移文件里的
up()方法是否用了不支持的语法（比如在 MySQL 5.6 上用了JSON类型，或字段默认值写了NULL却没加->nullable()） - 打开 MySQL 的 general log 或查看 Laravel 日志（
storage/logs/laravel-*.log），搜索关键词SQLSTATE或errno—— 很多时候错误被吞掉了，只留一行Migration table not found，其实是建表语句本身失败
phpMyAdmin 显示乱码或时间错乱？调整连接字符集和时区
phpMyAdmin 默认可能用 utf8 连接 MySQL，但 Laravel 5.4+ 默认要求 utf8mb4；另外 migrations 表的 created_at 是 timestamp，若服务器时区和 PHP 不一致，时间会偏移。
不用改 phpMyAdmin 全局配置，临时解决只需：
- 在 phpMyAdmin 右上角「更多」→「设置」→「SQL 查询」里，执行：
SET NAMES utf8mb4; - 查表前加一句：
SET time_zone = '+00:00';（或匹配你config/app.php的'timezone'） - 如果发现
migration字段里中文路径显示为问号，说明该列是latin1编码，得用ALTER TABLE migrations CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;修正（仅限开发环境）
真正麻烦的不是看不到记录，而是看到记录就以为万事大吉。迁移成功与否，必须同时满足三件事：SQL 执行成功、事务提交成功、migrations 表写入成功——缺一不可，而 phpMyAdmin 只能帮你验证最后一条。
