GORM 不自动生主键值，因gorm:"primaryKey"仅设约束和查询逻辑，不干预值生成；需手动赋值或用BeforeCreate回调、第三方库实现。
GORM 不提供内置的主键生成策略（如 UUID、雪花 ID、自定义序列），必须手动控制主键值或借助第三方库注入。 它只负责“把字段设为主键”，不负责“怎么生成这个主键值”。
为什么 gorm:"primaryKey" 不能自动帮你生成值
GORM 的 primaryKey 标签仅影响建表语句（比如加 PRIMARY KEY 约束）和查询逻辑（如 First() 默认按该字段查），它不会拦截插入前的值生成。如果你声明了 ID uint64 `gorm:"primaryKey"`，但没给 ID 赋值，插入时就是 0 —— 数据库会报错（如果字段是 NOT NULL）或存入无效主键。
- 主键字段类型为
int/uint且未赋值 → 插入 0，大概率违反唯一性或非空约束 - 主键字段是
string且未赋值 → 插入空字符串""，同样可能冲突或不符合业务语义 -
gorm:"default:uuid_generate_v4()"这类数据库侧默认值，在 GORM 中不会被自动读取或回填（除非用Returning或手写 SQL）
常见主键类型对应的手动处理方式
你得在调用 Create() 前，自己确保主键字段有合法值。几种典型场景：
-
UUID 字符串主键：用
github.com/google/uuid生成，赋值给结构体字段user.ID = uuid.New().String() -
雪花 ID（Snowflake）：用
github.com/bwmarrin/snowflake初始化 node 后调用Generate()user.ID = node.Generate().Int64() -
数据库自增整数：字段类型用
int/uint，不设primaryKey以外的 tag，让数据库控制；但注意 GORM 默认会尝试写入 0，需显式跳过：db.Create(&user)→ 改为db.Omit("ID").Create(&user)，或更稳妥地用db.Create(&user).Scan(&user)配合Returning（PostgreSQL） - 业务编码（如 U202409210001）：自己写生成逻辑，插入前计算并赋值，别依赖 GORM 自动填充
BeforeCreate 回调是集中控制点，但要注意陷阱
你可以实现 BeforeCreate 接口，在插入前统一生成主键。这是最接近“策略”的做法，但必须小心：
立即学习“go语言免费学习笔记（深入）”；
- 回调函数接收的是指针
*gorm.DB和interface{}，你需要做类型断言才能操作具体字段 - 不要在回调里直接调用
db.Create()或其他写操作，会导致无限递归 - 若主键字段是嵌套结构体字段或指针类型（如
*string），判空逻辑要额外处理 - 示例：
func (u *User) BeforeCreate(tx *gorm.DB) error { if u.ID == "" { u.ID = uuid.New().String() } return nil }
全局主键策略难落地，建议按模型定制
有人想通过 NamingStrategy 或自定义 Callbacks 实现“所有模型主键自动 UUID”，但实际不可靠：
-
NamingStrategy只管名字映射，不管值生成 - 全局 callback（如
db.Callback().Create().Before(...)）无法区分哪些模型需要 UUID、哪些需要自增、哪些是业务编码 - 一旦某张表主键是联合字段（如
tenant_id + id），通用逻辑就失效
真正可维护的做法是：每个主键行为差异大的模型，单独实现 BeforeCreate；共性大的（比如全是 UUID 主键的微服务模块），封装一个基结构体或工厂函数来统一生成。
