GORM V2 默认将整型ID字段识别为自增主键，但不自动为数据库列添加AUTO_INCREMENT；AutoMigrate不会修改已有字段属性，需手动DDL或显式建表声明；推荐用BeforeCreate钩子注入雪花ID，ID类型须为int64且钩子接收指针参数。
自增主键在 GORM 中的默认行为
GORM V2 默认把 ID 字段识别为自增主键，前提是类型为 uint、int、int64 等整数类型，且未显式禁用自增。但这个“默认”只影响模型定义时的映射逻辑，不等于数据库表一定建了 AUTO_INCREMENT。
常见踩坑点：
- MySQL 表没加
AUTO_INCREMENT，只靠 GORM 的primaryKeytag 不会自动补上，插入时会报ERROR 1364 (HY000): Field 'id' doesn't have a default value - 使用
uint类型但数据库字段是BIGINT UNSIGNED，可能因 MySQL 版本或 sql_mode 导致插入失败 -
AutoMigrate不会修改已有字段的属性（比如给已有id列加自增），只建新表或新增列
稳妥做法：建表 SQL 显式声明 id BIGINT AUTO_INCREMENT PRIMARY KEY，或在迁移前用 db.Migrator().CreateIndex 配合手动 DDL 补全。
用 BeforeCreate 钩子注入雪花 ID
替换自增主键最常用的方式是 GORM 的 BeforeCreate 钩子，在写入前生成 int64 类型的雪花 ID 并赋值给 ID 字段。它不依赖数据库，适合分布式部署。
关键注意事项：
- 结构体中
ID必须是int64（不能是uint64），否则 GORM 可能忽略赋值或触发类型转换错误 - 钩子函数必须接收指针参数：
func (u *User) BeforeCreate(tx *gorm.DB) error，否则修改无效 - 机器 ID 和时间戳需提前初始化，不要在钩子里实时调用
time.Now()或硬编码节点 ID，否则并发下序列号冲突概率上升 - 如果用第三方库（如
sony/sonyflake或bwmarrin/snowflake），注意其NextID()方法是否线程安全；不安全的实现需加sync.Mutex
示例片段：
func (u *User) BeforeCreate(tx *gorm.DB) error {
id, err := sf.NextID()
if err != nil {
return err
}
u.ID = int64(id)
return nil
}
UUID vs 雪花 ID：GORM 场景下的取舍
选 UUID 还是雪花 ID，本质是权衡「索引局部性」和「ID 可预测性」。GORM 本身不干预 ID 生成逻辑，但会影响字段定义和查询表现。
对比要点：
- 数据库存储：UUID 推荐用
CHAR(36)或BINARY(16)（后者需自行处理 hex-to-bin 转换），雪花 ID 用BIGINT即可，索引体积小 50% 以上 - 排序需求：雪花 ID 天然按时间递增，
ORDER BY id DESC查最新记录极快；UUID 无序，分页性能差，尤其大表 - 调试友好度：雪花 ID 是纯数字，日志/监控里一眼可读大致生成时间（高位时间戳）；UUID 完全随机，无法反推上下文
- GORM 关联操作：两者都支持
Preload和Joins，但外键字段类型必须严格匹配——比如关联表的user_id也得是BIGINT，不能一边UUID一边int64
雪花 ID 在 GORM 迁移与查询中的隐性约束
用了雪花 ID 后，AutoMigrate 依然能建表，但要注意几个 GORM 不会自动处理的细节：
- 主键字段不能带
autoIncrement:truetag，否则 GORM 会尝试插入NULL并触发数据库报错 - 如果想保留
db.Create(&u)语义（即不手动赋值 ID），必须确保钩子已注册且无 panic，否则ID为 0 插入失败 - 批量插入（
CreateInBatches）时，每个对象仍会单独走一次BeforeCreate，性能取决于 ID 生成器吞吐量；高并发场景建议预生成一批 ID 缓存复用 - 时间回拨问题不在 GORM 控制范围内，但可通过钩子中校验当前时间是否小于上次生成时间来 abort 写入，避免 ID 重复
真正容易被忽略的是：雪花 ID 的 41 位时间戳是从 2025-01-01 开始算的（常见偏移），如果你的系统要运行到 2106 年以后，得确认所用库是否支持扩展时间位——多数 Go 实现默认只支持约 69 年，超限后 ID 会归零重复。
