Go-uuid已停止维护，应优先选用google/uuid；其因不支持Go modules、UUID v4非加密安全随机源、未适配分布式场景等问题被弃用。
Go-uuid 已停止维护，不建议在新项目中使用；当前应优先选用 google/uuid 或 github.com/google/uuid。
为什么不能直接用 github.com/satori/go.uuid
这个库早在 2019 年就标记为 Deprecated，作者明确不再维护。它存在几个实际问题：
- 不支持 Go modules，
go get在较新 Go 版本（1.16+）下会失败或拉取错误 commit - UUID v4 生成逻辑未使用 cryptographically secure 随机源（如
crypto/rand），在高安全要求场景下有风险 - 没有对时钟回拨、多节点并发等分布式 ID 场景做适配，纯 UUID 不解决排序或时间局部性问题
替换为 github.com/google/uuid 的实操步骤
这是目前最广泛采用的替代方案，兼容性强、API 简洁、默认使用 crypto/rand。
- 执行
go get github.com/google/uuid（Go 1.16+ 可省略-u） - 生成标准 UUID v4：
id := uuid.New().String() // 返回类似 "f47ac10b-58cc-4372-a567-0e02b2c3d479"
- 若需二进制形式（节省存储/网络传输），用
uuid.New()返回uuid.UUID类型，再调用.Bytes()或.MarshalBinary() - 注意：该包不提供 UUID v1（时间戳+MAC）——如需带时间序能力，得换其他方案（见下节）
需要时间有序 ID？别硬套 UUID，考虑 snowflake 或 ulid
UUID 本质是随机字符串，数据库索引写入性能差、无法按时间范围查询。真实架构中常需兼顾唯一性与时间局部性：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
-
github.com/oklog/ulid：基于时间戳 + 随机熵，字符串可排序，且比 UUID 短（26 字符）id := ulid.MustNew(ulid.Timestamp(time.Now()), rand.Reader).String()
-
github.com/bwmarrin/snowflake：Twitter Snowflake 变种，需配置 Node ID，适合固定集群规模 - 如果只是想让 UUID 按时间粗略排序，可用
github.com/google/uuid的uuid.NewUUID()（v4）不行，但该包不提供 v1；真要 v1，请用github.com/pborman/uuid（注意其NewRandom()是 v4，NewUUID()才是 v1）
在 Gin / Echo 等 Web 框架中注入 ID 的常见错误
很多人把 ID 生成塞进中间件，但容易忽略两点：
- 不要在中间件里用
uuid.New().String()后直接存到c.Set("request_id", ...)就完事——若后续 handler panic，日志里可能拿不到该 ID；应在 defer 日志或 recovery 中统一捕获 - 避免每层都重新生成：
service.CreateUser()内又调一次uuid.New()，导致 DB 主键和日志 ID 不一致；建议从 handler 层一次性生成，透传下去 - 若用
context.WithValue()传 ID，务必定义私有 key 类型（如type ctxKey string），别用string直接当 key，防止 key 冲突
真正麻烦的不是“怎么生成一个 UUID”，而是“在哪生成、怎么透传、怎么保证日志/DB/链路追踪三者 ID 对齐”。很多线上问题都出在 ID 泄漏或错位，而不是生成算法本身。
