UUID.randomUUID()生成的是不可预测、不可排序的随机UUID（type 4），不包含时间或机器信息，不适合需时间序的场景；解析时须严格校验格式，数据库存储需按引擎特性优化。
UUID.randomUUID() 生成的是随机 UUID，不是时间戳或机器信息编码
Java 的 UUID.randomUUID() 默认用的是 type 4（随机数）算法，它不依赖系统时间、MAC 地址或进程 ID。这意味着每次调用都是独立采样，理论上碰撞概率极低（2^122 分之一），但**完全不可预测、不可排序、也不反映创建顺序**。
常见错误是误以为它像数据库自增 ID 或 Snowflake 那样带时间语义——结果在分页、范围查询或日志追踪时发现没法按生成时间排序。
- 如果需要时间可排序性，别用
UUID.randomUUID()，改用java.time.Instant.now().toEpochMilli()拼接节点 ID，或引入com.fasterxml.uuid:java-uuid-generator - type 4 UUID 的 128 位中，只有 122 位真正随机（6 位固定为 variant 和 version 标识），这点不影响使用，但影响你对熵值的判断
- 高并发下反复调用
UUID.randomUUID()不会锁全局，性能够用（JDK 7+ 用SecureRandom的非阻塞实现）
UUID.fromString() 解析失败的典型错误：格式多空格、大小写混用、缺连字符
UUID.fromString() 对输入极其严格：必须是 32 位十六进制字符 + 4 个连字符，共 36 字符，且连字符位置固定（8-4-4-4-12）。任何偏差都会抛 IllegalArgumentException。
常见错误现象：java.lang.IllegalArgumentException: Invalid UUID string: "abc123" 或 "aBc1-2345-6789-0123-456789012345"（大小写本身合法，但少连字符就挂）。
立即学习“Java免费学习笔记（深入）”；
- 入库前或 API 接收时，先用正则
^[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}$做预校验，比直接 try-catch 更早暴露问题 - 前端传来的 UUID 经常带首尾空格，务必先调用
trim()，否则fromString()直接炸 - PostgreSQL 的
UUID类型和 MySQL 的CHAR(36)存储都接受小写，但解析时大小写不敏感——这点不用额外处理
UUID 作为主键时，MySQL 和 PostgreSQL 的索引效率差异明显
UUID 用作主键，在 MySQL（InnoDB）里容易引发页分裂和插入变慢，因为新值不是单调递增；而 PostgreSQL 的 UUID 类型配合 B-tree 索引表现更稳，尤其开启 pg_uuidv7 扩展后能支持时间有序 UUID。
真实场景中，你可能看到 MySQL 插入吞吐从 5000 QPS 掉到 800 QPS，只因把 BIGINT 主键换成 UUID，且没做任何优化。
- MySQL 下若坚持用 UUID，至少用
UUID_TO_BIN(uuid, true)存为BINARY(16)，避免字符串比较开销，再加ORDER BY时用BIN_TO_UUID()转回可读格式 - PostgreSQL 不必转二进制，默认
UUID类型已优化存储和比较，但注意：原生不支持 v7，得靠扩展或应用层生成 - 无论哪种数据库，都别在 UUID 上建前缀索引（如
INDEX(uuid(8))），前 8 位几乎不携带区分度，等于白建
不要用 UUID.nameUUIDFromBytes() 做“确定性 ID”而不控制字节源
UUID.nameUUIDFromBytes() 是基于 MD5 的 type 3 UUID，输入相同字节数组必然输出相同 UUID。但它**不校验输入内容是否合理**——比如传一个空字符串、JSON 字段名、甚至用户昵称，都可能生成看似“稳定”实则语义混乱的 ID。
典型踩坑：用 nameUUIDFromBytes("user_id_".getBytes()) 生成固定 ID，结果所有用户都共享同一个 UUID，因为没拼上实际 user_id 值。
- 必须确保输入字节数组包含足够区分度的信息，例如
nameUUIDFromBytes(("User:" + userId).getBytes(StandardCharsets.UTF_8)) - MD5 已不推荐用于安全场景，但仅作 ID 生成无风险；不过要注意：Java 的
nameUUIDFromBytes()固定用 UTF-8 编码，别用String.getBytes()无参重载（依赖平台默认编码） - 如果需要加密安全的确定性 ID，改用
UUID.randomUUID()配合外部哈希（如 SHA-256）再截取，或者直接用MessageDigest
UUID 看似简单，但一旦混用类型、忽略存储层特性或盲目信任“唯一性”，问题往往在压测或数据迁移时才爆发——尤其是跨服务、跨数据库拼接 ID 的场景，字节序、编码、连字符、大小写，任何一个环节松动，后面就是查数对不上。
