必须在phpMyAdmin中直接验证表结构，因迁移命令“成功”仅表示SQL执行完成，不保证字段类型、索引、默认值或外键约束按预期生效；需逐项核对迁移代码与表结构、检查migrations表记录状态、确认字符集和排序规则统一为utf8mb4_unicode_ci。
直接看数据库结构和数据，别信迁移命令的“成功”输出——它只说明 sql 执行了，不保证字段类型、索引、默认值或外键约束按预期生效。
在 phpMyAdmin 里定位 Laravel 迁移创建的表
Laravel 默认把表建在当前连接的数据库下，迁移文件名里的时间戳（如 2019_08_19_000000_create_users_table.php）通常对应表名 users。但注意：
- 表前缀（如
prefix_）会加在所有表名前，需查config/database.php中mysql.prefix配置 - 软删除字段
deleted_at是否存在，得点开表结构看，不是所有迁移都加 - 如果迁移用了
Schema::create('my_custom_table', ...)，表名就是字面值，跟文件名无关
验证字段定义是否与迁移代码一致
点开表 → “结构”页，逐项比对迁移中 Schema::table(...) 或 Blueprint 的定义：
-
$table->string('name')应为VARCHAR(255)，若看到TEXT或长度是191，可能是 MySQL 5.7+ utf8mb4 默认限制导致，需检查AppServiceProvider中是否调了Schema::defaultStringLength(191) -
$table->timestamps()应生成created_at和updated_at，类型必须是TIMESTAMP（不是DATETIME），且updated_at要有ON UPDATE CURRENT_TIMESTAMP属性——phpMyAdmin 在“结构”页“编辑”字段时能看到“属性”列 -
$table->foreignId('user_id')->constrained()不仅要字段存在，还要在“关系视图”页确认外键是否已建立（显示为锁形图标）
检查迁移是否真正执行过（避免重复或跳过）
Laravel 用 migrations 表记录执行状态，这个表本身也由迁移创建。进 phpMyAdmin 查 migrations 表：
- 每行对应一次
php artisan migrate执行，migration字段值应与迁移文件名（不含 .php）完全一致，如2019_08_19_000000_create_users_table - 若某迁移文件没出现在表里，说明它根本没跑；若出现两次，可能手动执行过或回滚后重迁失败
-
batch字段值相同表示同批执行，若中间某次失败，后续迁移可能被跳过——此时migrations表里会有断层，得结合 Laravel 日志查具体哪条 SQL 报错
最易被忽略的是字符集和排序规则：Laravel 新项目默认用 utf8mb4_unicode_ci，但旧数据库可能仍是 utf8_general_ci，导致 emoji 存储异常或索引长度超限。在 phpMyAdmin 的“操作”页点“排序规则”，确认整张表和每个文本字段都是 utf8mb4_unicode_ci —— 单改表不改字段没用。
立即学习“PHP免费学习笔记（深入）”；
