uuid.randomuuid()基于securerandom生成密码学安全的随机uuid，概率极低重复（2^(-122)），适用于主键等场景；命名uuid用nameuuidfrombytes()确保确定性；解析需严格校验格式并指定utf-8编码。
UUID.randomUUID() 是最常用也最安全的生成方式
Java 的 UUID 类本身不负责“生成”逻辑，它只是对 128 位值的封装；真正生成随机 UUID 的是 UUID.randomUUID() 这个静态工厂方法。它基于 SecureRandom 实现，满足密码学安全强度，适用于绝大多数需要唯一性的场景（如数据库主键、分布式事务 ID、临时 token）。
常见误区是以为调用一次就能“永久唯一”，其实它只保证**概率意义上极难重复**（理论碰撞概率约 2^(-122)），不是绝对数学唯一。但只要不是每秒生成数万亿个，实际可视为稳定可靠。
- 不要自己拼接时间戳 + 随机数来模拟 UUID——容易出错且破坏标准格式
- 避免在高并发循环中反复调用
UUID.randomUUID()而不做缓存——SecureRandom初始化有一定开销，但后续调用很快，一般无需优化 - 生成结果是
UUID对象，若需字符串形式，显式调用.toString()；它默认带连字符（如"f47ac10b-58cc-4372-a567-0e02b2c3d479"），去掉连字符需自行 replace 或用uuid.toString().replace("-", "")
UUID.nameUUIDFromBytes() 适合确定性命名场景
当你需要“相同输入总是产生相同 UUID”时，用 UUID.nameUUIDFromBytes()。它基于 MD5 哈希，把任意字节数组映射为固定 UUID，常用于将用户名、URL、资源路径等转换为稳定 ID。
注意：输入必须是 byte[]，中文字符串要先指定编码（推荐 UTF-8），否则跨环境结果不一致：
立即学习“Java免费学习笔记（深入）”；
String input = "user@example.com"; UUID id = UUID.nameUUIDFromBytes(input.getBytes(StandardCharsets.UTF_8));
- 别直接传
string.getBytes()——平台默认编码不可控 - MD5 不再推荐用于密码或签名，但用于命名 UUID 是标准做法，无安全风险
- 输出 UUID 版本是 3；如果想用 SHA-1（版本 5），Java 标准库不提供，需借助
MessageDigest自行实现
UUID.fromString() 解析字符串时格式错误会抛异常
从数据库或网络读取 UUID 字符串后，用 UUID.fromString() 转回对象。它对格式极其严格：必须是 32 位十六进制字符 + 4 个连字符，共 36 个字符，且连字符位置固定（8-4-4-4-12）。
典型错误包括：
- 字符串含空格或换行：
" f47ac10b-58cc-4372-a567-0e02b2c3d479 "→ 抛IllegalArgumentException - 缺少连字符：
"f47ac10b58cc4372a5670e02b2c3d479"→ 同样失败 - 长度不对或含非法字符（如
'g'）→ 直接崩溃
稳妥做法是先 trim 再校验正则：^[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}$，匹配后再解析。
性能和序列化要注意 byte[] 和字符串的开销差异
UUID 对象内部用两个 long 存高位/低位，内存仅 16 字节；但 .toString() 生成的是 36 字符的 String，占约 72 字节（UTF-16），序列化到 JSON 或存入日志时明显膨胀。
- 高频日志场景，考虑只记录部分字段（如后 8 位）或改用
ByteBuffer.putLong(uuid.getMostSignificantBits()).putLong(uuid.getLeastSignificantBits())二进制写入 - Jackson 默认序列化为字符串，如需紧凑格式，可用自定义
Serializer输出为 base64 或 16 进制字节数组 - 数据库存储：PostgreSQL 有原生
UUID类型，MySQL 推荐用BINARY(16)存 raw bytes（比VARCHAR(36)更快更省空间）
getBytes() 没指定 charset，都可能让命名 UUID 在不同机器上产出不同结果。 
