go 的 uuid.new() 默认生成 uuidv4（纯随机），不带时间戳，故无法按时间排序；需时间顺序 id 应改用 gofrs/uuid/v5 的 newv1()。
Go 里 uuid.New() 默认生成的是 UUIDv4（纯随机），不是 Python 的 uuid1()；想用时间顺序 ID，必须显式调用 uuid.NewUUID()（已弃用）或改用 gofrs/uuid 的 NewV1()。
为什么 uuid.New() 生成的 ID 看起来“不按时间排序”
很多人从 Python 切过来，下意识以为 uuid.New() ≈ uuid1().hex[:16]，结果发现生成的字符串完全无规律——因为 github.com/google/uuid 自 v1.3 起就把 uuid.New() 绑定为 UUIDv4。它不带时间戳、不暴露 MAC、也不可预测。
- UUIDv4：128 位全靠
crypto/rand.Read()填充，安全且快，适合会话 ID、临时令牌等通用场景 - UUIDv1：含 60 位时间戳（精度 100ns）+ 48 位 MAC 地址，能按字典序粗略排序，但暴露设备信息，敏感环境需禁用 MAC
-
uuid.NewUUID()在新版中只是uuid.New()的别名，实际仍发 v4；它已被标记为deprecated，不要依赖
想用时间戳 ID？换 gofrs/uuid + NewV1()
github.com/google/uuid 不再维护 v1 支持，硬要上得自己拼时间+MAC+随机数，跨平台获取 MAC 极不稳定，容易出错。推荐直接切到 gofrs/uuid/v5：
- 安装：
go get github.com/gofrs/uuid/v5 - 生成：
u, err := uuid.NewV1()，失败通常因无法读取 MAC（Linux/macOS 需cap_net_raw或 fallback 到随机 HWAddr） - 提取时间：
ts, _ := uuid.TimestampFromV1(u); t := ts.Time()，可直接用于日志归档、分库分表路由 - 如需隐藏物理地址，传自定义
HWAddrFunc，返回全零或固定值（注意：这会让不同机器生成的 v1 在相同时间点碰撞概率微升）
String()[0:16] 截 UUID 是常见错误
UUID 字符串格式是 8-4-4-4-12，例如 "123e4567-e89b-12d3-a456-426614174000"，第 16 个字符可能是 '-' 或中间某个 hex 字符，id.String()[0:16] 可能截出 "123e4567-e89b-12" 这种带破折号、长度不准的结果。
- 正确做法一（推荐）：
fmt.Sprintf("%x", id)[:16]—— 输出 32 字符小写 hex，无分隔符，天然适配截断 - 正确做法二：
strings.ReplaceAll(id.String(), "-", "")[:16]—— 先去连字符再切，语义清晰但多一次分配 - 绝对别写
id.String()[0:8]或[0:12]—— 索引位置和语义无关，升级库或换版本后极易崩
高并发下 uuid.New() 变慢，不是算法问题
压测时 QPS 上不去、延迟毛刺增多，pprof 显示 runtime.syscall 或 crypto/rand.(*Reader).Read 占 CPU 高？那是每次调用都触发一次 /dev/urandom 读取（Linux/macOS）或系统 Crypto API（Windows），在容器冷启动、熵池不足、或每秒数万次调用时，syscall 成了瓶颈。
- 别用
math/rand替代 —— 它不安全、可预测、非线程安全，ID 生成绝不允许 - 可行优化：
sync.Pool缓存 16 字节数组，复用 buffer，手动置位 v4 版本（b[6] |= 0x40）和变体（b[8] |= 0x80） - 如果只要字符串，
fmt.Sprintf("%x-%x-%x-%x-%x", b[0:4], b[4:6], ...)比先uuid.New().String()再处理快 2–3 倍（实测百万次）
真正难的不是生成 UUID，而是选对版本、截对长度、扛住并发——v1 的时间语义、v4 的安全性、v5 的确定性，三者互斥，没法靠一个函数兜底。别让“唯一”变成“看似唯一”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
