Gin中不应在handler内仅调用uuid.NewString()而不显式赋值给结构体字段，否则主键为零值导致插入失败；必须立即绑定到待入库对象，如user.ID = uuid.NewString()，并配gorm:"primaryKey"确保GORM识别。
为什么 Gin 里不该在路由 handler 中直接生成 UUID 主键
因为 Gin 本身不负责数据建模或主键生成，它只是 HTTP 路由和中间件框架。你在 gin.Context 里调用 uuid.New() 没问题，但“作为主键”这个动作实际发生在数据库插入或结构体赋值阶段——如果没显式赋值、又没设数据库默认值，主键字段就会是零值（比如 "" 或 "00000000-0000-0000-0000-000000000000"），导致插入失败或逻辑错乱。
- 常见错误现象：
ERROR: null value in column "id" violates not-null constraint（PostgreSQL）或 MySQL 报Field 'id' doesn't have a default value - 典型误用场景：只在 handler 里调用
uuid.NewString()，却没把它赋给结构体字段或传进 SQL 参数 - 更隐蔽的问题：用了
uuid.Must(uuid.New())但没处理 panic，一旦熵池枯竭（极少见）会 crash 进程
用 github.com/google/uuid 生成并安全赋值
推荐用 github.com/google/uuid，它比 crypto/rand 手写更可靠，且默认使用 v4（随机生成）。关键不是“怎么生成”，而是“生成后立刻绑定到待入库的数据对象上”。
- 必须显式赋值给结构体字段，例如：
type User struct { ID string `json:"id" gorm:"primaryKey"` Name string `json:"name"` } // handler 内 user := User{ ID: uuid.NewString(), // ← 这行不能少 Name: c.PostForm("name"), } - 如果用 GORM，确保字段 tag 里有
gorm:"primaryKey"，且类型是string；不要依赖gorm:"type:uuid"自动转换（GORM v2 对原生 UUID 类型支持有限） - 避免在模型定义里用
default:uuid_generate_v4()（PostgreSQL 函数）配合 GORM 的CREATE TABLE自动迁移——GORM 不解析该 default 表达式，会导致字段变成NOT NULL DEFAULT ''
PostgreSQL + GORM 下的兼容写法
如果你用 PostgreSQL 并希望主键由数据库生成（减少应用层依赖），得绕过 GORM 的自动 insert 流程，或改用原生 SQL。GORM 的 Create 默认不会跳过零值主键字段，所以即使 DB 有 DEFAULT gen_random_uuid()，GORM 仍会把空字符串当有效值传进去。
- 方案一（推荐）：禁用主键插入，让 DB 处理
db.Session(&gorm.Session{SkipHooks: true}).Create(&user) // 同时模型字段加 tag： // ID string `gorm:"primaryKey;default:gen_random_uuid();type:uuid"`注意：gen_random_uuid()需提前CREATE EXTENSION IF NOT EXISTS "pgcrypto" - 方案二：用
Exec直接执行 INSERT RETURNINGvar id string db.Raw("INSERT INTO users(name) VALUES (?) RETURNING id", name).Scan(&id)这时 DB 生成 UUID，应用直接拿到 - 别踩的坑：
db.Create(&user).Error之后再读user.ID—— 如果没配RETURNING或没开gorm:"，这个 ID 仍是空字符串
性能与唯一性要注意的实际边界
v4 UUID 理论碰撞概率极低，但在单机每秒上万次生成时，仍要确认熵源是否充足。不过对绝大多数 Web API，这不是瓶颈；真正容易出问题的是测试和事务一致性。
- 测试时别 mock
uuid.NewString却忘了在每个 test case 重置，否则可能因复用相同 UUID 导致UNIQUE constraint failed - 在事务内多次调用
uuid.NewString()是安全的，但不要用它做业务排序依据（无序、不可读） - 如果后续要支持分库分表或迁移到 Snowflake，现在就别把 UUID 当作“永远不变”的主键设计前提——它只是当前最省事的全局唯一方案
