Laravel回滚失败主因是migrations表batch值异常（如全为0），导致命令跳过down()执行；应先运行php artisan migrate:status确认batch≥1，再检查Schema::drop需改dropIfExists、autoload未更新或外键约束问题。
down() 方法执行报错或没反应，先查 migrations 表状态
回滚失败时，migrate:rollback 命令本身不报错、但数据库结构没变，大概率是 down() 逻辑在运行前就被跳过或中断了。根本原因往往不在代码写得对不对，而在于 Laravel 根本没走到那一步——它先查 migrations 表，发现 batch 值异常（比如全为 0），就直接退出，连 down() 都不会加载。
务必先运行：php artisan migrate:status
重点看最后一行的 batch 值是否 ≥ 1。如果全是 0，说明这些迁移从未被正式登记（可能手动执行过 SQL、连错库、或用了 --force 跳过检查），此时改 down() 没用，得先补录或重跑迁移。
Schema::drop() 在 down() 里必报错，改用 dropIfExists()
这是最常踩的坑：Schema::drop('users') 在表已不存在时直接抛出异常，导致整个回滚中断；而 Schema::dropIfExists('users') 是安全兜底操作，不管表在不在，都能顺利往下走。
- 所有删表操作一律用
Schema::dropIfExists() - 删字段前加存在性判断：
if (Schema::hasColumn('users', 'phone')) { Schema::table('users', function (Blueprint $table) { $table->dropColumn('phone'); }); } - 外键约束要显式处理：先删外键再删表，或用
DB::statement('SET FOREIGN_KEY_CHECKS = 0;')临时关闭（记得恢复）
类找不到（Class not found）不是 down() 写错了，是 autoload 没更新
删了迁移文件、重命名了类名、或合并分支后漏了 autoload 更新，都会让 migrate:rollback 在加载类时失败，报 Class 'CreatePostsTable' not found。这不是逻辑问题，是 Composer 缓存没刷新。
解决方法很简单：composer dump-autoload
如果已删文件但 migrations 表里还有记录，Laravel 仍会尝试加载对应类——这时要么恢复文件，要么手动从 migrations 表删掉那条记录（仅限本地开发环境）。
想只撤某个迁移文件？别硬改 down()，用 batch 临时重定向
Laravel 没有 --path 或 --name 参数支持按文件回滚。所谓“指定文件回滚”，本质是把目标迁移记录的 batch 值临时改成一个未使用的数字（比如 999），再执行 php artisan migrate:rollback --step=1，让它去撤那个 batch。
操作步骤：
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
查出目标迁移：SELECT id, migration FROM migrations WHERE migration LIKE '%add_status_to_users%';
临时修改 batch：UPDATE migrations SET batch = 999 WHERE id = 123;
执行回滚：php artisan migrate:rollback --step=1
完事记得把 batch 改回去，否则下次 migrate 会混乱。
真正容易被忽略的是：batch 是隐式生成的，它取决于你调用 php artisan migrate 的次数，而不是文件数量或时间戳顺序。一次命令跑多个文件，它们共享同一个 batch —— 这个设计决定了你永远没法靠“名字”或“时间”精准控制单个文件的回滚。
