不能直接用 uuid.New() 生成用户ID存数据库，因为其生成的UUID v4虽唯一但需确保格式统一（如带连字符的36位字符串），否则MySQL中VARCHAR(36)字段因格式不一致（如缺失连字符）导致查询失败或索引失效；同时GORM需显式声明gorm:"primaryKey;type:char(36);not null"且字段名为ID，否则默认启用int型ID主键。
为什么不能直接用 uuid.New() 生成用户ID存数据库
因为 uuid.New() 默认生成的是 UUID v4（随机），每次调用都是全新值，但用户标识需要“可预测的唯一性”——比如注册时生成一次、后续所有请求都复用同一个 ID。更关键的是，如果没做类型转换或序列化处理，直接把 uuid.UUID 存进 MySQL 的 VARCHAR(36) 或 CHAR(36) 字段，容易因格式不一致（带/不带连字符）导致查询失败或索引失效。
- 常见错误现象：
WHERE user_id = 'a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8'查不到数据，而'a1b2c3d4e5f67890g1h2i3j4k5l6m7n8'可以 —— 说明入库时丢了连字符或做了 trim - 推荐做法：统一用
uuid.Must(uuid.NewUUID()).String()（来自github.com/google/uuid）生成标准格式字符串，入库前不做额外 replace 或 toLower - 注意兼容性：PostgreSQL 原生支持
UUID类型，MySQL 不支持，必须用字符串类型；若用 GORM，记得给字段加type:varchar(36)tag，并确保gorm.Model中的 ID 字段类型是string而非uint
Gin 中如何在注册路由里安全生成并返回 UUID 用户 ID
别在 handler 里裸写 uuid.New().String() 然后塞进 JSON 返回 —— 缺少错误处理、没校验是否真生成成功、也没考虑并发下重复风险（虽然 v4 概率极低，但逻辑上应兜底）。正确做法是封装一个可复用的 ID 生成函数，并在插入数据库成功后再返回。
- 使用场景：用户注册接口
POST /api/v1/register，需要返回{"user_id": "xxx"} - 实操建议：用
github.com/google/uuid替代标准库crypto/rand手动拼接，它内部已处理熵源和错误 - 示例片段：
func generateUserID() string { uid := uuid.New() return uid.String() // 标准格式：8-4-4-4-12 } // 在 handler 中 userID := generateUserID() user := User{ID: userID, Email: req.Email, PasswordHash: hash} if err := db.Create(&user).Error; err != nil { c.JSON(500, gin.H{"error": "failed to create user"}) return } c.JSON(201, gin.H{"user_id": userID}) - 容易踩的坑：Gin 的
c.BindJSON()默认不会校验字段长度或格式，user_id字段若被恶意传入超长字符串（如 1000 字符），可能触发 DB 截断或 panic；建议用结构体 tag 加validate:"required,max=36"配合go-playground/validator
怎么让 Gin 的中间件自动注入当前用户的 UUID 到上下文
不是所有请求都带用户 ID，比如登录前的 /health 或 /login 接口。所以中间件得先判断 Header 或 Cookie 是否含有效 X-User-ID 或 token 解析出的 ID，再决定是否注入。硬编码 c.Set("user_id", ...) 容易漏掉类型断言或空值检查，导致后续 handler panic。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 使用场景：需要在多个 handler 中获取当前用户 ID 做权限校验或日志记录
- 参数差异：用
c.GetString("user_id")比c.MustGet("user_id").(string)更安全，前者返回空字符串而非 panic - 性能影响：每次请求都解析 JWT 并查 DB 获取用户信息很重，建议只解析 token 得到 UUID，再按需懒加载用户详情（例如用
db.First(&user, "id = ?", userID)） - 示例中间件：
func AuthMiddleware() gin.HandlerFunc { return func(c *gin.Context) { userID := c.GetHeader("X-User-ID") if userID == "" { c.Next() return } // 可选：加一层 UUID 格式校验 if _, err := uuid.Parse(userID); err != nil { c.AbortWithStatusJSON(400, gin.H{"error": "invalid user_id format"}) return } c.Set("user_id", userID) c.Next() } }
数据库迁移和 GORM 模型里怎么定义 UUID 主键字段
很多人以为只要字段类型设成 string 就行，结果发现 GORM 自动加了 id int 主键，或者 UUID 字段被忽略。根本原因是没关掉 GORM 的默认主键约定，也没告诉它这个 string 字段就是主键。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：插入后
ID字段为空，或报错ERROR: null value in column "id" violates not-null constraint - 实操建议：在模型 struct tag 里明确声明
gorm:"primaryKey;type:char(36);not null"，且字段名必须叫ID（首字母大写），否则 GORM 不认作主键 - 示例模型：
type User struct { ID string `gorm:"primaryKey;type:char(36);not null"` Email string `gorm:"uniqueIndex"` CreatedAt time.Time } - 注意点：MySQL 的
CHAR(36)比VARCHAR(36)更适合 UUID，因为长度固定，索引效率略高；但如果你用的是 MariaDB 10.4+，可以考虑BINARY(16)存压缩后的 UUID（用uuid.Must(uuid.FromString(s)).Bytes()转换），节省空间且排序更快
