buffalo db 回滚需显式指定上一版 timestamp 版本号，执行 buffalo db migrate down -v ；down 不支持 -v -1 等简写，且 down 函数必须完整实现可逆操作，否则易失败。
buffalo db migrate 回滚到上一版迁移
Buffalo 的迁移回滚不能靠 buffalo db migrate -v 或类似参数直接指定“上一版”，它默认只向前执行。要回滚上一次成功应用的迁移，必须显式指定目标版本号（即上一个迁移文件的 timestamp 前缀），且该迁移必须已成功执行过。
- 先查当前已应用的迁移：运行
buffalo db migrate status，输出中带applied标记的行就是已执行的迁移，倒数第二行（如果存在）就是“上一版”的版本号，例如20240512103022 - 执行回滚命令：
buffalo db migrate down -v 20240512103022（把20240512103022换成你实际看到的上一版版本号） - 注意：
down不支持-v latest或-v -1这类简写，必须填完整 timestamp
回滚失败常见原因和应对
回滚失败往往不是命令输错，而是迁移本身不满足可逆性要求。Buffalo 使用 GORM 执行 SQL，而 GORM 对某些 DDL 操作（如 DROP COLUMN、RENAME TABLE）在反向迁移中缺乏自动推导能力。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 错误现象：
ERROR: migration failed: pq: column "xxx" does not exist—— 说明Down函数里写了删字段，但数据库里字段已被删，或上一次Up根本没成功 - 迁移文件里
Down函数为空或写成了return nil，导致回滚实际没做任何事 - 多个迁移共享同一 timestamp（比如手动复制了迁移文件），
buffalo db migrate down -v会尝试回滚所有匹配该时间戳的迁移，可能出错 - 解决办法：优先检查
migrations/下对应文件的Down实现；若不可逆操作已发生，建议用buffalo db migrate reset全量重置（仅限开发环境）
企业环境下慎用 buffalo db migrate down
生产环境不应依赖 buffalo db migrate down 做故障恢复。Buffalo 的迁移机制不记录执行上下文（比如哪台机器、哪个 deploy ID 执行的），也无事务包裹整个迁移过程，单条 SQL 失败会导致状态不一致。
- 上线前迁移脚本必须经过人工 review，
Down函数需覆盖所有Up中的副作用（包括索引、约束、默认值） - 连接池参数、超时、重试等不在 Buffalo 控制范围内，回滚期间 DB 连接中断可能导致迁移表卡在中间状态
- 更稳妥的做法是：把“回滚”拆成两个独立动作——先用备份还原元数据（
mysqldump --no-data+ 表结构快照），再用业务层补偿逻辑修复数据
真正棘手的从来不是命令怎么敲，而是迁移文件里那几行 Down 函数有没有覆盖所有 Up 引起的 schema 变更，以及你是否清楚上次 Up 到底执行到了哪一行 SQL。
