安全最佳实践指南7 分钟阅读
UUID v4 实战指南：生成、存储与常见坑
说明 UUID v4 的工作原理、何时优于其他 ID 方案、数据库存储建议以及常见设计误区。
本指南包含
3
本指南使用的工具
1
相关主题
5
指南概览
UUID v4 使用加密安全随机数生成 128 位标识符。它非常适合分布式系统中的去中心化唯一 ID，但在数据库写入、可读性和索引表现上也有需要提前理解的权衡。
01
UUID 的格式与 v4 特征
UUID 通常写成 8-4-4-4-12 的十六进制格式，例如 f47ac10b-58cc-4372-a567-0e02b2c3d479。
其中 v4 的第三段总是以 4 开头，第四段则以 8、9、a 或 b 开头。这两个位置可以帮助你快速判断当前 ID 是否属于随机型 UUID v4。
本节相关工具
02
数据库里该如何存 UUID
直接存成 VARCHAR(36) 最直观，但相比二进制会浪费空间。PostgreSQL 有原生 UUID 类型，MySQL 则更适合考虑 BINARY(16) 这类更紧凑的表示方式。
不过 UUID v4 的随机性也意味着写入 B-tree 索引时位置会比较分散，插入量大时更容易出现页分裂和碎片化。如果你的表是高频写入场景，就应该把 UUID v7 或 ULID 也纳入评估范围。
本节相关工具
03
哪些情况下不适合继续用 UUID v4
UUID v4 的优势是唯一性强，但缺点也很明显：太长、不便人工识别、排查和沟通。在支持工单、短链接或需要人工输入的场景里，它常常不是最友好的选择。
如果你更在意可读性、排序性或数据库插入性能，可以考虑 nanoid、CUID2、UUID v7、ULID 等方案。真正合理的 ID 设计，应该同时考虑系统架构和运维体验。
本节相关工具