UUIDv7 三大卖点全翻车
推荐指数 54.0 NO. 014 · 2026.10.24
发布2026/10/23Score80Comments68
简介
RFC 合规的 UUIDv7 实现中，单调递增、时间戳可读、不可猜测这三个被广泛宣传的特性能被严重破坏，唯一严格保证的只有唯一性。如果你在依赖这些特性做数据库排序或安全设计，需要重新评估。
编辑判断
很多团队选 UUIDv7 是为了替代 Snowflake 或自研发号器，图的是"自带时间序+不用运维"，但这篇文章暴露了一个致命盲区：RFC 9562 只规定了位布局，对时钟回拨、亚毫秒精度、随机位质量等关键行为完全放任。这意味着你换了个 UUIDv7 库，行为可能天差地别。
如果你用 UUIDv7 做数据库主键并依赖局部有序来减少页分裂，务必确认实现是否保证 monotonicity（如 Java 的 uuid7 库有 strict 模式，而某些 JS 实现没有）；如果你用时间戳做业务排序或调试，要知道同一毫秒内生成的 ID 时间位完全相同，顺序全靠随机位。
最务实的做法是：需要严格时间序用 ULID 或自研发号器，需要纯唯一性用 UUIDv4，UUIDv7 的甜蜜区其实很窄。
社区反馈
意见分歧 57 条评论
核心争论：UUIDv7 是否被过度宣传，数据库主键该用 UUID 还是自增整数
> My mental model for UUIDv7 is that it’s a mash-up of a bunch of different ideas which implementations are free to choose as they see fit. There’s a wide variance of properties that UUIDv7 implementations can provide, with varying degrees of certainty they can successfully provide those properties.
You probably don't need a UUID: https://ssg.dev/you-probably-dont-need-a-uuid/
I support this. I wrote a Sqlite plugin for KSUIDs, but at the end I never used them, since all I do can be handled by integer primary keys, which sqlite maps to the rowid automatically. Autoincrement is only required, if you want to prevent the reuse of ids in deleted rows.