UUID核心用途是无中心生成极大概率不重复的128位唯一标识符；常用randomUUID()生成版本4随机UUID，适合分布式主键、traceId等；nameUUIDFromBytes()生成版本3确定性UUID，适用于URL等输入映射；不可对版本4调用timestamp()等方法。
Java 中的 UUID 类核心用途就一个：在无中心协调的前提下，生成**极大概率不重复的 128 位唯一标识符**。它不是“绝对唯一”，但重复概率低到可忽略（比如每纳秒生成 10 亿个，持续 100 年，碰撞概率仍小于十亿分之一），因此被广泛用于分布式系统主键、日志 traceId、临时资源命名等场景。
什么时候该用 UUID.randomUUID()？
这是最常用、最安全的默认选择，适用于绝大多数需要“本地快速生成唯一 ID”的情况。
- 适合场景：数据库分库分表主键、微服务间请求链路 ID（如
X-Request-ID）、上传文件临时名、缓存 key 前缀 - 本质是版本 4 UUID：基于加密安全随机数（
SecureRandom）生成，不依赖时间或硬件信息，抗时钟回拨、跨机器天然隔离 - 注意性能开销：每次调用会触发一次
SecureRandom.nextLong()，高并发下比纯递增 ID 稍慢，但对绝大多数业务无感 - 别误以为“有序”：它生成的字符串字典序完全随机，直接用作 MySQL 主键会导致频繁页分裂，索引性能下降 —— 若需顺序性，得换
UUIDv7或自定义时间前缀方案
UUID.nameUUIDFromBytes() 适合哪些确定性场景？
当你需要“相同输入永远生成相同 UUID”时才用它，典型如：将 URL、用户名、API 路径等业务名称映射为稳定 ID。
- 它是版本 3 UUID：底层用 MD5 哈希，输入字节数组 → 输出固定 UUID，可用于去重、幂等控制、缓存键一致性
- 示例：
UUID id = UUID.nameUUIDFromBytes("https://api.example.com/user/123".getBytes(StandardCharsets.UTF_8)); System.out.println(id); // 每次运行都一样，比如 9a3b4c5d-e6f7-3890-a1b2-c3d4e5f6a7b8 - ⚠️ 坑点：必须指定字符集（如
UTF_8），否则不同平台默认编码不同会导致结果不一致；不要传 null 或空数组，会抛NullPointerException - Java 不原生支持版本 5（SHA-1），如需更强抗碰撞性，得自己封装
MessageDigest
为什么不能直接调用 clockSequence() 或 timestamp()？
因为这些方法只对版本 1（基于时间+MAC 地址）UUID 有效，而 UUID.randomUUID() 生成的是版本 4 —— 调用会抛 UnsupportedOperationException。
立即学习“Java免费学习笔记（深入）”；
- 错误现象：
Exception in thread "main" java.lang.UnsupportedOperationException at java.base/java.util.UUID.clockSequence(UUID.java:352) - 验证方式：
uuid.version()返回4，说明是随机型；只有version() == 1时才能安全调用timestamp() - 真要获取时间戳？别依赖 UUID：直接用
System.currentTimeMillis()或Instant.now().toEpochMilli()更清晰可靠 - MAC 地址暴露风险：版本 1 UUID 含网卡物理地址，内网可用，公网暴露有隐私隐患，生产环境慎用
真正关键的不是“选哪个方法”，而是想清楚你要的是「确定性」还是「不可预测性」、「是否需要时间局部性」、「存储和索引成本能否接受」——UUID 只是工具，用错场景比写错代码更难排查。
