回滚需同步处理代码与数据库版本，先用php artisan migrate:status定位失败点，再按git tag切回旧版并手动修复数据库；禁用migrate:reset/refresh，强调down()可逆性及预发布验证。
迁移失败后回滚到上一个版本，要分清“代码版本”和“数据库版本”两层——Laravel 本身没有“一键回滚应用”的命令，回滚必须同时处理代码与数据库，并确保二者状态匹配。直接只跑 php artisan migrate:rollback 而不切代码，极大概率导致代码调用不存在的字段或方法，引发500错误。
先确认失败点在哪一层
迁移失败通常发生在三类场景：
- 数据库结构变更失败：比如添加非空字段但没给默认值、修改列类型失败、外键冲突等；
-
迁移文件逻辑报错：如在
up()中执行了非法 SQL、调用了已移除的辅助函数； - 代码已上线但迁移未完成：新代码依赖刚新增的字段，而 migration 卡在中间，数据库没更新成功。
第一步不是急着回滚，而是运行：php artisan migrate:status
查看哪些迁移已标记为 “Ran”（已执行），哪些是 “Pending”。如果最后一条显示 “Ran”，说明迁移其实成功了，问题可能出在代码或缓存；如果显示 “Failed” 或根本没出现在列表里，说明迁移中途中断，数据库处于不一致状态。
安全回滚的完整操作步骤
假设你用 Git tag 管理发布（如 v1.0.0 是旧稳定版，v1.1.0 是刚部署但迁移失败的新版）：
- 进入部署目录：
cd /var/www/myapp - 检查当前 Git 状态：
git status（确保无未提交改动） - 硬重置到上一稳定 tag：
git reset --hard v1.0.0 - 重装生产依赖（尤其 composer.json 有变动时）：
composer install --no-dev --optimize-autoloader - 清 Laravel 缓存：
php artisan config:clear && php artisan cache:clear && php artisan view:clear - 重启 Web 服务：
sudo systemctl restart php8.2-fpm（按实际 PHP 版本调整）
⚠️ 注意：如果 v1.1.0 的迁移已部分写入数据库（比如建了表但没加字段），仅切代码不够——你还得手动修复数据库，或用 migrate:rollback 配合目标批次回退（见下一条）。
仅数据库回滚（适用于 migration 失败但代码未切换）
若你还没切代码，只是 php artisan migrate 报错退出，且想撤回最后一次尝试：
- 先查最近批次号：
php artisan migrate:status | grep "Ran" | tail -n 3 - 回滚最新一批（含所有该批次内文件）：
php artisan migrate:rollback - 若需回滚多批（例如刚连续跑了两次 migrate）：
php artisan migrate:rollback --step=2 - 确认回滚干净后，再执行
git reset --hard HEAD~1或切回 tag，保持代码与 DB 一致
不建议在生产环境用 migrate:reset 或 migrate:refresh，它们会清空全部表结构，风险极高。
预防下次再踩坑的关键习惯
真正减少回滚需求，靠的是部署前的防御性动作：
- 所有迁移文件的
down()方法必须可逆、经测试（本地migrate+rollback走通） - 上线前，在预发布环境完整走一遍：git checkout → composer install → migrate → smoke test
- 把回滚命令封装成脚本（如
./rollback.sh v1.0.0），包含 git 切换、依赖安装、缓存清理、服务重启全链路 - 对高危操作（如删字段、改类型）优先用“新增+迁移+清理”三步法，避免直接 down() 删除
