UUID.randomUUID() 是最常用也最容易出错的起点
Java 里生成唯一 ID，UUID.randomUUID() 是第一反应，但它生成的是 128 位随机 UUID（version 4），不是递增、不带时间信息、字符串长度固定 36 字符（含 4 个短横线）。很多人直接用它当数据库主键，结果发现索引性能差、存储冗余、排查日志时还得手动去掉短横线。
- 别在高频插入场景（比如订单流水表）直接用
UUID.randomUUID().toString()作主键——B+ 树索引会因随机写导致页分裂严重 - 如果需要“可读性稍好一点”，可以用
UUID.randomUUID().toString().replace("-", "")去掉分隔符，变成 32 位十六进制字符串，但仍是完全随机的 - 注意
UUID是线程安全的，但频繁调用仍有一定对象创建开销；高并发下不如预生成一批缓存再取
想带时间戳又保持唯一？用 Snowflake 或自研时间+随机组合
UUID 本身不提供时间顺序能力。如果你需要“大致按时间排序”“能从 ID 反推生成时间”或“避免数据库索引碎片”，就得换思路。Java 生态里没有内置 Snowflake 实现，得靠第三方库或自己写轻量版。
- 推荐用
TwitterSnowflake的 Java 移植版（如twitter-snowflake或mybatis-plus内置的IdWorker），它生成 long 类型 ID，高位是时间戳（毫秒级）、中位是机器 ID、低位是序列号 - 自己拼接时间戳 + 随机数也能凑合：比如
System.currentTimeMillis() + "-" + ThreadLocalRandom.current().nextInt(1000, 9999)，但要注意并发下时间戳重复风险，必须加锁或用AtomicLong做序列保底 - 别用
new Date().getTime()直接当 ID——毫秒级精度在单机高并发下极易重复，且无法区分来源节点
数据库字段类型不匹配会导致隐式转换和查询变慢
生成 ID 后往数据库写，类型选错会让原本的唯一性优势打折扣。MySQL 和 PostgreSQL 对 UUID 的支持差异明显，尤其在索引效率上。
- MySQL 中，用
CHAR(36)存标准 UUID 字符串，但更优解是BINARY(16)——先用UUID.fromString(s).getMostSignificantBits()等方法转成两个 long，再存为字节数组，索引大小直接减半 - PostgreSQL 有原生
UUID类型，支持高效比较和索引，但 JDBC 驱动默认把ResultSet.getObject("id")返回为String，需显式调用getUUID()才能拿到java.util.UUID对象 - 千万别把 UUID 字符串存进
INT或BIGINT字段——会截断或报错Data truncation: Out of range value for column 'id'
测试环境用固定 UUID 会掩盖分布式唯一性问题
单元测试里为了可重现，常写死 UUID.fromString("123e4567-e89b-12d3-a456-426614174000")，这没问题；但集成测试或本地联调时，如果所有服务都用相同“伪随机种子”生成 UUID，就测不出真实冲突场景。
立即学习“Java免费学习笔记（深入）”；
- Spring Boot 测试中，可通过配置类禁用默认
SecureRandom，改用new Random(123)控制随机性，但仅限单 JVM 场景 - 微服务间通过消息传递 ID 时，要确认上游是否真用了
randomUUID()，还是误用了静态 UUID 单例——后者在多实例部署下必然重复 - 线上查重逻辑不能只依赖数据库唯一索引报错，得在业务层加
SELECT COUNT(*) FROM table WHERE id = ?预检，否则异常堆栈里全是SQLIntegrityConstraintViolationException，定位成本高
UUID 的“唯一”是概率意义上的，不是绝对保证。真正麻烦的从来不是生成那一刻，而是 ID 落库、跨系统传输、日志关联、归档检索这一整条链路上，每个环节对格式、长度、排序性、可读性的隐含假设。漏掉任意一环，都可能让“唯一 ID”变成“重复事故源头”。
