buffalo迁移脚本必须放在models/migrations/目录下，命名严格为yyyymmddhhmmss_description.up.fizz或.down.fizz格式，依赖时间戳排序执行；fizz语法需用抽象类型而非原生sql，外键须显式声明，回滚须手动编写对称逻辑，文件编码须为utf-8 without bom。
Buffalo 框架里迁移脚本该放哪、怎么命名
Buffalo 的迁移脚本必须放在 models/migrations/ 目录下，且文件名需严格遵循 YYYYMMDDHHMMSS_description.up.fizz 或 .down.fizz 格式（例如 20240515103000_add_users_table.up.fizz）。Buffalo 依赖文件名里的时间戳排序执行顺序，手动改时间或重命名会导致 buffalo pop migrate 跳过或乱序——哪怕只差一秒。
常见错误：把 .up.fizz 写成 .up.sql，或漏掉时间戳前导零（如写成 2024515103000），Buffalo 会直接忽略该文件，不报错也不提示。
fizz 语法写增删改表操作要注意什么
fizz 是 Buffalo 默认的迁移 DSL，不是 SQL，不能直接写 CREATE TABLE 原生语句。它用链式调用描述结构，比如建表要写成：
create_table("users", func(t *Table) {
t.Column("id", "uuid", {"primary": true})
t.Column("email", "string", {"null": false})
t.Column("created_at", "timestamp", {})
})
关键点：
-
t.Column("name", "type", opts)中type必须是 fizz 支持的抽象类型（"string"、"int"、"bool"、"uuid"等），不是数据库原生类型（如"VARCHAR(255)"） - 外键必须显式调用
t.ForeignKey("user_id", "users", {"on_update": "CASCADE"})，不能靠字段名自动推断 - 添加非空字段时，若表已有数据，
{"null": false}会失败；得先加可空字段，再用alter_column补默认值，最后设为非空
如何安全地回滚迁移（down.fizz）
.down.fizz 不是 .up.fizz 的简单逆序，尤其涉及数据变更时。比如 .up.fizz 中执行了 add_column("users", "status", "string")，对应的 .down.fizz 应该是 drop_column("users", "status")，而不是 remove_column（后者不存在）。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
更关键的是：如果 .up.fizz 包含 exec("UPDATE users SET status = 'active'") 这类数据操作，.down.fizz 必须明确还原逻辑（比如 exec("UPDATE users SET status = NULL WHERE status = 'active'")），否则回滚后数据状态不可逆。
Buffalo 不校验 up/down 是否对称，也不会阻止你提交一个没写 .down.fizz 的迁移——但生产环境严禁这么做。
运行迁移时为什么提示 “no migrations to run”
最常见原因是 pop.Connection 配置未指向正确数据库，或 models/migrations/ 下没有未执行的迁移文件。检查三件事：
- 运行
buffalo task db:status看当前 migration 版本和 pending 列表 - 确认
database.yml中development环境的url可连通，且pop已加载该配置（pop.Connect("development")） - 执行
buffalo pop migrate -e test时，实际读的是test环境的database.yml和models/migrations/，别和开发环境混淆
另一个隐蔽坑：迁移文件权限为只读，或文件编码含 BOM，Buffalo 会静默跳过——建议用 file models/migrations/*.fizz 确认编码是 UTF-8 without BOM。
