直接用 github.com/google/uuid 库最稳妥，它符合 rfc 4122，支持 v1/v4/v5 且线程安全；手动拼字符串或用 math/rand 生成的只是随机字符串，非标准 uuid。
Go 里生成 UUID，直接用 google/uuid 库最稳妥——它符合 RFC 4122，支持 v1/v4/v5，且线程安全；别自己拼字符串或调 math/rand，那不是 UUID，只是随机字符串。
为什么不用 crypto/rand + 手动格式化
有人想省依赖，用 crypto/rand.Read 填充 16 字节再格式化成 UUID 字符串。这能跑通，但问题不少：
- 没校验版本位和变体位（UUID v4 要求第 13 位是
4，第 17–19 位是8|9|a|b），生成的字符串可能被下游系统拒绝 - 缺少标准解析逻辑，比如
Parse或ParseBytes的容错处理（大小写、花括号、短横线） - 无法直接调
UUID.String()或UUID.Bytes()，后续序列化/网络传输容易出错
google/uuid 生成 v4 的正确姿势
v4 是最常用场景（纯随机），google/uuid 提供了两个等效函数，区别只在错误处理方式：
-
uuid.NewUUID()：返回uuid.UUID和error，需显式检查错误（推荐用于关键路径） -
uuid.New()：panic on failure（内部调uuid.Must(uuid.NewUUID())），适合快速原型或测试，生产环境慎用
示例：
id := uuid.New() // 简洁，但失败会 panic fmt.Println(id.String()) // e.g. "f47ac10b-58cc-4372-a567-0e02b2c3d479"
v1 和 v5 的使用边界与风险
v1 基于时间戳+MAC 地址，v5 基于 SHA-1 命名空间哈希——它们有明确适用场景，但也容易误用：
- v1：暴露生成时间（精度到 100ns）和网卡 MAC（若未禁用），内网服务可用，公网暴露有隐私风险；启用需
uuid.NewUUID()默认不开启，得手动调uuid.NewTime() - v5：需要指定命名空间（如
uuid.NameSpaceDNS）和名称（string），哈希结果固定；别把敏感数据当 name 直接传，SHA-1 不防碰撞，且 name 泄露即等价泄露原始输入 - 注意：
uuid.NewV5(ns, name)返回的是 v5 UUID，但name必须是[]byte，别传string还强转，会丢数据
性能与内存：字符串 vs 字节 vs 指针
UUID 在高频场景（如日志 traceID、数据库主键）下，选对类型直接影响 GC 和内存占用：
- 存数据库时，优先用
uuid.UUID类型（如github.com/google/uuid的 struct）而非string，PostgreSQL/pgx 支持原生uuid类型，避免字符串解析开销 - 网络传输中，用
id.Bytes()（16 字节）比id.String()（36 字节）节省带宽；反序列化时用uuid.FromBytes()比uuid.Parse()快约 3× - 别长期持有
*uuid.UUID指针——struct 本身才 16 字节，指针反而增加逃逸和 GC 压力
真正容易被忽略的点是：v4 UUID 的随机性依赖系统熵源，容器环境（尤其 init 容器）若未挂载 /dev/random 或熵池不足，uuid.New() 可能阻塞或降级到弱随机源——上线前务必验证 /proc/sys/kernel/random/entropy_avail 是否稳定 >1000。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
