go 的 uuid.new() 默认生成 uuidv4（纯随机），非 python 的 uuid1()；需 v1 须手动组合时间、mac 和随机数；截取 16 字符应先去连字符或用 fmt.sprintf("%x", id)[:16]。
Go 里 uuid.New() 默认生成的是 v4，不是 Python 的 uuid1()
很多人从 Python 切过来，下意识以为 uuid.New() 就等于 uuid1().hex[:16]，结果发现生成的 ID 完全没时间顺序、也没机器信息痕迹——因为 github.com/google/uuid 从 v1.3 起就把 uuid.New() 设为默认生成 UUIDv4（纯随机），而 UUIDv1（时间+MAC）需要显式调用或手动构造。
-
uuid.New()→ 安全、快、推荐用于大多数场景，但不带时间戳语义 - 想模拟 Python 的
uuid1()行为？得用uuid.Must(uuid.NewUUID())（注意：NewUUID()已被标记为 deprecated，新版中它只是New()的别名，实际仍发 v4） - 真要 v1，得自己组合：用
time.Now()+ MAC 地址 + 随机数，再按 RFC 4122 手动填充字节 —— 不推荐，容易出错且跨平台 MAC 获取不稳定
16 字符“短 UUID”怎么截才靠谱
直接 id.String()[0:16] 是常见错误：连字符位置不确定（比如 "123e4567-e89b-12d3-a456-426614174000" 第 16 位可能是 '-' 或中间某个 hex 字符），切出来可能含破折号或长度不对。
- 正确做法是先去掉所有
'-'，再取前 16 字符：strings.ReplaceAll(id.String(), "-", "")[:16] - 更优写法是用
fmt.Sprintf("%x", id)，它输出 32 字符小写 hex、无分隔符，天然适配截断：fmt.Sprintf("%x", id)[:16] - 别用
id.String()[0:8]这类硬切 —— UUID 字符串格式固定但索引语义模糊，易在升级后崩
高并发下生成 UUID，别让 crypto/rand 成瓶颈
每次调用 uuid.New() 都会打开一次 /dev/urandom（Linux/macOS）或调用系统 Crypto API（Windows），高频下可能成为 syscall 瓶颈，尤其在容器冷启动或熵池不足时。
- 标准库
github.com/google/uuid内部已做缓冲优化，日常 QPS - 若压测发现
rand.Read占 CPU 高，可自己用sync.Pool缓存 16 字节数组，配合crypto/rand.Read复用 buffer - 极端场景（如百万级 ID/秒）建议预生成一批（例如 1000 个）进 channel，worker goroutine 消费，避免争抢全局 rand 实例
命名空间增强型 ID：什么时候该用 uuid.NewSHA1()
当你要确保不同服务、租户或模块的 ID 绝对不重叠（比如多租户 SaaS 中用户 ID 和订单 ID 必须隔离），又不想引入中心化发号器时，UUIDv5 是解法 —— 它用 SHA-1 把命名空间 + 名称哈希成确定性 ID。
- 命名空间必须是静态、全局唯一、不可变的，例如：
uuid.Must(uuid.NewSHA1(uuid.NameSpaceDNS, []byte("myapp.example.com"))) - 千万别用
runtime.GoroutineID()（Go 根本不提供稳定 Goroutine ID）、时间戳或随机数当 namespace —— 这会让 v5 退化成 v4，还失去可复现性 - v5 生成的 ID 仍是 128 位，同样可用
fmt.Sprintf("%x", id)[:16]截成短名，语义更强、碰撞概率理论更低
真正难的不是生成 UUID，而是选对版本、截对位置、管住命名空间。v4 简单可靠，v5 有语义但得守规矩，v1 看似“带时间”实则坑多——别为了看起来像 Python，就绕远路造轮子。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
