UUID类用于生成128位全局唯一标识符，适用于分布式系统；最常用UUID.randomUUID()生成v4版本，基于122位强随机数，理论碰撞概率约1/2¹²²；但存在无序性、存储开销大、不可读等限制。
Java里的UUID类主要用于生成全局唯一的128位标识符，无需中心协调，天然适配分布式系统。它不依赖数据库自增、不需网络通信，靠算法和熵值保障极低的重复概率（理论碰撞概率约1/2¹²²），实际可视为“几乎不会重复”。
UUID的核心用途
它解决的是“谁来保证ID不重”的问题，典型场景包括：
- 数据库主键（尤其分库分表或跨服务写入时）
- 用户会话ID（如
sessionId）、临时令牌、API请求追踪ID（traceId） - 离线生成的订单号、文件名、消息唯一ID
- 微服务间数据合并、日志关联、事件溯源中的实体标识
Java中怎么生成UUID
最常用的是UUID.randomUUID()，生成的是版本4（v4）UUID——完全基于加密安全的随机数：
UUID uuid = UUID.randomUUID(); String id = uuid.toString(); // 如 "f47ac10b-58cc-4372-a567-0e02b2c3d479"
这个字符串固定36字符（32个十六进制字符 + 4个连字符），内部由两个long值（高位+低位）构成，可通过getMostSignificantBits()等方法访问原始位数据。
立即学习“Java免费学习笔记（深入）”；
UUID为什么能保证唯一性
不是靠“绝对不重”，而是靠“空间足够大 + 随机足够强”：
- v4使用122位真正随机比特（其余6位用于标识版本和变体），可能组合数达2¹²² ≈ 5.3×10³⁶种
- 即使每纳秒生成10亿个UUID，持续100年，冲突概率仍远低于10⁻¹⁵
- Java实现基于
SecureRandom，满足密码学强度，避免伪随机缺陷
需要注意的实际限制
UUID强大但不万能，用前得看清这些点：
- 无序性：v4是纯随机的，插入数据库会导致B+树频繁分裂，影响写性能（尤其MySQL聚簇索引）
-
存储开销：36字符比
BIGINT（8字节）大得多，索引体积膨胀明显；可考虑存为二进制（16字节）或去掉连字符（32字符） - 不可读不可推断：无法从中看出时间、来源或顺序，调试友好性差
- 不适用于需要排序或分页优化的场景：此时可考虑UUID v7（含时间戳）或Snowflake等有序ID方案
