工具指南20-在线UUID生成器

GeraldChen
2 阅读8分钟

开发中经常需要生成唯一标识符。数据库主键、分布式系统节点ID、前端临时Key、API幂等性Token......这些场景都离不开UUID。很多人对UUID的了解停留在"一串随机字符",但它其实有多个版本,不同版本的生成逻辑和适用场景完全不同。

本文会先讲清楚UUID的核心知识,再介绍一个实用的在线UUID生成器。

UUID是什么

UUID(Universally Unique Identifier)是一个128位的标识符,通常表示为32个十六进制字符,用连字符分成5段:

550e8400-e29b-41d4-a716-446655440000

格式是 8-4-4-4-12,其中第三段的首位标识版本号。比如上面这个UUID,第三段以 4 开头,说明它是v4版本。

UUID的设计目标是:在不需要中心化协调的情况下,任意节点都能独立生成不重复的标识。这一点对分布式系统尤其重要——你不需要一个"发号器"来分配ID,每个节点自己生成就行。

UUID版本对比

UUID目前有8个版本(v1到v8),日常开发中常用的是v1、v4和v7。其他版本要么应用场景有限,要么已被新版本替代。

v1: 基于时间戳 + MAC地址

v1用当前时间戳和机器的MAC地址来生成UUID。优点是天然有序(时间递增),可以从UUID中反推生成时间。缺点也明显:MAC地址会暴露机器信息,存在隐私风险。

v1 示例: 6fa459ea-ee8a-11e3-a10e-0800200c9a66
         ^^^^^^^^          ^^^^
         时间戳低位          MAC地址片段

适用场景:需要按时间排序,且不关心隐私泄露的内部系统。

v4: 纯随机

v4是目前使用最广泛的版本。除了固定的版本号和变体标识位,其余122位全部随机生成。没有时间信息,没有机器信息,完全靠随机数的统计特性保证唯一性。

// Node.js 内置支持(v14.17+)
import { randomUUID } from "crypto";  // ESM
// const { randomUUID } = require("crypto");  // CJS
console.log(randomUUID());
// 输出: 1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed

// 浏览器原生API
crypto.randomUUID();
// 输出: 3f5e9a2c-7b1d-4f8e-a6c3-2d4e5f6a7b8c

碰撞概率有多低? 生成 2^61 (约 2.3 * 10^18)个v4 UUID后,碰撞概率才达到50%。按每秒生成10亿个的速度,需要连续跑约73年才可能遇到一次碰撞(数据来源: RFC 9562)。实际项目中可以认为不会碰撞。

适用场景:绝大多数业务场景的默认选择。

v7: 基于时间戳 + 随机(新标准)

v7是2024年正式发布的RFC 9562中新增的版本。它在前48位放Unix毫秒时间戳,后面跟随机数。兼具v1的时间有序性和v4的隐私安全性。

v7 结构:
|-- 48bit 毫秒时间戳 --|-- 4bit版本 --|-- 12bit随机 --|-- 2bit变体 --|-- 62bit随机 --|

v7的核心优势是数据库友好。作为B+树索引的主键时,时间有序的UUID能保证新数据总是追加到索引末尾,避免频繁的页分裂,写入性能比v4好很多。

需要注意的是,主流数据库目前还没有内置v7生成函数。PostgreSQL的 gen_random_uuid() 生成的是v4,MySQL的 UUID() 生成的是v1。如果需要在数据库层面生成v7,PostgreSQL可以使用 pg_uuidv7 扩展,或者在应用层生成后写入。

适用场景:数据库主键、需要按生成顺序排列的场景。

三者对比

特性v1v4v7
时间有序是否是
隐私安全差(含MAC)好好
数据库索引性能好差好
浏览器/JS原生支持否是(crypto.randomUUID())否(需第三方库)
推荐程度遗留系统通用默认新项目首选

如果你正在启动新项目,优先考虑v7。不过v7目前在JavaScript中没有原生API,需要使用 uuid 或 uuidv7 等npm包。如果是已有系统或简单场景,v4足够用——浏览器和Node.js都内置支持。

在线UUID生成器

AnyFreeTools的UUID生成器支持批量生成UUID v4。打开页面,设置需要的数量,点击生成即可。所有计算在浏览器本地完成,不会发送到服务器。

工具特点:

  • 批量生成: 一次可以生成多个UUID,省去反复操作的麻烦
  • 一键复制: 生成结果支持一键复制到剪贴板
  • 纯前端计算: 基于浏览器的 crypto.randomUUID() API,数据不经过网络传输
  • 免费无限制: 不需要注册,没有使用次数限制

典型使用场景

场景1: 数据库测试数据

写单元测试或准备mock数据时,经常需要一批UUID作为主键:

INSERT INTO users (id, name, email) VALUES
  ('550e8400-e29b-41d4-a716-446655440000', '测试用户1', 'test1@example.com'),
  ('f47ac10b-58cc-4372-a567-0e02b2c3d479', '测试用户2', 'test2@example.com'),
  ('7c9e6679-7425-40de-944b-e07fc1f90ae7', '测试用户3', 'test3@example.com');

直接用在线工具批量生成,复制粘贴进SQL,比手动编造快得多。

场景2: 分布式系统消息ID

微服务间通信时,每条消息需要全局唯一ID做链路追踪:

const message = {
  messageId: crypto.randomUUID(),
  source: "order-service",
  target: "payment-service",
  payload: { orderId: "ORD-2026001", amount: 99.9 },
  timestamp: Date.now()
};

场景3: 前端临时标识

React/Vue中渲染动态列表时,需要稳定的key:

import { useState } from "react";

const [items, setItems] = useState([]);

const addItem = () => {
  setItems(prev => [...prev, {
    id: crypto.randomUUID(),
    content: "",
    createdAt: new Date()
  }]);
};

return items.map(item => (
  <ListItem key={item.id} data={item} />
));

用UUID而不是数组索引作为key,能避免列表增删时的渲染错乱问题。

各语言的UUID生成方式

不同语言和平台生成UUID的方式略有差异,整理如下供参考:

// JavaScript (浏览器 / Node.js 14.17+)
crypto.randomUUID()

# Python 3
import uuid
str(uuid.uuid4())

// Go (使用 google/uuid 包)
import "github.com/google/uuid"
id := uuid.New().String()

// Java
import java.util.UUID;
UUID.randomUUID().toString();

# Linux 命令行
uuidgen
# 或者
cat /proc/sys/kernel/random/uuid

-- PostgreSQL (生成v4)
SELECT gen_random_uuid();

-- MySQL (生成v1)
SELECT UUID();

如果只是临时需要几个UUID,不想写代码,直接打开在线生成器更方便。

UUID vs 其他ID方案

UUID不是唯一的ID生成方案。选择之前值得了解几个替代方案:

自增ID: 最简单,但依赖数据库,分布式环境下需要额外协调。适合单体应用。

Snowflake: Twitter开源的64位ID方案,由时间戳+机器ID+序列号组成。长度比UUID短(64位 vs 128位),但需要预先分配机器ID。适合高吞吐的分布式系统。

NanoID: 更短的随机ID(默认21个字符),URL安全。适合前端场景,比如短链接、CSS class名。

ULID: 类似UUID v7的思路,26个字符,时间有序+随机。Crockford Base32编码,比UUID更紧凑。

选择建议:

  • 不确定用什么 → UUID v4(最通用)
  • 数据库主键 → UUID v7 或 Snowflake
  • 前端短ID → NanoID
  • 需要时间排序且不想用UUID → ULID

安全注意事项

UUID v4虽然是随机的,但它不是加密安全token。不要把UUID当作密码、API密钥或会话令牌使用。原因有两个:

  1. UUID的格式是公开的(固定位置有版本号和变体位),实际随机位只有122位
  2. UUID通常以明文传输,不具备防篡改能力

需要安全token时,应该用专门的加密随机函数:

// 生成32字节的安全随机token
const token = crypto.randomBytes(32).toString("hex");
// 输出: a3f2b8c9d1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9

UUID适合做标识符,不适合做密钥。用对工具,才能保证安全。

相关阅读:

本系列其他文章:

原文链接：chenguangliang.com/posts/blog1…

avatar
文章
阅读
粉丝