Laravel 不支持回滚单个迁移文件，migrate:rollback 仅作用于最高 batch 中的迁移；--path 仅筛选该 batch 内的子集，若目标迁移不在当前最高 batch 则静默跳过。
Laravel 没有原生命令支持回滚单个迁移文件。你执行 php artisan migrate:rollback --path=xxx 看似指定了文件，但它只在「当前可回滚批次内」生效；若该文件不在最新 batch 中，命令会静默跳过——不是功能没起作用，而是根本没被纳入回滚范围。
为什么 --path 参数常被误用
很多人以为 --path 能像 php artisan migrate --path=xxx 那样精准定位单个迁移，但 migrate:rollback 的逻辑完全不同：
-
migrate:rollback先查migrations表里最大batch值，只处理该 batch 下的所有迁移；--path只是进一步筛选这批里的子集 - 如果目标迁移文件属于
batch = 2，而当前最高 batch 是3，加--path也无效——它不会往前翻 batch - 路径必须写全名且区分大小写：
--path=database/migrations/2024_05_10_142300_add_status_to_users_table.php，漏掉database/migrations/前缀会失败
想撤掉某一个迁移？先确认它是否在可回滚范围内
别急着敲命令，先看数据表里它到底在哪一批：
- 运行
php artisan migrate:status，找到你要撤的迁移文件名对应的行，确认其状态为Ran且 batch 值等于当前最大 batch - 手动查库：
SELECT id, migration, batch FROM migrations ORDER BY batch DESC, id DESC LIMIT 10; - 如果它 batch 值明显更小（比如当前 max batch 是 5，它在 batch 3），说明它早已随之前某次 rollback 被撤过了，或压根没进过这轮 batch
down() 方法不健壮，回滚就中断
哪怕你成功触发了某个迁移的 down()，只要里面写了硬删除操作，大概率直接报错退出：
-
$table->dropColumn('status')在字段已不存在时，MySQL 8.0+ 和 SQLite 会抛SQLSTATE[42S22]: Column not found - 正确写法是先判断：
if (Schema::hasColumn('users', 'status')) { $table->dropColumn('status'); } - 删表也要用
Schema::dropIfExists('posts')，而不是裸写Schema::drop('posts') - 所有
DB::statement()原生 SQL 都必须在down()里配对写反向语句，否则 rollback 到这步就卡死
真要精确控制单个迁移，得绕过原生命令
没有银弹，但有可控路径：
- 临时把目标迁移在
migrations表里的batch值改成一个新数字（如999），再跑php artisan migrate:rollback --step=1—— 这样它就被拉进最新 batch 里了 - rollback 完后，立刻把
batch改回原值，否则下次migrate会混乱 - 更稳妥的做法：写个一次性 Artisan 命令，用
Schema::dropIfExists()或DB::statement('DROP TABLE ...')手动删结构，再从migrations表里DELETE对应那条记录
最易被忽略的一点：回滚不是“撤销代码”，而是“重放 down() 函数”。只要 down() 里有任何假设（比如“这张表一定存在”“这个字段还没被删”），它就会在非预期状态下崩掉——别依赖命令的“智能”，得靠你写的逻辑兜底。
