buffalo中必须用sql.nullstring和sql.nullint64映射可空字段，因其valid字段显式标识null，避免scan失败或静默丢数据；直接用string/int会panic，且需配合数据库列nullable:true及手动valid判断。
Buffalo 框架中 NullString 和 NullInt64 怎么选
PostgreSQL 或 MySQL 中的可空字段（如 name VARCHAR NULL、score INT NULL）在 Buffalo 的默认 ORM（Pop）里不会自动映射为 Go 的指针类型，而是用 sql.NullString、sql.NullInt64 等标准库类型——这是最稳妥的选择，不是“可选”，是“必须”。直接用 *string 或 *int 会导致 Scan 失败或静默丢数据。
Pop 不会自动帮你把 NULL 转成 nil 指针，它依赖 sql.Null* 的 Valid 字段做显式判断。所以模型字段声明要严格匹配：
type User struct {
ID int `json:"id" db:"id"`
Name sql.NullString `json:"name" db:"name"`
Score sql.NullInt64 `json:"score" db:"score"`
}
-
sql.NullString对应数据库VARCHAR/TEXT可空列，String字段存值，Valid表示是否非 NULL -
sql.NullInt64是INT类型的唯一安全选择；别用sql.NullInt32，PostgreSQL 默认整型是 64 位，MySQL 的INT在 Pop 里也常被当作int64处理，类型不匹配会报cannot scan into dest - 自定义类型（比如
type NullEmail sql.NullString）可以，但需实现driver.Valuer和sql.Scanner，否则 Pop 插入/查询时会 panic
Pop 查询后怎么安全取值，避免 panic
直接访问 user.Name.String 是危险的——如果数据库值是 NULL，String 字段是空字符串，你无法区分“空字符串”和“NULL”。必须先检查 Valid：
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
if user.Name.Valid {
fmt.Println("Name:", user.Name.String)
} else {
fmt.Println("Name is NULL")
}
- 不要写
if user.Name.String != ""判断，这会把NULL和空字符串混为一谈 - JSON 序列化时，
sql.Null*类型默认输出{"String":"xxx","Valid":true}，不符合前端预期。应在序列化前手动转：例如JSONName: func() interface{} { if u.Name.Valid { return u.Name.String } else { return nil } }() - Pop 的
Find/All方法返回结构体后，所有sql.Null*字段的Valid已正确设置，无需额外调用 Scan
插入或更新时怎么传 NULL 值给数据库
Pop 不接受 nil 指针赋值到 sql.Null* 字段。要写入 NULL，必须显式设 Valid = false：
u := User{
Name: sql.NullString{Valid: false}, // 写入 NULL
Score: sql.NullInt64{Int64: 95, Valid: true},
}
- 千万别写
Name: sql.NullString{}——零值的Valid是false，但String也是空字符串，语义模糊；显式写{Valid: false}更清晰 - 前端传
{"name": null}到 Buffalo handler 时，JSON 解码后sql.NullString字段的Valid不会自动设为false，需要手动处理：if req.Name == "" { u.Name = sql.NullString{Valid: false} } - 使用
tx.Create(&u)时，Pop 会根据Valid字段决定是否在 INSERT SQL 中包含该列；设Valid=false后，该列不会出现在 VALUES 子句中，数据库自然填入 NULL
用 Buffalo 生成器建模时怎么避免空值陷阱
运行 buffalo g model user name:string score:int 生成的模型默认用 string 和 int，完全忽略 NULL。这会导致后续查询遇到 NULL 时直接 panic：sql: Scan error on column index 1: unsupported Scan, storing driver.Value type <nil> into type *string</nil>。
- 生成后必须立刻手动改字段类型：把
name string改成name sql.NullString，并补上import "database/sql" - Pop 迁移文件（
models/migrations/xxx_create_users.up.fizz）里要显式加nullable: true，例如：t.Column("name", "string", {"null": true})；否则即使代码用了sql.NullString，数据库列本身不可空，INSERT NULL 会失败 - 别依赖
fizz自动生成的down迁移——它可能把nullable: true列删成非空，导致回滚出错；建议手写down，或干脆不用down
空值不是边缘情况，而是数据库设计常态。Buffalo + Pop 的组合里，sql.Null* 不是“一种选项”，它是空值语义的唯一载体；漏掉 Valid 判断、错用指针类型、或迁移没开 nullable，三者任一都会让应用在某个看似普通的请求里突然崩溃。
