UUID 解决了分布式环境下生成唯一标识的难题，但它也带来了一系列容易被忽视的代价。在数据库和接口设计里，不当地使用 UUID 会悄悄拖慢查询、撑大存储、影响索引，甚至无意中泄露信息。这些问题往往在数据量小时毫无征兆，等到规模上来才集中爆发。了解这些常见误用，能帮你在享受 UUID 好处的同时，避开它的陷阱。
用随机 UUID 做高频写入主键
一个典型误用，是在写入频繁的表上用纯随机 UUID 做主键。随机值毫无顺序，新插入的记录会落到索引的各个位置，导致索引频繁分裂、缓存命中率下降，在大数据量下显著拖慢写入。这与自增主键"总在末尾追加"的高效形成鲜明对比。
如果确实需要 UUID 又在意写入性能，更稳妥的做法是选用可排序的、把时间编在前面的版本，让插入重新变得大致连续。把随机 UUID 当主键的代价，往往要到规模上来才痛感强烈。
以低效方式存储 UUID
UUID 本质上是 128 位的二进制值，但很多系统把它当作长长的文本字符串来存。文本形式占用的空间远大于二进制形式，索引也更大、比较更慢。在数据量庞大的表里，这种浪费会累积成可观的存储和性能开销。
更高效的做法，是用数据库提供的原生二进制类型来存储 UUID，只在需要展示时才转成文本。把"存储形式"和"展示形式"分开，能在不牺牲可读性的前提下省下大量空间和开销。
把 UUID 当成机密
有人因为 UUID 又长又随机，就把它当作不可猜测的秘密，用它来代替真正的访问控制——比如"只要知道这个 UUID 就能访问资源"。但 UUID 的设计目标是唯一，而不是保密。它可能出现在日志、链接、引用里，一旦泄露，所谓的保护就荡然无存。
正确的做法是把 UUID 当作标识符，而把访问控制交给专门的权限机制。哪怕 UUID 难以猜测，也不该用它来替代真正的鉴权。唯一性不等于安全性。
无意中泄露信息
某些版本的 UUID 会把时间戳或机器相关信息编码进去。如果你把这类 UUID 暴露给外部用户，对方就可能从中推断出记录的创建时间，甚至生成它的环境细节。在对隐私敏感的场景里，这可能是不希望发生的泄露。
设计对外接口时，要清楚你用的 UUID 版本会暴露什么。如果不希望泄露时间或环境信息，就选择不携带这些信息的版本。别让一个看似随机的标识符，悄悄透露了你不想公开的细节。
接口里的格式不一致
UUID 有标准的文本格式，但实践中常出现各种变体：带不带连字符、大写还是小写、是否加额外的修饰。如果接口在生成、存储、比较时对格式不统一，就会出现"看起来相同却不相等"的诡异 bug，或是查不到本应存在的记录。
稳妥的做法是在系统边界处对 UUID 做规范化，统一成一种约定的格式再存储和比较。把格式约定写进文档，并在输入时严格校验，能避免这类因表示不一致而引发的隐蔽问题。
把 UUID 暴露在不该出现的地方
有时内部使用的 UUID 会不经意地出现在面向用户的 URL、错误信息或日志里。这不仅可能泄露前面提到的信息，也可能把内部标识符的结构暴露给外界，给探测和滥用留下线索。内部标识和对外标识，最好有清晰的边界。
考虑为对外暴露的资源使用单独的、不泄露内部细节的标识，而把内部 UUID 留在系统内部。这种分离既保护了信息，也让内外两套体系可以各自独立演进。
把代价想清楚再用
这些误用有一个共同点：它们都源于只看到 UUID 的好处，却忽视了它的代价。它更大、通常无序、可能泄露信息、还容易被误当成机密。每一项都需要在设计时被正视，而不是等出了问题再补救。
用好 UUID 的关键，是有意识地权衡：选对版本、用高效方式存储、不拿它当鉴权、统一格式、谨慎对外暴露。把这些做到位，UUID 就能在为你提供分布式唯一性的同时，不在数据库和接口里留下隐患。