uuid.new() 和 uuid.newv4() 功能完全等价，均生成 rfc 4122 v4 uuid，底层均使用 crypto/rand；uuid.new() 是 github.com/google/uuid 中的推荐简写，而旧库 satori/go.uuid 的 new() 行为不一致且已弃用。
uuid.New() 和 uuid.NewV4() 有啥区别？别用错
直接调用 uuid.New() 是最简写法，但它底层其实就等价于 uuid.NewV4() —— 都走加密安全随机数生成路径。但要注意：uuid.New() 来自 github.com/google/uuid，而老库 github.com/satori/go.uuid 的 New() 行为不一致（可能 fallback 到非加密源），已弃用。生产环境必须锁定 google/uuid。
常见错误是混用包导致行为漂移，比如：
- 误引入
satori/go.uuid后调用New()，在高并发下可能因 rand 源未加锁而轻微退化 - 用
Must(NewV4())忽略 error，但实际NewV4()只在crypto/rand.Read()失败时才返回 error（如系统熵池枯竭），这种失败极其罕见，但 panic 会直接中断服务
数据库主键用 UUID.String() 还是 []byte？性能差三倍
PostgreSQL、MySQL 8.0+ 原生支持 UUID 类型，存为二进制比字符串快得多。GORM 默认把 uuid.UUID 映射成 string，结果多存 36 字节、索引体积翻倍、JOIN 效率下降。
正确做法是显式指定类型：
- PostgreSQL：字段声明为
type ID uuid.UUID `gorm:"type:uuid;primaryKey"` - MySQL：用
binary(16)存 raw bytes，需手动转换：id.Bytes()写入，uuid.FromBytes()读取 - 避免在 WHERE 中用
WHERE id = 'a1b2c3...'::uuid字符串比较，改用参数化查询传uuid.UUID值
微服务间传递 UUID 时，大小写和连字符必须统一
UUID 字符串格式虽允许大小写混合（如 A1B2c3...）和省略连字符（a1b2c3...456789...），但不同语言/框架解析行为不一。Go 的 uuid.Parse() 接受大小写混合，但某些 Java 库（如 Apache Commons）默认只认小写；gRPC metadata 传输时若大小写不一致，会导致幂等校验失败。
强制标准化的实操建议：
- 所有输出统一用
id.String()（小写 + 连字符） - 输入解析一律用
uuid.Parse()，它内部会 normalize 大小写 - 禁止用
strings.ToLower(id.String())手动转小写——String()已保证小写 - API JSON 响应里不要省略连字符，否则前端 new Date() 等解析库可能误判
为什么 v1/v5 不适合做主键？时间戳和命名空间暴露风险
UUID v1 包含时间戳和 MAC 地址，v5 依赖 namespace + name 的 SHA-1 哈希。这两者在微服务主键场景下有硬伤：
- v1 的时间戳可被反推生成时间（精确到 100ns），MAC 地址可能暴露部署节点物理信息
- v5 的 namespace 若用业务字段（如 user_id），相同 name 在不同 namespace 下会碰撞；若用固定 namespace，则 hash 结果可被批量预测
- 两者都不满足“不可推测性”要求，而主键一旦泄露，可能被用于爬虫或越权探测
真正需要抗推测的场景（如订单号、分享链接 token），必须用 v4 或更严格的 crypto/rand 自定义生成 —— 它不带任何可推导信息，122 位纯随机，碰撞概率低于硬件故障率。
最后提醒：UUID 主键不是银弹。如果业务强依赖时间序（如 feed 流分页），得搭配 created_at 字段排序，不能指望 UUID 本身有序。
