自增ID在GORM中默认行为不可靠，需谨慎使用：依赖数据库AUTO_INCREMENT/SERIAL建表时生效，但uint主键插入0值会报错；Gin中应检查db.Create().Error后再取user.ID；高并发下性能瓶颈在数据库层，非GORM问题；业务需全局唯一或分库分表时应改用Snowflake或UUID。
自增 ID 在 GORM 中默认行为是否可靠
Gin 本身不处理数据库 ID 生成，真正起作用的是 GORM 的 AutoIncrement 行为。默认情况下，只要结构体字段标记为 gorm:"primaryKey" 且类型是整数（如 uint、int64），GORM 就会依赖数据库的 AUTO_INCREMENT（MySQL）或 SERIAL（PostgreSQL）——但这仅在建表时生效，且要求底层驱动支持。
常见陷阱：用 uint 做主键时，若插入值为 0，GORM 会尝试显式插入 0 而非跳过，导致 MySQL 报错 ERROR 1062: Duplicate entry '0' for key；PostgreSQL 则可能因序列未初始化而报 nextval(): sequence "xxx_id_seq" does not exist。
- 确保迁移时启用自动建表或手动执行
CREATE SEQUENCE（PG）或确认引擎支持 AUTO_INCREMENT（MySQL） - 结构体字段不要赋零值，用指针或跳过字段：例如
ID *uint `gorm:"primaryKey"`，插入时不设该字段 - 避免在
CREATE TABLE后手动删重建序列（PG），否则 GORM 插入会卡在SELECT last_value FROM xxx_id_seq
Gin 请求中如何安全获取刚插入记录的 ID
很多人在 Gin handler 里写完 db.Create(&user) 就直接读 user.ID，这看似没问题，但实际依赖 GORM 是否成功将数据库生成的 ID 回填到结构体。它只在 Create 成功且主键字段可寻址时才生效。
典型失败场景：结构体字段是 int 非指针、字段名与数据库列名不匹配（如 Id vs id）、用了 db.Exec() 或原生 SQL 插入——这些都不会触发回填。
立即学习“go语言免费学习笔记（深入）”；
- 始终检查
err：即使user.ID看起来有值，也要先确认err == nil - 推荐写法：
if err := db.Create(&user).Error; err != nil { c.JSON(500, gin.H{"error": err.Error()}) return } c.JSON(201, gin.H{"id": user.ID}) - 若用
Select("id").Create()或批量插入，user.ID不会被填充，改用db.CreateInBatches()并配合db.Session(&gorm.Session{PrepareStmt: true}).Create()提升兼容性
高并发下自增 ID 是否成为性能瓶颈
不是 GORM 的问题，而是数据库层的锁机制决定的。MySQL 的 InnoDB 在 INSERT 时对自增锁（AUTO_INC lock）加表级短锁，PG 的序列（SEQUENCE）默认使用缓存（cache 1），每取一个值就刷一次 WAL，QPS 上千后延迟明显上升。
这不是“换 ORM”能解决的，关键看你怎么用。
- MySQL：升级到 8.0+，开启
innodb_autoinc_lock_mode=2（interleaved 模式），允许并发插入不阻塞 - PostgreSQL：建表时指定
INCREMENT BY 10和CACHE 100，减少序列访问频次；或改用gen_random_uuid()+ 唯一索引替代自增（适合无序场景） - GORM 层别做“预占 ID”之类操作——比如先
INSERT ... SELECT MAX(id)+1，这反而引发竞争和死锁
什么时候不该用数据库自增 ID
当业务需要 ID 具备时间顺序、全局唯一、可预测长度或分库分表友好时，自增 ID 很快会暴露短板：MySQL 主从延迟导致 ID 乱序、跨库难保证唯一、雪花算法（Snowflake）类 ID 更易做路由。
GORM 支持自定义主键生成，但要注意它不自动帮你发号——你得自己集成 Redis 自增、Twitter Snowflake 或数据库 UUID 函数。
- 用
gorm:"type:uuid;default:gen_random_uuid()"（PG）或gorm:"default:uuid_v4()"（MySQL 8.0+）可免服务层生成，但排序/索引效率略低 - 若坚持用 Snowflake，结构体字段设为
int64，插入前调用你的发号器（如snowflake.NextID()），然后显式赋值给user.ID，再Create—— 此时必须去掉gorm:"primaryKey"的自增语义，否则 GORM 仍会忽略你设的值 - 切勿混用：同一张表既用数据库自增又用服务端生成 ID，否则主键冲突无法回滚
自增 ID 简单有效，但它的“简单”只在单机、低并发、无需跨系统标识的场景里成立。一旦涉及分片、多活、导出导入或审计溯源，ID 的生成逻辑就得提前设计，而不是等上线后靠 GORM 标签硬补。
