Protobuf结构体不能直接用作GORM模型，因其缺少gorm tag、零值覆盖风险、时间类型不兼容及嵌套字段映射困难；须定义独立GORM模型并手动/工具转换，禁止直接Updates，repeated字段宜存JSON，嵌套消息应拆分或扁平化。
Protobuf结构体字段无法被GORM自动映射
GORM靠结构体标签（如 gorm:"column:name"）识别数据库列，而Protobuf生成的Go结构体默认只有 json 和 protobuf tag，没有 gorm tag。直接把 pb.User 当作GORM模型传给 Create 或 Find，GORM会忽略所有字段，最终插入空记录或查不到数据。
常见错误现象：调用 db.Create(&pbUser) 后数据库里全是 NULL；或者 db.First(&pbUser, 1) 成功但所有字段都是零值。
- 不要复用 Protobuf struct 作为 GORM 模型 —— 它们语义不同：Protobuf 是通信契约，GORM struct 是数据持久化载体
- 必须定义独立的 GORM 模型 struct，并手动或工具辅助完成
pb.User ↔ UserModel转换 - 若强行加
gormtag 到 Protobuf struct，每次protoc重生成都会被覆盖，不可维护
零值覆盖导致数据库写入意外清空字段
Protobuf 的 proto.Unmarshal 默认行为是「未出现字段置零」，而 GORM 的 Save 或 Updates 会把零值（0、""、nil）当作显式更新意图。两者叠加，极易造成字段被静默清空。
例如：user := &UserModel{Name: "old"} 已存库中，再用 proto.Unmarshal(data, &pbUser) 解析一个不含 name 字段的请求体，接着 db.Model(user).Updates(pbUser) → Name 变成 ""。
- 禁止对 Protobuf struct 直接调用
Updates()；应先转为 map 或显式构造更新字段列表 - 使用
Select()明确指定要更新的字段，如db.Select("email", "age").Updates(&user) - 考虑用
map[string]interface{}接收解析结果，再按需赋值到 GORM 模型，避开零值陷阱
时间字段类型不一致引发转换失败
Protobuf 中常用 google.protobuf.Timestamp，对应 Go 里是 *timestamp.Timestamp（含秒+纳秒），而 GORM 原生支持的是 time.Time。两者不能直接赋值，且 timestamp.Timestamp 不实现 driver.Valuer 和 sql.Scanner，会导致 Scan 报错 unsupported Scan, storing driver.Value type *timestamp.Timestamp into type *time.Time。
- 在 Protobuf struct 转 GORM struct 时，必须显式调用
ts.AsTime()转为time.Time - 反向转换用
timestamp.Now()或timestamp.TimestampFromTime(t) - 别依赖 GORM 的自动类型转换——它对自定义 Protobuf 类型完全无感知
嵌套消息与 repeated 字段难以映射到关系型数据库
Protobuf 支持深度嵌套（message Address { string city = 1; }）和列表（repeated string tags = 1;），但关系型数据库没有原生等价结构。GORM 不会自动展开嵌套或序列化 repeated 字段，直接映射会丢数据或 panic。
典型报错：failed to convert field tags: unsupported data type []string；或嵌套 struct 插入时触发 invalid memory address or nil pointer dereference。
- repeated 字段建议存为 JSON 字符串（用
gorm:"type:json"+ 自定义Scanner/Valuer），而非尝试拆成关联表（除非业务强需查询单个元素） - 嵌套 message 应拆为独立 GORM 模型 + 外键关联，或扁平化为多个顶层字段（如
address_city,address_postal_code） - 避免在 GORM struct 中直接嵌入
*pb.Address—— 它不是 GORM 认可的类型，也不会触发关联操作
