你以为 UUID 够快了？同样 1 秒，它生成 2000 万个 ID 时，你的服务在等什么？

你以为 UUID 够快了？同样 1 秒，它生成 2000 万个 ID 时，你的服务在等什么？

摘要：比 UUID 快 15 倍：1 秒造 2000 万个 ID

先认清一个扎心事实：你的 ID 生成正在偷偷拖垮高并发

说实话，绝大多数后端同学用 UUID 的时候，眼睛都不眨一下。“全球唯一”、久经考验、一行代码的事，有什么好纠结的？

但有个事实很多人从没认真量过：在高并发服务里，生成 ID 从来不是"免费"的。以 UUID v4 为例，每生成一个 ID，底层都要向操作系统申请一次加密级随机数（syscall 进/dev/urandom或getrandom）。到了每秒上万请求的场景，光是"造 ID"这一项，每秒就是上万次系统调用——这还没算你真正的业务逻辑。

更扎心的是，这种开销是"静默"的。它不像慢 SQL 那样会打日志报警，而是像一笔你忘了还的贷款利息，悄悄堆在你的 p99 延迟上。等你在监控里看到尾延迟悄悄爬升时，第一反应往往是加机器、加缓存，很少有人会回头怀疑：“是不是我的 ID 生成太慢了？”

事实上，"UUID 够快了"是工程里最常被默认、却最少被验证的假设之一。

数据先行：Rust 版 SparkID 真能跑 2000 万/秒吗？

先把结论拍在桌面上：能，而且不是在一个语言里能，是 JS、Python、Rust 三个版本全部跑赢主流对手。

作者把 SparkID 和 UUID v4、UUID v7、ULID、n