Laravel只能按批次回滚，无法按单个迁移文件回滚；php artisan migrate:rollback --step=N是唯一原生支持的方式，它回滚最近N个batch（每次migrate执行产生的整批迁移），每个batch内的所有迁移文件被原子化处理。
只能按批次回滚，不能按单个迁移文件回滚 —— 这是 Laravel 原生命令的硬限制，所有“精准撤某几个文件”的需求都得绕开原生命令。
php artisan migrate:rollback --step=N 是唯一可控的回滚方式
它不是回滚 N 个迁移文件，而是回滚最近 N 个 batch（即 N 次 php artisan migrate 执行产生的记录）。每个 batch 可能包含多个迁移文件，它们被当作一个原子单元处理。
- 执行前先查当前最高 batch：
SELECT MAX(batch) FROM migrations;，避免误判步数 -
--step=1撤的是最新 batch（比如 batch=5），哪怕它含 7 个迁移文件，全部一起 down - 只要其中任意一个迁移的
down()报错（如删表失败、外键阻塞），整个 step 就中断，后续不会继续 - 不支持
--batch=3这类直接指定 batch 值的参数 —— Laravel 官方没实现这个功能
想只撤 CreateUsersTable 和 AddStatusToPosts？没有原生命令
Laravel 不提供按文件名、类名或时间戳筛选回滚的机制。所谓“指定文件回滚”，必须手动干预 migrations 表：
- 先确认这两个迁移的
down()方法是否真能安全执行（比如用Schema::dropIfExists('users')而非Schema::drop('users')） - 从
migrations表里查出对应记录的id和当前batch，把它们的batch值临时改成一个未使用的数字（如999） - 再跑
php artisan migrate:rollback --step=1，它就会去 rollback batch=999 的那批 - 回滚完立刻把
batch改回原值，否则下次migrate会跳过或重复执行
migrate:refresh 和 migrate:fresh 容易被误用
这两个命令看起来像“高级回滚”，但实际行为和部分回滚完全无关：
-
php artisan migrate:refresh=migrate:reset+migrate，它清空全部迁移历史再重跑，不是“选几条” -
php artisan migrate:fresh根本不走任何down()方法，而是直接调用DB::getDoctrineSchemaManager()->listTables()批量删表，风险极高 - 两者都会触发所有已注册迁移的
down()（或直接删表），一旦某个表被外键引用或正被应用读写，就卡死 - 加
--force只是跳过 yes/no 提示，**不校验 down() 是否可逆** —— 生产环境用它等于主动放弃安全兜底
真正麻烦的地方在于：batch 是隐式生成的，你无法在迁移文件里控制它；而 migrations 表一旦被手动改错，php artisan migrate 的状态判断就会失准。所以比“怎么回滚”更关键的，是每次 migrate 前确保 down() 已验证、batch 值未被污染、线上操作有备份快照。
