应手动向migrations表插入记录：执行INSERT INTO migrations (migration, batch) VALUES ('2019_01_01_000000_create_categories_table', 1)，其中migration值须严格匹配迁移文件名前缀（不含.php），batch通常填1；操作前需确认数据库连接正确、文件路径规范且未被忽略，避免因连错库或路径错误导致跳过失败。
怎么手动往 migrations 表里插记录
当某个迁移文件已执行过 SQL（比如你用 SQL 导入了表），但 Laravel 还没在 migrations 表里记账，php artisan migrate 就会重复跑它并报错 SQLSTATE[42S01]: Base table or view already exists。这时最直接的办法就是手动补一条记录进去，让 Laravel “以为它已执行”。
- 确认迁移文件名（含时间戳）：比如
2019_01_01_000000_create_categories_table.php，对应migration字段值就是2019_01_01_000000_create_categories_table -
batch值填 1 即可（除非你明确知道当前最大 batch 是几；填错只影响后续回滚粒度，不阻碍本次跳过） - 执行 SQL：
INSERT INTO migrations (migration, batch) VALUES ('2019_01_01_000000_create_categories_table', 1); - 别漏掉单引号——字符串字段必须加，否则 MySQL 报错
Unknown column 'xxx' in 'field list'
为什么不能直接删 migrations 表里的旧记录
删记录看似能“重来”，但风险明显：如果该迁移已被其他迁移依赖（比如后续迁移里有 foreignId('category_id')->constrained()），删掉建表记录后，再跑 migrate 会因外键找不到父表而失败。更麻烦的是，migrate:rollback 会按 batch 回退整批，你删了一条，可能把整批都搞乱。
- 只在开发环境操作；生产环境禁止手动改
migrations表 - 执行前先备份：
SELECT * FROM migrations WHERE migration = 'xxx'; - 如果迁移已和其他变更耦合（如字段修改、索引添加），补记录比删记录更安全
用 php artisan migrate --pretend 看它到底想跑谁
--pretend 不真执行 SQL，只打印将要运行的迁移列表和语句。它能帮你确认：是不是你以为“已跳过”的那个文件，其实根本没被 Laravel 识别到？
- 运行：
php artisan migrate --pretend - 输出里没出现目标迁移 → 检查文件命名是否规范（必须是
YYYY_MM_DD_HIS_create_xxx_table.php格式）、是否在database/migrations/下、是否被.gitignore忽略 - 输出里出现了，但后面跟着
CREATE TABLE categories→ 说明它确实打算建表，此时补记录或注释up()才是正解 - 注意：
--pretend不校验数据库连接，连错库也会照常输出，务必先核对.env中的DB_DATABASE
补记录后还报错？检查这些隐藏条件
手动插入记录只是第一步。Laravel 启动迁移时还会校验其他东西，漏掉任一环节都会卡住。
-
DB_CONNECTION和DB_DATABASE是否指向你正在操作的库？连错库会导致记录插进 A 库，但migrate在 B 库查表，永远“看不见” - MySQL 版本低于 5.7.7 或 MariaDB 低于 10.2.2？需提前在
AppServiceProvider::boot()加Schema::defaultStringLength(191)，否则建索引时爆Specified key was too long - 迁移文件里用了
DB::unprepared()或原生 SQL？--pretend不模拟这类语句，但真实执行时仍会报错，得单独验证
补记录这事本身很简单，难的是确认“它真被跳过了”——而不是因为连错库、读错路径、或版本不兼容，让你误以为跳过成功。
