laravel 的 migrate:rollback 命令只回滚 migrations 表中 batch 值最大且 ≥1 的批次；若所有 batch 为 0，说明迁移未被正式登记；删迁移文件后需先 composer dump-autoload，否则报类未找到；--step 回滚的是批次而非文件数。
migrate:rollback 命令没反应，不是命令坏了，而是 Laravel 没找到可回滚的批次——它只看 migrations 表里 batch 值最大的那组记录，且该值必须 ≥ 1。
先查 migrations 表状态，别直接跑命令
运行 php artisan migrate:status，重点看最后一行的 batch 列：
- 如果所有行的
batch都是0，说明这些迁移从未被 Laravel「正式登记」——常见于手动执行 SQL、连错数据库、或用--force跳过检查 - 如果最高
batch是3，migrate:rollback就只撤batch = 3的那批（哪怕含 5 个文件） -
batch是按php artisan migrate执行次数生成的，不是按文件数算的
migrate:rollback 找不到类：autoload 缓存没更新
删了迁移文件后执行回滚，报 Class 'CreatePostsTable' not found，是因为 Laravel 还要去 autoload 中加载已删类的 down() 方法：
- 先运行
composer dump-autoload，强制重建类映射 - 更稳妥的做法是别删迁移文件，改用
php artisan make:migration fix_user_email_length --path=database/migrations/2023_05_01新建修正迁移 - 若已删文件且不想恢复，可手动从
migrations表中删掉对应记录（不推荐，易破坏历史一致性）
--step 参数误解：它回的是「批次」，不是「文件」
php artisan migrate:rollback --step=2 不是撤最近 2 个迁移文件，而是撤最近执行的 2 批迁移：
- 一批迁移可能包含多个文件（比如一次
migrate跑了 4 个新文件，它们共用同一个batch值） - 想精准撤某个文件（如
2023_05_01_100000_add_status_to_users_table.php），不能靠--step，得用migrate:reset全清再手动调整 -
--step在 CI/CD 流水线里容易误判，仅建议本地开发环境使用
真正卡住的地方往往不在命令本身，而在 migrations 表里那几条记录是否真实、完整、可追溯。批量操作前先确认 batch 值，比反复重试更省时间。
