uuid.New() 默认生成合法 RFC 4122 v4 UUID，手写易漏关键位操作（u[6]设版本、u[8]设变体），导致跨语言解析失败；高并发瓶颈在 crypto/rand 系统调用，非算法本身，应优先用 sync.Pool 优化而非自实现。
直接用 github.com/google/uuid 的 uuid.New() 就够了，99% 场景下无需自己实现——它默认就是 RFC 4122 v4，线程安全、无冲突、已过生产验证。
为什么别手写 uuid.New() 的替代逻辑
手写容易漏掉两个强制位操作，导致生成的字符串看似随机，实则不合法：
-
u[6]必须设置为(u[6] & 0x0f) | 0x40—— 确保版本字段是0100（即 v4） -
u[8]必须设置为(u[8] & 0x3f) | 0x80—— 确保变体字段是10xx（RFC 4122 variant 1）
漏掉任一操作，uuid.Parse() 可能成功（因宽松解析），但跨语言（如 Java 的 UUID.fromString()）或严格校验工具会拒绝。更危险的是用 math/rand 替代：不安全、可预测、非线程安全，且无法满足 v4 的比特位约束。
uuid.New() 在高并发下变慢？先确认是不是真瓶颈
真实瓶颈往往不在算法，而在 crypto/rand.Read() 的系统调用开销，尤其在容器冷启动、熵池不足或 QPS > 5k 的场景。现象包括：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
pprof显示runtime.syscall或crypto/rand.(*Reader).Read占 CPU 高 - 压测时延迟毛刺明显，QPS 上不去
不是 uuid.New() 本身慢，而是每次调用都 malloc + syscall。此时才值得上 sync.Pool 优化，而不是一上来就手写。
真要自定义高性能生成器：复用 buffer + 手动位修正
如果确认是性能瓶颈，且已压测验证，可用以下最小改动方案（比原生快 2–3 倍）：
- 用
sync.Pool缓存[]byte，避免每次分配 16 字节和 GC 压力 - 必须手动设置第 6 字节（
buf[6] = (buf[6] & 0x0f) | 0x40）和第 8 字节（buf[8] = (buf[8] & 0x3f) | 0x80），否则不是合法 v4 - 字符串化用
fmt.Sprintf("%x-%x-%x-%x-%x", ...)，别用encoding/hex.EncodeToString全量编码再切分——更慢、分配更多内存
最容易被忽略的一点：所有自定义实现里，两处位操作缺一不可；少一个，ID 就不符合 RFC，跨系统交互时会在最意想不到的地方失败。
