Laravel 的 migrate:rollback 默认只回退 batch 值最大的一批迁移；若 migrations 表中所有 batch 均为 0，说明迁移未被正式登记，命令将无效果；需先确认数据库连接、补录或重跑迁移，并避免在生产环境使用回滚。
php artisan migrate:rollback 执行后没变化？检查迁移文件是否被跳过
回滚命令不生效，最常见原因是 Laravel 认为当前没有「待回滚的批次」。它只回退 batch 值最大的那一批迁移（默认一次回退 1 批）。如果 php artisan migrate:status 显示所有迁移都标着 Ran，但 batch 列全是 0 或数值混乱，说明迁移表 migrations 没被正确记录——比如你手动执行了 SQL、用 php artisan migrate --force 跳过了某些检查，或数据库连接指向了错误的库。
- 先运行
php artisan migrate:status，确认最后一行的batch值是否 ≥ 1 - 若全是
0，说明迁移从未被「正式登记」，migrate:rollback无从下手，得先补录或重跑 - 检查
config/database.php中的connections配置，确保migrations表在当前连接的库中存在且可读写
回退指定数量的迁移：--step 参数不是万能的
--step=2 看似直观，但它回退的是「最近执行的 2 批迁移」，不是「最近 2 个迁移文件」。一批迁移可能包含多个文件（比如你用 php artisan migrate 一次性跑了 5 个新文件，它们共享同一个 batch 值），这时 --step=1 就会把这 5 个全撤掉。
- 用
php artisan migrate:status查看每行的batch和name，确认你要回退的是哪几个批次 - 如果只想撤掉某个特定文件（比如
2023_05_01_100000_add_status_to_users_table.php），不能靠--step，得用php artisan migrate:reset全部清空，再手动删掉该文件并重跑其余迁移（慎用） -
--step在 CI/CD 流水线里容易误判，建议只在本地开发环境使用
回滚失败报错 “Class not found”：autoload 没更新
删除或重命名了迁移文件后执行 php artisan migrate:rollback，常遇到 Class 'CreatePostsTable' not found。Laravel 回滚时仍会尝试加载已删除类的 down() 方法，而 Composer 的自动加载缓存还没刷新。
- 先运行
composer dump-autoload，强制重建类映射 - 如果迁移文件已删，但数据库里还留着记录，Laravel 会去 autoload 中找对应类名——此时要么恢复文件，要么手动从
migrations表中删掉那条记录（不推荐） - 更稳妥的做法：别删迁移文件，改用
php artisan make:migration fix_user_email_length --path=database/migrations/2023_05_01新建修正迁移，保持历史可追溯
生产环境绝对不要用 migrate:rollback
线上数据库结构变更必须可预测、可验证、不可逆。回滚操作依赖 PHP 运行时和迁移文件源码，一旦部署包里漏了某个 down() 方法，或数据库版本与本地不一致，就会卡死甚至损坏数据。
- 生产环境只允许执行
php artisan migrate，禁止任何回退命令 - 真正需要“撤销”的场景，应通过新增迁移实现逻辑补偿（例如加回字段、恢复默认值），而不是删结构
- 所有迁移文件提交前，必须保证
up()和down()都能独立运行成功，且down()不删关键数据（如用户表）
迁移不是 Git commit，回退动作本身就有歧义——是删表？是丢数据？还是改约束？Laravel 不做判断，它只按你写的代码执行。所以真正难的从来不是命令怎么敲，而是每次写 down() 时，得想清楚：这个操作，在三个月后的某次部署里，是否依然安全、可理解、可预期。
