laravel只能按batch回滚，不能按单个迁移文件回滚；若migrations表中所有batch均为0，则rollback命令无反应，需先确认数据库连接、补录迁移或重跑，并避免在生产环境使用回滚。
不能按单个迁移文件回滚，只能按 batch 回滚 —— 这是 Laravel 原生命令的硬性限制，所有“只撤某几个文件”的需求都得绕开 php artisan migrate:rollback。
为什么 migrate:rollback 没反应？
最常见原因是 migrations 表里没有有效的 batch 值。Laravel 只回退 batch 最大的那一批，如果所有记录的 batch = 0（比如你手动执行过 SQL、用 --force 跳过检查、或连错了数据库），命令就完全静默。
- 先跑
php artisan migrate:status，确认最后一行的batch是否 ≥ 1 - 如果全是 0，说明迁移没被正式登记，
migrate:rollback无从下手 - 检查
config/database.php中的connections配置，确保migrations表在当前连接库中存在且可读写
--step 不是回退 N 个文件，而是 N 个 batch
php artisan migrate:rollback --step=2 会撤掉最近两次 php artisan migrate 执行产生的全部迁移，哪怕某次 migrate 一口气跑了 8 个文件，它们共享一个 batch，也会被一起撤掉。
- 用
php artisan migrate:status查看每行的batch和name，确认你要撤的是哪几个批次 - 如果某个
batch里的任意一个down()报错（比如删表失败、外键阻塞），整个--step就中断，后续不继续 -
--step在 CI/CD 流水线里容易误判，建议只在本地开发环境使用
想只撤 CreateUsersTable 和 AddStatusToPosts 怎么办？
Laravel 官方没提供按文件名、类名或时间戳筛选回滚的机制。强行做，必须手动干预 migrations 表：
- 先确认这两个迁移的
down()方法是否真能安全执行（比如用Schema::dropIfExists('users')，而不是Schema::drop('users')） - 查出它们在
migrations表中的记录：SELECT id, batch, migration FROM migrations WHERE migration LIKE '%create_users_table%' OR migration LIKE '%add_status_to_posts%'; - 把它们的
batch值临时改成一个未使用的数字（如999）：UPDATE migrations SET batch = 999 WHERE id IN (123, 456); - 再跑
php artisan migrate:rollback --step=1，它就会去 rollbackbatch = 999的那批 - 回滚完立刻把
batch改回原值，否则下次migrate会跳过或重复执行
migrate:fresh 和 migrate:reset 不是“精准回滚”
这两个命令常被误认为能选几个迁移来撤，其实完全不是：
-
php artisan migrate:fresh：不走任何down()，直接调用DB::getDoctrineSchemaManager()->listTables()批量删表，风险极高 -
php artisan migrate:reset：等价于--step设成最大batch数，会清空整个迁移历史，不是“选几个” - 两者都会触发所有已注册迁移的
down()（或直接删表），一旦某个表被外键引用或正被应用读写，就卡死 -
--force只跳过 yes/no 提示，**不校验down()是否可逆** —— 生产环境用它等于主动放弃安全兜底
真正麻烦的地方在于：batch 是隐式生成的，你无法在迁移文件里控制它；而 migrations 表一旦被手动改错，php artisan migrate 的状态判断就会失准。
