必须用 UUID.nameUUIDFromBytes() 生成确定性 UUID，它基于 SHA-1 哈希，输入相同字节数组（需显式指定 UTF-8 编码）输出恒定，且线程安全；禁用 randomUUID()、无参 getBytes() 和 fromString() 模拟。
用 UUID.nameUUIDFromBytes() 生成确定性 UUID
从字节数组生成固定、可复现的 UUID，必须用 nameUUIDFromBytes()，不是 randomUUID()，也不是手动拼 UUID.fromString()。它基于 SHA-1 哈希，输入相同字节数组，输出永远一致。
-
nameUUIDFromBytes()接收byte[]，输出UUID；传null会直接抛NullPointerException - 别误用
UUID.randomUUID()—— 它是真随机，每次调都不同，和“固定算法 ID”完全相反 - SHA-1 输出 20 字节，
nameUUIDFromBytes()只取前 16 字节并按 UUID 格式重排（把第 6–7、8–9 字节位置挪成 version 和 variant 位），所以哪怕你传 100 字节，结果也只依赖前 20 字节哈希 - 示例：
UUID.nameUUIDFromBytes("user:123".getBytes(StandardCharsets.UTF_8))每次运行都返回同一个 UUID
字节数组编码必须统一，否则跨环境不一致
同一字符串在不同编码下字节不同，nameUUIDFromBytes() 对字节敏感，UTF-8 和 GBK 下 "张三" 的字节数组完全不同，生成的 UUID 也就不同。
- 务必显式指定字符集，禁用无参
String.getBytes()—— 它依赖平台默认编码，Linux/Windows/macOS 可能各不相同 - 推荐固定用
StandardCharsets.UTF_8，这是互联网事实标准 - 如果输入本来就是二进制数据（比如加密后的密钥、哈希值），跳过字符串编码，直接传原始
byte[] - 错误示范：
UUID.nameUUIDFromBytes("abc".getBytes())→ 在 Windows 上可能是 GBK 编码，结果不可移植
别拿 UUID.fromString() 反向构造“固定 ID”
有人想“先算好一个 UUID 字符串，再用 fromString() 加载”，这看似绕开哈希，实则失去一致性保障：字符串本身若含大小写、带或不带花括号、空格等，fromString() 虽能解析，但无法保证源头字符串生成逻辑稳定。
-
fromString()是解析器，不是生成器；它不关心来源，只校验格式 - 如果你硬编码一个 UUID 字符串（如
"550e8400-e29b-41d4-a716-446655440000"），那它确实固定，但和“从字节数组生成”毫无关系，也不满足“算法 ID”需求 - 真正需要算法派生时，必须走
nameUUIDFromBytes()，不能靠字符串约定
性能与线程安全：无锁、无状态，放心用
nameUUIDFromBytes() 内部只做 SHA-1 计算 + 位操作，没有 IO、不读配置、不依赖外部状态，天生线程安全，且单次调用耗时稳定（微秒级）。
立即学习“Java免费学习笔记（深入）”；
- 无需缓存结果 —— 计算快，重复调用开销极小；但若高频调用同一字节数组（如固定用户 ID），缓存
UUID实例仍比反复计算略优 - 注意：SHA-1 虽被密码学界认为不够强，但用于 UUID 生成（非签名/认证场景）完全够用；Java 官方没标记它为 deprecated
- 别自己重实现 SHA-1 + UUID 组装 —— 容易错位（比如没置 version=5 或 variant=2），导致生成的 UUID 不被其他系统识别为合法 name-based UUID
