UUID.randomUUID()是最常用且稳妥的UUID生成方式，基于SecureRandom生成v4版本，碰撞概率极低，适用于订单号等场景，但不保证有序、不含时间戳，不宜直接用作MySQL主键。
UUID.randomUUID() 是最常用也最稳妥的生成方式
Java 内置的 UUID 类提供了开箱即用的全局唯一标识生成能力，无需引入第三方依赖。调用 UUID.randomUUID() 会基于随机数（伪随机，使用 SecureRandom）生成一个 version 4 的 UUID，碰撞概率极低（约 2^122 分之一），适合绝大多数业务场景——比如订单号、消息 ID、临时 token 等。
注意它不保证单调递增或时间有序，也不含时间戳信息，纯靠随机性保障唯一性。
UUID id = UUID.randomUUID(); String idStr = id.toString(); // 如 "f47ac10b-58cc-4372-a567-0e02b2c3d479"
-
toString()返回带连字符的标准格式（32 字符 + 4 个-），共 36 字符；如需无分隔符形式，可用id.toString().replace("-", "") - 不要用
UUID.nameUUIDFromBytes(byte[])除非你明确需要“相同输入必得相同输出”的确定性哈希行为，否则容易因字节序列构造不当导致重复 - 避免在高并发循环中频繁调用
randomUUID()——虽然线程安全，但底层SecureRandom在某些 JDK 版本（尤其旧版 Linux 系统）可能因熵池耗尽而阻塞
别直接用 UUID 作数据库主键（尤其 MySQL InnoDB）
UUID 字符串作为主键存在明显性能隐患：长度大（36 字符）、无序写入导致 B+ 树频繁分裂和页碎片，插入吞吐下降显著。MySQL 官方文档明确建议避免用 UUID 做聚簇索引键。
如果必须用 UUID，推荐两种折中方案：
立即学习“Java免费学习笔记（深入）”；
- 将
UUID存为BINARY(16)：先用UUID.getMostSignificantBits()和getLeastSignificantBits()拆成两个long，再组合为 16 字节数组，可节省空间并提升索引效率 - 用 UUID 做逻辑 ID，另设自增
BIGINT主键：业务层用 UUID 标识资源，数据库用整型主键维护关系和性能
PostgreSQL 对 UUID 支持更好（原生 UUID 类型 + 高效索引），但依然不建议直接用其做高频写入表的主键。
需要时间有序？考虑 Snowflake 或 ULID，而非 UUID
UUID v4 完全随机，无法反映生成时间或支持按 ID 排序查询。若你需要“新 ID 总是比旧 ID 大”“能从 ID 反推大致生成时间”或“兼容分布式且无中心节点”，UUID 不是合适选择。
Java 生态中有成熟替代：
-
Twitter Snowflake衍生实现（如twitter-snowflake或java-snowflake）：64 位整型，含时间戳、机器 ID、序列号 -
ULID（Universally Unique Lexicographic Identifier）：字符串格式，128 位，前 48 位为毫秒级时间戳，天然有序，Java 有ulid-creator库
例如用 ulid-creator：
import com.github.f4b6a3.ulid.Ulid; Ulid ulid = Ulid.random(); // 返回类似 "01ARZ3NDEKTSV4RRFFQZ8SBSNY" 的字符串 String idStr = ulid.toString();
它比 UUID 更短（26 字符）、可排序、含时间信息，且仍保持全局唯一性。
测试时慎用固定 UUID，避免污染断言逻辑
单元测试中常有人写 UUID.fromString("00000000-0000-0000-0000-000000000000") 作占位 ID，这看似方便，实则埋下隐患：
- 多个测试用同一固定值，可能导致缓存冲突、数据库唯一约束失败
- 一旦业务代码误将该“零值”当作特殊语义（如“未设置”），测试会掩盖真实逻辑缺陷
- 更安全的做法是每次测试生成新
UUID.randomUUID()，或用Mockito模拟UUID工厂返回可控实例
真正需要可重现 ID 的集成测试场景，建议封装一个测试专用的 TestUuidProvider，内部维护计数器生成确定性但非零的 UUID，而非硬编码字符串。
