buffalo g model仅生成基础字段和迁移骨架，字段类型由后缀指定（如email:string→text），但非空、唯一、索引等约束须手动修改迁移文件；结构体需补全tablename()、主键tag、时间字段及db映射。
buffalo g model 命令怎么指定字段类型和约束
Buffalo 的 buffalo g model 命令本身不支持直接声明非空、唯一、索引等数据库约束，它只生成带基础字段的 Go 结构体和迁移文件骨架。字段类型由参数名后的冒号后缀决定，比如 email:string 生成 VARCHAR，age:int 生成 INTEGER，active:bool 生成 BOOLEAN。
常见误区是以为 buffalo g model User name:string email:string 就能自动加唯一索引或 NOT NULL —— 实际上它默认全为 NULLABLE，且无索引。约束必须手动补在迁移文件里。
-
string→ TEXT（不是 VARCHAR，默认不限长；如需限制，得改迁移） -
int→ INTEGER（有符号；要无符号用uint，但 pop 不原生支持，需手动写 SQL） -
time→ TIMESTAMP WITH TIME ZONE（PostgreSQL）或 DATETIME（MySQL），但不会自动设为CreatedAt/UpdatedAt字段，除非你显式命名为这两个名字 - 字段名含下划线（如
first_name:string）会按 snake_case 映射，但结构体字段仍为FirstName，tag 里自动生成db:"first_name"
生成后必须立刻修改迁移文件加约束
运行 buffalo g model 后，它会在 models/migrations/xxx_create_users.up.fizz 里生成建表语句，但全是宽松定义。例如：
create_table("users", func(t) {
t.Column("name", "string", {"null": true})
t.Column("email", "string", {"null": true})
})
这会导致数据库字段允许 NULL，且无索引。真实项目中邮箱通常要 UNIQUE 且 NOT NULL，就得手动改：
create_table("users", func(t) {
t.Column("name", "string", {"null": false})
t.Column("email", "string", {"null": false, "unique": true})
t.Index("email", {"unique": true})
})
注意：{"unique": true} 在列定义里只加 UNIQUE 约束，但某些驱动（如 SQLite）不支持列级 UNIQUE，必须靠 t.Index 显式建索引才生效。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- PostgreSQL/MySQL：列级
{"unique": true}和t.Index效果一致 - SQLite：只写列级 unique 会被忽略，必须加
t.Index - 主键必须显式声明：
t.Column("id", "integer", {"primary": true, "auto_increment": true})，否则 fizz 可能不生成自增逻辑
字段 tag 和模型方法不能靠命令生成，必须手写
buffalo g model 生成的结构体只有基本字段和 db tag，但 pop 要求的硬性约定它一概不管。比如：
- 没生成
TableName()方法 → 运行时查users表却去找user，报错或静默空结果 - 没给
ID字段加db:"id"→ Save 时主键不识别，插入后 ID 为 0 - 时间字段叫
created_at，但没在结构体里声明为CreatedAt time.Time `db:"created_at"`→ pop 不会自动填充
所以生成后务必打开 models/user.go，补全：
func (u *User) TableName() string {
return "users"
}
// 并确保 ID 字段带 db:"id" tag
ID uint `db:"id,primarykey,autoincrement"`
CreatedAt time.Time `db:"created_at"`
UpdatedAt time.Time `db:"updated_at"`
漏掉任一，Save 或 First 都可能 panic 或返回空值，且错误信息极不直观。
别用 buffalo db migrate 直接跑，先验证迁移内容
很多人生成模型后直接 buffalo db migrate，结果表建错了还得 rollback、删库重来。正确流程是：
- 先
buffalo db migrate -dry-run看 SQL 输出，确认字段类型、约束、索引是否符合预期 - 如果用 SQLite，再额外检查是否漏了
PRAGMA foreign_keys = ON（关联加载依赖它） - 开发环境建议配
DB_DEBUG=true，让 pop 打印每条 SQL，方便发现字段映射失败（比如日志里出现INSERT INTO users (name) VALUES (?)却没传 email，说明 email 字段被忽略了）
最常被忽略的是：迁移文件改了，但忘了 buffalo db migrate；或者改了模型结构，却没写新迁移，导致代码和 DB schema 错位 —— pop 不做运行时校验，错配后行为不可预测。
