laravel 12 迁移出错应先查状态再恢复：运行 php artisan migrate:status、查 migrations 表和 show tables 确认实际状态，再按场景选 migrate:fresh、rollback 或 db:wipe；生产环境须用新增迁移修正，禁用回滚。
遇到 Laravel 12 迁移出错，重点不是“修复单个错误”，而是快速恢复数据库结构到一致、可用的状态。核心思路是：先确认当前状态，再选择最匹配场景的清理或重建方式，避免手动删表或改 migrations 表这类高风险操作。
查清当前迁移状态再动手
别急着回滚或重跑。先运行：
- php artisan migrate:status —— 查看哪些迁移已执行、哪些失败、属于哪个批次
- SELECT * FROM migrations WHERE migration LIKE '%modules%';（把 modules 换成你出问题的表名）—— 确认记录是否存在，是否被标记为已运行但物理表缺失
- SHOW TABLES LIKE 'modules'; —— 直接验证表是否存在，区分是“没建”还是“建了但数据不对”
按场景选恢复方式
迁移失败后，恢复方式取决于你是否还能接受丢数据、是否在本地开发、以及错误类型：
- 本地开发，无重要数据，想彻底重来：用 php artisan migrate:fresh --seed。它会删掉所有表（包括 migrations 表），重新运行全部迁移并填充测试数据，是最干净的起点
- 只想撤销最近一次改动（比如刚加了个字段导致报错）：用 php artisan migrate:rollback。它只撤回最新一批迁移（可能含多个文件），不会动其他已生效结构
- 迁移卡住、migrations 表记录混乱、或 up() 方法里有静默 return：先执行 php artisan db:wipe --force（Laravel 12+ 支持），再跑 php artisan migrate --seed。db:wipe 会清空所有表并重置迁移状态，比 migrate:reset 更彻底
常见静默失败要手动验证
如果 migrate 命令显示 “Nothing to migrate”，但表就是没生成，大概率是迁移没被识别或被跳过：
- 检查迁移文件名是否全小写+下划线（如 2024_05_10_120000_create_modules_table.php），类名是否完全匹配（CreateModulesTable）
- 打开 .env 确保 APP_DEBUG=true，让 SQL 错误不被吞掉
- 在迁移的 up() 方法开头加一行 Log::info('running create_modules_table');，确认它是否真被执行
- 简化 up() 内容，只留最基础的 Schema::create('modules', ...)，排除条件判断或环境检查干扰
生产环境千万别直接回滚
线上数据库结构变更必须通过新增迁移文件来修正，而不是 rollback 或 reset：
- 写一个新迁移，比如 fix_modules_table_structure.php，在里面修正字段、索引或关系
- 测试通过后再部署，确保 down() 方法也合理（哪怕只是注释说明“此迁移不可逆”）
- 用 php artisan migrate --force 强制运行（需在生产环境配置中允许）
