回滚到指定迁移批次只能用 php artisan migrate:rollback --step=N，按 migrations 表中 batch 倒序撤销整批迁移；无法按单个文件回滚，也无原生命令支持指定文件回滚。
回滚到指定迁移批次用 php artisan migrate:rollback --step=
想只撤回最近几条迁移，不是全退到空库，php artisan migrate:rollback --step=N 是唯一直接支持的方式。它按 migrations 表里的 batch 字段倒序撤销，每次撤一个 batch（即一次 php artisan migrate 执行时写入的全部迁移）。
常见错误是以为 --step 能按单个文件回滚——不能。比如你连续跑了三次 migrate，生成了 batch 1、2、3，那 --step=1 只会撤 batch 3，哪怕 batch 3 里有 5 个迁移文件，它们会一起被 rollback。
-
--step=2撤 batch 3 和 batch 2，不碰 batch 1 - 如果目标 batch 里某个迁移的
down()方法报错，整个回滚中断，后续 batch 不会动 - 执行前最好先查下当前最高 batch：
SELECT MAX(batch) FROM migrations;
想精确回滚某几个特定迁移文件？没有原生命令
Laravel 官方没提供“只撤 CreateUsersTable 和 AddStatusToPosts”这种按文件名回滚的功能。强行做，得手动干预：
- 确认那几个迁移文件的
down()方法逻辑正确且可逆（比如删表前要检查表是否存在） - 从
migrations表里找出对应记录的id和batch，把它们的batch值临时改成一个新数字（如 999），再跑php artisan migrate:rollback --step=1 - 改完记得把
batch改回去，否则下次 migrate 会混乱 - 更稳妥的做法：写个一次性 Artisan 命令，调用
Schema::dropIfExists()或DB::statement()手动删结构，再从migrations表删掉对应行
migrate:fresh 和 migrate:reset 的本质区别
这两个常被误认为“能精准控制”，其实都不是为部分回滚设计的：
-
php artisan migrate:fresh先删所有表（靠DB::getDoctrineSchemaManager()->listTables()），再重跑全部迁移 —— 它不管 batch，也不留数据 -
php artisan migrate:reset是按batch从大到小逐个执行所有已注册迁移的down()，相当于--step设成最大 batch 数 —— 它会清空整个迁移历史，不是“选几个” - 两者都会触发所有
down()方法，如果其中某个失败（比如试图删一个已被外键引用的表），整个过程就卡住
生产环境千万别用 --force 回滚未验证的 down 逻辑
本地测试时加 --force 是为了跳过确认提示，但它的真正风险在于：它不会校验 down() 是否真能安全执行。比如你在 down() 里写了 Schema::drop('users')，但线上 users 表有百万数据，或者被其他服务强依赖，这时候强制回滚等于直接断服务。
- 上线前必须在预发环境完整走一遍
rollback → migrate循环 - 涉及数据删除或结构变更的
down()，建议加上存在性判断：if (Schema::hasTable('xxx')) { ... } - 批量操作（如删数据）务必加
DB::table('xxx')->where(...)->delete()而不是truncate，方便加条件和观察影响行数
batch 是 Laravel 迁移的隐含锚点，不是版本号，也不是时间戳。它只代表“哪次执行写进去的”，理解这点，才能避开大部分误操作。
