Java中UUID.randomUUID()默认生成线程安全的v4版本UUID，基于SecureRandom伪随机数，无需外部依赖，适用于分布式环境；不支持v1/v3/v5需自行实现或借助工具库。
Java中借助UUID生成全局唯一标识，核心是使用java.util.UUID类提供的静态方法，无需外部依赖，线程安全，且默认生成的是基于随机数（伪随机）的版本4 UUID，具备极高的唯一性保障。
UUID的基本类型与Java默认行为
UUID共有5个版本（Version 1–5），Java的UUID.randomUUID()默认生成的是Version 4——完全基于加密安全的随机数（底层调用SecureRandom）。它不依赖时间、MAC地址或命名空间，因此在分布式、容器化、多JVM环境中天然适合生成无中心协调的唯一ID。
注意：Java标准库不直接支持Version 1（时间戳+MAC）或Version 3/5（哈希命名空间），如需这些类型，需自行实现或借助Apache Commons Codec等工具库。
最常用方式：randomUUID() + 基础校验
生成简单、高效、可靠：
立即学习“Java免费学习笔记（深入）”；
-
生成：
UUID id = UUID.randomUUID(); -
转字符串：
id.toString()→ 格式如"f47ac10b-58cc-4372-a567-0e02b2c3d479"（32位十六进制+4个短横线） -
转字节数组：
id.toString().getBytes(StandardCharsets.UTF_8)或更高效地用ByteBuffer提取高低64位 -
校验合法性（非必须但建议）：可用正则
"^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$"粗略判断是否为合规的v4格式
进阶控制：避免重复场景下的注意事项
虽然碰撞概率理论值极低（约2^122分之一），但在高吞吐批量生成（如每秒百万级）或测试环境反复创建JVM时，仍需留意：
-
不要复用同一个SecureRandom实例做大量UUID生成——
randomUUID()内部已优化，每次调用都获取独立随机源，无需手动管理 -
避免在单元测试中“固定”UUID用于断言——应改用
UUID.fromString("...")构造已知值，而非mock随机行为 -
存储建议：数据库中优先用
CHAR(36)或BINARY(16)（压缩存储，需自行转换高低位）；MySQL 8.0+支持UUID_TO_BIN()提升索引效率
轻量替代方案：Snowflake变体（非UUID但常被对比）
若需要有序性、时间可读性或更小存储体积，UUID不是唯一选择。可考虑：
- 自研64位Snowflake ID（含时间戳+机器ID+序列号）
- 使用Twitter的
twitter-snowflake或Alibaba的leaf等成熟方案 - 注意：这类ID不具备UUID的“无上下文唯一性”，需部署协调服务或预分配worker ID
基本上就这些。UUID在Java里开箱即用，逻辑清晰，重点是理解它“靠强随机性换唯一性”的设计本质，而不是把它当成黑盒调用。
