UUID.randomUUID()是最稳妥的生成方式，底层用SecureRandom实现UUID v4，碰撞概率极低；禁用手动拼接、时间戳模拟或new UUID()构造；存储宜用BINARY(16)而非字符串；命名场景用nameUUIDFromBytes()；测试应避免污染全局随机状态。
UUID.randomUUID() 是最常用也最稳妥的生成方式
Java 的 UUID 类本身不负责“生成”逻辑，它只是对 128 位标识符的封装；真正生成随机 UUID 的是静态工厂方法 UUID.randomUUID()。这个方法底层调用 SecureRandom 生成伪随机数，符合 UUID version 4 规范，碰撞概率极低（约 2^122 分之一），适合绝大多数业务场景。
常见误用是试图手动拼接或基于时间戳构造——这既不标准，也不保证唯一性，还可能破坏跨系统兼容性。
- 不要用
new UUID(mostSigBits, leastSigBits)手动构造，除非你明确知道两个 long 的含义且有确定来源 - 避免用
System.currentTimeMillis()+ 线程ID 等方式“模拟”UUID，这类 ID 在高并发或分布式下极易重复 -
UUID.randomUUID().toString()返回带连字符的 36 字符字符串（如"f47ac10b-58cc-4372-a567-0e02b2c3d479"），若需无连字符格式，用uuid.toString().replace("-", "")
UUID.nameUUIDFromBytes() 适用于确定性命名场景
当你需要“相同输入总是得到相同 UUID”时，比如为用户名、资源路径等稳定标识生成可复现的 ID，就该用 nameUUIDFromBytes()。它基于 MD5 哈希（RFC 4122 定义），输入字节数组，输出 version 3 UUID。
注意：这不是加密用途，MD5 已不安全，但用于内部 ID 映射完全够用；别拿它做签名或权限校验。
立即学习“Java免费学习笔记（深入）”；
- 输入必须是明确、一致的字节序列，推荐用
name.getBytes(StandardCharsets.UTF_8)，避免平台默认编码差异 - 同一个字符串在不同 JVM 或版本下结果始终一致，适合做缓存键、数据库分区键等
- 不要传空数组或 null，会抛
NullPointerException
别把 UUID 当主键用在 MySQL InnoDB 上直接写入
UUID 字符串作为主键，在 InnoDB 中会导致严重的页分裂和插入性能下降——因为新 UUID 是随机值，无法顺序追加，频繁触发 B+ 树重排。实测写入吞吐可能比自增整型低 5–10 倍。
如果非用 UUID 不可，至少做两件事：
- 用
BINARY(16)存储（而非VARCHAR(36)），先调UUID.fromString(s).getMostSignificantBits()和getLeastSignificantBits()拆成两个 long，再合并为 16 字节数组 - 考虑使用
UUID.toByteBuffer()或 Guava 的LongEncoding.longToBytes()辅助转换 - 或者换用优化版 UUID：如 Twitter Snowflake、MongoDB ObjectId，或 Java 库如
com.fasterxml.uuid:java-uuid-generator提供的TimeBasedEpochGenerator
测试中生成固定 UUID 要小心线程安全与污染
单元测试里常需要“固定 UUID”来断言或 mock，但直接写死 UUID.fromString("...") 没问题；一旦用 Mockito.mock(UUID.class) 或反射修改静态行为，就容易污染其他测试用例。
更稳妥的做法是依赖注入或工厂抽象：
- 定义接口
IdGenerator，生产环境用UUID::randomUUID，测试用返回预设值的实现 - 避免在
@BeforeAll或静态块里重置SecureRandom，这会影响整个测试套件的随机性表现 - JUnit 5 的
@TempDir或WireMock等工具内部也可能依赖 UUID，随意 mock 可能导致不可预期失败
