在大部分业务里，你绕不开“唯一标识符”。注册用户、上传文件、订单、消息、请求链路……凡是要“唯一定位”的地方，都需要一个不重复、可追踪的ID。很多团队一开始用数据库自增主键，后来遇到分库分表、数据迁移、服务解耦，再回头补分布式ID，往往会很痛。本文不铺陈理论，而是以工程视角，讲清楚为什么大量团队会选择 UUID，以及如何把它稳稳地落到生产。
第一件事：别纠结“到底会不会撞”。对UUID v4而言，生成 10^12 个出现一次碰撞的概率仍然极低。多数互联网业务规模下，“撞不撞”不是关键矛盾，真正的矛盾在“存储、索引与排序”。这三个点没处理好，你就会觉得“UUID不好用”。
先说存储。把UUID当字符串 CHAR(36) 存，是能用，但不优。36个字符不仅空间更大，索引页利用率也更差；如果业务写入量较高，你会感觉性能不稳。建议直接二进制存 BINARY(16)，MySQL/PG 都有成熟方案：写入使用 UUID_TO_BIN()，读取用 BIN_TO_UUID()。迁移老表也简单：新增二进制列，逐步双写，最后切换主键。
第二是索引与排序。UUID v4 完全随机，作为主键天然“无序”，插入B-Tree索引会产生更多页面分裂。如果你的表是“写多读少”，问题不大；但若是高写入+高查询，建议：
- 不要拿UUID做默认排序字段，额外保留
created_at或sequence字段； - 与时间强相关的数据（例如日志、事件流），可以考虑 v1/v7 一类的“时间有序”方案；
- 千万别在没有必要的地方“联索引 + 模糊条件 + 随机排序”，组合拳下任何主键都扛不住。
第三是风控与可观测。UUID本身“不可预测”，对外暴露要更安全一些，但你仍然需要日志与链路追踪：网关处打 X-Request-ID，下游服务透传，告警和排障靠这根“线”串起来。统一追踪ID与业务ID并存，是工程可维护性的关键细节。
落到代码层面，前后端都很简单：
- 浏览器原生
crypto.randomUUID()就能得到一个 v4； - Node/Java/Python 等语言均有稳定库；
- 生成在“边界”做，不要让中间层“同时负责生成又负责校验”。职责清晰了，问题才好排查。
工程里经常被忽略的，是“格式统一”。一套服务里，有的环节返回大写，有的环节返回小写；有的带连字符，有的不带；有的走字符串，有的走二进制。规范定不下来，日志与数据分析就会碎片化。建议在网关层就统一：
- 对外API一律字符串小写、带连字符；
- 存储走二进制
BINARY(16)； - 日志打印统一格式，便于检索；
- 文档明确输入输出的大小写与连字符约定。
对于“批量生成”的需求（比如压测数据、模拟订单），不要在命令行里手搓循环，直接用现成的工具一键生成、下载文本或CSV，省心省力。我们的在线工具“UUID生成器”支持 v1/v3/v4/v5/v6/v7 多版本，支持 1 到 1,000,000 的批量生成，并且能按 string/hex/binary/base64 多格式导出，适合临时数据和联调自测。
关于版本选择，给出一个非常接地气的判断树：
- 绝大多数后端业务：v4 即可；
- 需要时间有序（写入更平滑、排序友好）：优先 v7（或 v1，但注意隐私泄漏与机器时钟问题）；
- 需要确定性（相同输入拿到相同输出）：v5（基于命名空间+名称的哈希）。
迁移建议也一并写在这里，避免掉坑：
- 老表若是自增ID，新增一个
uuid_bin BINARY(16)列并创建唯一索引； - 双写阶段：写入时同时填充自增与UUID；
- 读流量切换：先在新API与新后台管理里只读UUID字段；
- 老字段降级为冗余字段或历史兼容；
- 日志、埋点、导出报表统一切到UUID视角；
- 数据回溯：导出自增ID与UUID映射，给外部系统一段过渡期。
最后给一份常见问题清单：
- “UUID太长，占空间”：用
BINARY(16)； - “索引慢”：别用UUID当默认排序，时间字段单独建索引；
- “碰撞担心”：在大多数业务体量下可以忽略，真正要规避可加唯一约束+重试；
- “日志不好查”：统一大小写与连字符格式，约定好日志字段名；
- “与第三方系统对接格式不一致”：网关或适配层做转换，不要污染核心域模型。
工程实践的终点永远是可维护性。UUID不是银弹，但它减少了太多“中心化分配ID”的复杂度，尤其在多数据中心、离线作业、跨语言栈的环境里，简单往往意味着更稳。需要快速生成或批量导出，直接使用站点里的“UUID生成器”，把重复劳动交给工具，把脑力留给业务。
相关在线工具：
- 立即使用 UUID 生成器