UUID.randomUUID() 是最安全的随机 UUID 生成方式，基于 SecureRandom 实现、线程安全、无重复风险；但其无序性损害数据库写入性能，不宜直接用作主键，推荐 Snowflake 等有序方案替代。
UUID.randomUUID() 是最常用也最安全的生成方式
Java 的 UUID 类本身不负责“生成”逻辑，它只是对 128 位值的封装；真正生成随机 UUID 的是静态工厂方法 UUID.randomUUID()。它基于 java.security.SecureRandom 实现，线程安全，无需额外同步。
常见误区是以为 UUID 构造函数能“自定义生成”，但所有带参数的构造函数（如 UUID(long, long)）都只是把已有数据转为对象，不参与随机性构建。
- 每次调用
UUID.randomUUID()都产生一个新实例，值几乎不可能重复（理论碰撞概率约 2^(-122)） - 不依赖系统时间或 MAC 地址，规避了时钟回拨和硬件暴露风险
- 生成开销略高于纯数字 ID（约 2–5μs/次），但在绝大多数业务场景中可忽略
不要用 UUID.nameUUIDFromBytes() 做业务主键
UUID.nameUUIDFromBytes(byte[]) 是确定性哈希（MD5），输入相同字节数组永远输出相同 UUID。这在需要“可预测 ID”的场景（如缓存键、幂等 ID）有用，但极易引发冲突或泄露业务信息。
典型错误：用用户手机号或邮箱直接哈希生成 ID —— 一旦攻击者知道规则，就能反推原始数据或批量构造有效 ID。
立即学习“Java免费学习笔记（深入）”；
- 仅适用于内部标识映射，且输入源必须可控、长度固定、无敏感含义
- 若需确定性 ID，优先考虑加盐后哈希再截断，或使用专用库如
com.google.common.hash.Hashing - 数据库索引对 UUID 的写入性能影响比自增 ID 高约 30%～50%，尤其在 B+ 树页分裂频繁时
toString() 输出带连字符，入库前注意字段长度
UUID.toString() 返回形如 "f47ac10b-58cc-4372-a567-0e02b2c3d479" 的 36 字符字符串（32 字符 + 4 个短横）。若存入数据库，VARCHAR(36) 是安全选择；但若追求空间效率，可存为 16 字节二进制（BYTEA 或 BINARY(16)）。
- PostgreSQL 支持原生
UUID类型，自动校验格式且存储紧凑（16 字节） - MySQL 8.0+ 同样支持
UUID类型，但旧版本常用CHAR(36)或BINARY(16) - 用
uuid.getMostSignificantBits()和uuid.getLeastSignificantBits()可拆分为两个long，便于某些序列化或调试场景
分布式系统中 UUID 不等于“全局有序”
很多人误以为 UUID 天然适合分库分表场景，其实标准随机 UUID（version 4）完全无序，会导致 MySQL InnoDB 主键插入时频繁页分裂，写入吞吐下降明显。
如果需要兼顾唯一性与写入性能，应避免直接用 UUID.randomUUID() 作主键，而改用：
String id = String.format("%d%012d", System.currentTimeMillis(), ThreadLocalRandom.current().nextLong(1000000000000L)); 或更稳妥的 Snowflake 变种（如 Twitter 的 idworker 或 Apache ShardingSphere 的 SNOWFLAKE 算法）。
真正要用 UUID 时，至少确保数据库主键不是聚簇索引，或使用 UUID.toByteArray() 后按字节倒序存入（模拟时间前缀效果），但这已超出标准库能力范围。
