php artisan migrate:rollback 没反应，是因为 migrations 表中所有 batch 值均为 0，说明迁移未被 Laravel 正式登记；常见原因包括手动执行 SQL、数据库连接错误、使用 --force 中断迁移等，需先运行 migrate:status 确认 batch ≥ 1 才可回滚。
php artisan migrate:rollback 没反应，不是命令错了，而是 Laravel 根本没找到可回滚的 batch —— 这是迁移状态断裂最典型的信号。
为什么 migrate:rollback 什么都没做？
它只回退 migrations 表中 batch 值最大的那一批记录。如果所有记录的 batch 都是 0，说明这些迁移从未被 Laravel「正式登记」过。
常见诱因包括：
- 手动执行了 SQL，绕过了
php artisan migrate -
config/database.php中配置的默认连接指向了错误数据库（比如连到了测试库，但migrations表在开发库） - 用
php artisan migrate --force强行跳过检查后又中断，导致部分 SQL 执行了、但记录没写入 - 从其他环境复制了迁移文件，但没同步
migrations表数据
先运行 php artisan migrate:status，盯着最后一行的 batch 列：不是 ≥1，就别指望 rollback 能起作用。
Class not found 错误：删了迁移文件还跑 rollback？
报错 Class 'CreatePostsTable' not found，90% 是因为迁移文件已被删除或重命名，但 migrations 表里还留着那条记录。
Laravel 回滚时会根据 migration 字段值（如 2023_05_01_100000_create_posts_table）去自动加载对应类，而 Composer autoload 缓存里已经找不到这个类了。
解决路径很窄：
- 恢复被删的迁移文件（最快）
- 运行
composer dump-autoload强制刷新类映射（仅当文件还在但类名/命名空间不一致时有效） - 手动从
migrations表中删掉那条记录（高风险，仅限本地且确认无依赖时操作）
更稳妥的做法是：永远别删迁移文件，而是新增一个修正迁移，比如 php artisan make:migration fix_users_email_length。
--step 参数的实际行为和陷阱
--step=2 不是「撤掉最近两个迁移文件」，而是「撤掉最近两次 php artisan migrate 执行产生的 batch」。一次 migrate 可能包含 5 个新文件，它们共享同一个 batch 值 —— --step=1 就会把这 5 个全干掉。
想精准控制范围，必须看 php artisan migrate:status 输出里的 batch 和 name 列：
- 若你想撤掉
batch=3的全部迁移，就执行php artisan migrate:rollback --step=1 - 若只想撤其中某个文件（比如
add_status_to_users_table），Laravel 原生不支持 —— 得临时改migrations表，把它的batch改成一个孤立值（如999），再rollback --step=1 -
--step在 CI/CD 流水线里极易误判，建议只用于本地调试
down() 方法失败的三个硬伤点
即使 rollback 找到了 batch，down() 仍可能静默失败或报错：
-
Schema::drop('users')→ 改成Schema::dropIfExists('users')，否则表已不存在时直接炸 - 外键约束阻止删表 → 在
down()里先用DB::statement('SET FOREIGN_KEY_CHECKS = 0;')临时关闭，或显式删外键 - 字段修改类迁移没装
doctrine/dbal→change()方法无法识别，报Unsupported alter operation，必须先composer require doctrine/dbal
真正麻烦的是那些已经上线、down() 逻辑写得不完整（比如删表却不处理关联数据）的迁移——这种文件绝不能动，只能靠新迁移补救。
