Go语言生成UUID方法详解

在Go语言中生成UUID，最稳妥、官方推荐且生产验证的方案是使用`github.com/google/uuid`库：它兼容泛型、API简洁、性能优异，`uuid.New()`即可安全生成符合标准的v4随机UUID（失败返回零值而非panic），无需手动拼接时间或随机数；格式化推荐直接用`fmt.Sprintf("%x", u)`高效获取32位小写hex字符串，避免低效截断；高并发下表现优异，单goroutine每秒轻松超5万次，无需额外同步优化；虽UUID并非万能（无序、定长、占空间），但对“简单、可靠、开箱即用”的唯一标识需求，它仍是当前最少意外、最值得信赖的选择——别再用已归档且不兼容新版Go的`satori/go.uuid`了。

用 github.com/google/uuid 生成 v4 随机 UUID 是当前最稳妥的选择

别再用 github.com/satori/go.uuid —— 它已归档、不再维护，且不兼容 Go 1.18+ 的泛型生态。官方推荐、生产验证、性能稳定、API 干净的只有 github.com/google/uuid。

• go get github.com/google/uuid 安装后，直接 import "github.com/google/uuid"
• 生成标准 v4：调用 uuid.New()（它本质是 uuid.NewRandom() 的安全封装，失败返回零值而非 panic）
• 不要自己拼接 time.Now().UnixNano() 或 rand.Intn() —— 这不是 UUID，只是“看着像”的字符串，多协程下极易重复
• v4 的唯一性靠 122 位加密随机数保障，10 亿个 ID 的冲突概率约 1e-15，比硬盘静默损坏还低

uuid.New() 和 uuid.NewRandom() 有啥区别？该选哪个？

绝大多数场景下，用 uuid.New() 就够了；只有你明确需要区分错误类型（比如要重试或打特定告警），才用 uuid.NewRandom() 显式处理 error。

• uuid.New()：内部调用 uuid.NewRandom()，出错时返回 uuid.Nil（全零 UUID），不 panic
• uuid.NewRandom()：返回 (uuid.UUID, error)，适合你主动判断失败原因（如 crypto/rand 不可用）
• 两者底层都走 crypto/rand.Read()，性能无差异；uuid.New() 更轻量，日常开发首选

怎么生成不带连字符的 32 位小写 hex 字符串？

别用 strings.ReplaceAll(u.String(), "-", "") 再切片 —— 多一次内存分配，还容易误删业务中本就含 “-” 的字段。直接用格式化更高效、更可控。

• 要 32 字符小写 hex：fmt.Sprintf("%x", u)（%x 按 UUID 字节序输出，无需手动调整）
• 要 32 字符大写 hex：fmt.Sprintf("%X", u)
• 要精简成 16 字符 ID（如文件名）：fmt.Sprintf("%x", u)[0:16]，但注意：这牺牲了全局唯一性保证，仅适用于“局部命名空间 + 低冲突容忍”场景
• 避免 u.String()[0:8] 这类截断 —— 它取的是字符串前 8 个字节（含 “-”），结果不可控

高并发下频繁调用 uuid.New() 会卡住或变慢吗？

不会。实测在普通云服务器上，单 goroutine 每秒轻松生成 5 万+，多协程并行百万级也无压力 —— 库内部已对 crypto/rand 读取和字节数组做了缓冲与复用。

• 真正要警惕的是：在热循环里反复 import、或每次生成都 new 一个新 rand.Reader
• 不需要自己上 sync.Pool 或预生成 channel —— 这属于过早优化，反而引入复杂度和阻塞风险
• 如果你真遇到瓶颈（比如每秒千万级 ID），优先检查是否误用了非加密随机源（如 math/rand），或是否在日志里高频打印完整 UUID 字符串（I/O 才是真瓶颈）

UUID 不是银弹。它定长、无序、占存储；如果业务需要时间有序、分片友好或更短 ID，得换 Snowflake、ULID 或 KSUID —— 但只要需求是“简单、可靠、开箱即用的唯一标识”，uuid.New() 就是最少意外的选择。

今天关于《Go语言生成UUID方法详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！