UUID.randomUUID() 是最常用但非最优的UUID生成方式，底层用SecureRandom生成version 4随机UUID，高并发下有锁竞争、存储开销大、不可排序；适合低频单机场景，数据库主键应存为byte[16]；需确定性ID时用nameUUIDFromBytes()；解析字符串须校验格式；UUID不等同于Snowflake类分布式ID。
UUID.randomUUID() 是最常用但不总是最优的选择
Java 的 UUID 类本身不生成 ID，它只是对 128 位值的封装和解析工具；真正生成随机 UUID 的是静态方法 UUID.randomUUID()。这个方法底层调用 SecureRandom（非伪随机），每次调用都产生一个 version 4（随机生成）的 UUID，形如 "f47ac10b-58cc-4372-a567-0e02b2c3d479"。
但它不是“唯一 ID 生成器”的万能解：高并发下频繁调用 UUID.randomUUID() 可能因 SecureRandom 内部锁竞争导致延迟抖动；生成的字符串长度固定 36 字符（含连字符），存储和索引成本高于 16 字节二进制或紧凑编码；且无时间序、不可排序，不利于数据库分页或范围查询。
- 若只需单机、低频、不关心排序的唯一标识（如消息追踪 ID、临时 token），
UUID.randomUUID()足够直接 - 若用于数据库主键，尤其 MySQL InnoDB 表，建议转为
byte[16]存储（去掉连字符后 hex 解码），避免字符串索引膨胀 - 不要在循环内反复调用它生成大量 ID——可考虑复用
SecureRandom实例并手动构造 version 4 UUID，减少锁开销
UUID.nameUUIDFromBytes() 适合基于业务数据确定性生成
当你需要“相同输入永远得到相同 UUID”，比如把用户邮箱映射为稳定 ID，或为 API 路径生成缓存 key，应使用 UUID.nameUUIDFromBytes(byte[])。它基于 MD5 哈希（RFC 4122 定义），生成的是 version 3 UUID，结果完全确定、可重现。
注意：输入字节数组不能为 null，且推荐先 UTF-8 编码再传入，否则中文等字符会出错：
String input = "user@example.com"; UUIDuuid = UUID.nameUUIDFromBytes(input.getBytes(StandardCharsets.UTF_8));
- 不适用于需要“不可预测性”的场景（如密码盐、临时凭证），因为哈希可被逆向枚举
- MD5 虽不安全，但此处仅作 determinism 用途，不影响唯一性保障
- 与
randomUUID()不同，它不依赖系统熵源，无性能瓶颈
从字符串解析 UUID 时必须校验格式，否则抛 IllegalArgumentException
调用 UUID.fromString(String) 解析外部传入的 UUID 字符串（如 HTTP Header、JSON 字段）前，务必确认格式合法。非法输入如缺少连字符、含非十六进制字符、长度不对，都会直接触发 IllegalArgumentException，而非返回 null。
- 常见错误输入：
"abc123"、"f47ac10b-58cc-4372-a567-0e02b2c3d47"（少一位）、"f47ac10b-58cc-4372-a567-0e02b2c3d47g"（含 g） - 生产环境建议加 try-catch 或预校验正则：
^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$ - 不要用
UUID.fromString()解析自定义短 ID（如 Snowflake 字符串），它只认标准 UUID 格式
UUID 不等于分布式唯一 ID，别把它当 Snowflake 用
UUID 是全局唯一标识符（Globally Unique Identifier），强调“冲突概率极低”，但不保证严格单调、不保证时间局部性、不提供序列号语义。而像 Twitter Snowflake、百度 UidGenerator、美团 Leaf 这类方案，核心目标是：毫秒级时间戳 + 机器 ID + 序列号，生成 64 位 long 型递增 ID，便于数据库索引、分库分表路由、监控追踪。
- 如果你的系统有分库分表、需要 ID 支持范围查询、要求写入性能极致，UUID（尤其是 string 形式）会成为瓶颈
- UUID 无法反推生成时间（version 1 可以，但 Java
UUID类不支持生成 version 1） - 跨语言系统中，UUID 标准兼容性好；Snowflake 需统一时钟和机器 ID 分配策略，落地更重
真正容易被忽略的是：很多人把 UUID.randomUUID().toString() 当成“分布式唯一 ID”直接塞进订单表主键，却没意识到它让 MySQL 的聚簇索引彻底失效——随机字符串导致大量页分裂和磁盘随机写，压测时 QPS 断崖下跌。
