Pop 中需为自定义类型（如 UserID、Money）实现 pop.Scanner 和 pop.Valuer 接口，并在 pop.Open() 后、首次查询前调用 pop.RegisterScanner 与 pop.RegisterValuer 显式注册，否则会报 unsupported type 或写入零值。
Pop 中如何注册自定义字段类型转换器
Buffalo 默认用 pop 作为 ORM，但它的类型转换逻辑是封闭的：比如你定义了一个 Go 结构体字段为 time.Time，pop 会自动映射到数据库的 TIMESTAMP；但如果你用的是自定义类型（如 type UserID string 或 type Money int64），pop 不会识别，直接报错 unsupported type 或写入空值。
解决方式不是改 model struct 的字段类型，而是实现 pop.Scanner 和 pop.Valuer 接口，并在 pop 初始化时显式注册。这步必须在 pop.Open() 之后、任何查询执行之前完成。
- 定义类型时同时实现两个接口：
Scan(src interface{}) error和Value() (driver.Value, error) - 调用
pop.RegisterScanner(<your-type>, <scanner-impl>)和pop.RegisterValuer(<your-type>, <valuer-impl>) - 注意：必须对每个自定义类型分别注册，不能批量；且注册顺序无关，但必须早于第一次使用该类型字段的查询
常见错误：字段值始终为零值或 panic
典型现象是数据库能读出原始值（比如查出来是 "U123"），但结构体字段仍是空字符串或 0；或者直接 panic 报 cannot scan into dest。这基本是因为：
- 没实现
Scan方法，或方法签名不匹配（例如参数用了*string而不是interface{}） - 注册时传入的类型是
UserID，但 struct 字段声明为*UserID—— pop 不会自动解引用，必须注册指针类型版本（即*UserID） - 在
init()里注册了，但pop.Open()被多次调用（比如测试中反复初始化 DB），导致注册被覆盖或失效
示例：为 Money 类型支持 PostgreSQL 的 NUMERIC(10,2)
假设你有：
type Money int64 // 单位：分
func (m *Money) Scan(src interface{}) error {
if src == nil { *m = 0; return nil }
switch v := src.(type) {
case int64: *m = Money(v)
case float64: *m = Money(int64(v * 100))
case string:
if d, err := strconv.ParseFloat(v, 64); err == nil {
*m = Money(int64(d * 100))
}
}
return nil
}
func (m Money) Value() (driver.Value, error) {
return int64(m), nil
}
然后在 models/models.go 的 init() 函数末尾加：
pop.RegisterScanner(&Money{}, (*Money).Scan)
pop.RegisterValuer(Money(0), (Money).Value)
注意：第二个参数必须是方法值（method value），不是方法表达式（method expression），否则编译失败。
兼容性与陷阱：PostgreSQL vs SQLite vs MySQL
不同驱动对 Value() 返回值的容忍度不同：
- PostgreSQL 驱动（
lib/pq）接受int64，但若字段定义为NUMERIC，最好返回string（如fmt.Sprintf("%.2f", float64(m)/100)），否则可能精度丢失 - SQLite 驱动（
mattn/go-sqlite3）对nil处理更严格，Scan中遇到nil必须显式赋 0 并返回nil错误，否则 panic - MySQL 驱动（
go-sql-driver/mysql）要求Value()返回的driver.Value必须是基础类型（int64,string,[]byte），不能是自定义 struct
真正容易被忽略的是：pop 的 Scanner/Valuer 注册表是全局单例，一旦注册就影响所有连接池。如果你的服务要同时连多个异构数据库（比如订单库用 PG、日志库用 SQLite），必须确保同一类型在不同驱动下的行为一致，否则某条查询可能在某个库上成功、另一个库上静默失败。
