uuid.New()默认生成UUIDv4（纯随机），非Python的uuid1()；uuid.NewUUID()已弃用，行为等同uuid.New()，真需时间序ID应改用uuid.NewV7()或手动构造。
uuid.New() 默认生成的是 UUIDv4（纯随机），不是 Python 的 uuid1()；想用时间序 ID，得明确调用 uuid.NewUUID()（已标记为 deprecated，但行为仍是优先 v1 降级 v4），或直接改用 uuid.NewV7()（如果库支持）。
uuid.New() 和 uuid.NewUUID() 到底有什么区别
很多人从 Python 切过来，下意识以为 uuid.New() 就等于 uuid1().hex[:16]，结果发现生成的 ID 完全没时间顺序、也没机器信息痕迹——因为 github.com/google/uuid 从 v1.3 起就把 uuid.New() 固定为 UUIDv4。
-
uuid.New()：稳定返回 v4，安全、快、推荐用于大多数场景 -
uuid.NewUUID()：尝试生成 v1（含时间戳 + MAC），失败时静默回退到 v4；但它已被标记为deprecated，新版中只是New()的别名，语义模糊，不建议新项目使用 - 真要时间序且可排序，优先考虑
uuid.NewV7()（需确认你用的github.com/gofrs/uuid/v5或兼容版本） - v1 在容器或某些云环境里可能因单调时钟不可靠而降级，这不是 bug，是设计行为
16 字符“短 UUID”怎么截才不翻车
直接 id.String()[0:16] 是常见错误：连字符位置固定但索引语义模糊，“123e4567-e89b-12d3-a456-426614174000”第 16 位可能是 - 或某个 hex 字符，切出来可能含破折号、长度不对、甚至 panic。
- 正确做法：用
fmt.Sprintf("%x", id)得到 32 字符小写 hex 字符串（无分隔符、字节序合规），再取前 16 位：fmt.Sprintf("%x", id)[:16] - 别用
strings.ReplaceAll(id.String(), "-", "")[:16]——多一次字符串分配，且语义冗余 - 更糟的做法：
id.String()[0:8]这类硬切，升级后格式微调就崩
高并发下 uuid.New() 会成瓶颈吗
现代 github.com/google/uuid（v1.4+）已内置优化，绝大多数场景下不会成为瓶颈：
-
uuid.New()底层复用crypto/rand.Reader，不每次打开/dev/urandom - 无锁竞争，goroutine 安全
- 单次生成耗时约 100–300ns（实测），远低于 HTTP handler 开销
- 除非你每秒要生成百万级 ID，否则自己套
sync.Pool或缓存[]byte属于过早优化，反而引入复杂度和潜在 bug
什么时候该用 uuid.NewV5()（命名空间 UUID）
当你需要「确定性 + 隔离性」，比如多租户 SaaS 中用户 ID 和订单 ID 必须绝对不重叠，又不想引入中心化发号器时，uuid.NewV5() 是解法：
立即学习“go语言免费学习笔记（深入）”；
- 命名空间必须是静态、全局唯一、不可变的，例如：
uuid.Must(uuid.NewSHA1(uuid.NameSpaceDNS, []byte("myapp.example.com"))) - 千万别用
time.Now().UnixNano()、rand.Intn()或runtime.GoroutineID()当 namespace —— Go 根本不提供稳定 Goroutine ID，这么做会让 v5 退化成 v4，还失去可复现性 - v5 使用 SHA-1 哈希，抗碰撞强，适合 URL、域名、租户路径等语义化标识场景
%x 格式化的依赖**。前者一旦写错，v5 就失效；后者一旦用错切法，文件名或日志 ID 就会出现连字符或长度异常，排查起来费时费力。 
