UUID 生成器

v4 用随机数填充; 碰撞概率极低; 无需中央协调即可生成。

PostgreSQL/MySQL 主键、分布式日志 requestId、前端临时 key。

在开发API服务时，我们常需要为每个请求生成唯一标识。打开UUID生成器，选择无连字符格式，批量生成20个ID。将这些ID预存入Redis队列，当新请求到达时直接弹出使用，比实时生成效率更高。

处理用户上传文件时，用UUID替代原始文件名更安全。选择URN格式生成ID，如urn:uuid:xxx，将其作为S3存储路径。这种结构化命名既避免冲突，又方便后期通过统一资源标识符定位文件。

UUID v4 纯随机，分布均匀但 B-tree 索引插入随机。v7 含时间戳前缀，按时间大致有序，适合日志与事件 ID。数据库主键选型需权衡索引碎片与可排序性。

RFC 4122 要求 variant 与 version 位正确；无效 UUID 会导致 ORM 或 API 400。生成后用 regex-tester 验证格式，ulid-generator 提供另一种时间排序 ID。

v4 碰撞概率极低（122 位随机），但非零。金融或合规场景若要求全局唯一审计，需中心化发号或 ULID/雪花。本工具适合测试 fixture，非生产发号服务。

批量生成时复制到 spreadsheet 前确认无重复（本工具随机源为 crypto.getRandomValues）。勿将 UUID 当作安全 token——可预测性取决于版本与 entropy。

JWT 的 jti 声明可承载 UUID 实现单 token 吊销。jwt-generator 签发时填入 jti，jwt-decoder 解码核对。

API 路径参数中的 UUID 可用 url-parser 确认未被截断；semver 与 UUID 无关但常在同一代码库共存。

联调支付或下单接口时，用本工具为 Idempotency-Key 或 X-Request-Id 生成新 UUID，每次重试换新键，避免把生产幂等键写进脚本。记录键与响应到事故文档，再用 json-diff 对比「应相同」的两次响应。

批量生成 fixture 时一次复制一列到表格，抽样用 regex-tester 校验版本位。需要时间排序且更短时，评估 ulid-generator 而非强行截断 UUID。

把 UUID 当作请求关联 ID 很方便，但若 UUID 中嵌入可推测的业务含义（旧方案用用户手机号派生）会泄露隐私。坚持随机 v4/v7 或真正的内部映射表。日志外发前仍跑 pii-scanner。

JWT 的 jti 可存放 UUID；签发用 jwt-generator，检查用 jwt-decoder。切勿把 UUID 打印在可公开缓存的 URL 中若它映射到敏感资源且无鉴权。

随机 UUID v4 作主键会打散 B-Tree 插入顺序，高写入表可能放大页分裂。可选：用雪花/序列作聚簇键，UUID 作业务对外 ID；或评估有序 UUID v7。本工具帮你快速生成样本对比存储体积与可读性，不代替容量规划。

迁移前在预发用真实基数压测：插入吞吐、索引体积、JOIN 成本。日志与追踪 ID 可继续用 UUID，即使主键不是 UUID。

一次生成数百个 fixture 时，粘贴到表格后用去重公式或脚本确认无重复。理论碰撞概率极低，但「复制同一单元格一百次」是人为碰撞主因。需要可排序短 ID 时转向 ulid-generator，而不是手截 UUID。

把生成参数（版本、数量、用途）写进 README，避免同事用在线不明来源生成器混入不可复现的样本。

用 UUID 作主键可避免中心发号，但 B-Tree 随机写入可能导致页分裂。若存储引擎对顺序敏感，评估 UUID v7 或 ULID（时间有序）与业务可读短码的分工：对外暴露短码、内部关联 UUID。批量插入前先在 staging 压测索引膨胀。

迁移旧自增 ID 时，用映射表而不是「哈希手机号当 UUID」。生成样例后用 regex-tester 校验格式，再用本工具批量补齐测试库。

v4 碰撞在正常规模下可忽略；真正常见的是「人为复制同一 UUID」或「测试 fixture 写死 ID 打进生产」。为每个环境使用不同命名空间或前缀标签（日志字段），而不是截断 UUID。发现重复时先查导入脚本与种子数据。

把「禁止提交生产 UUID 到公共仓库」写进 CODEOWNERS 检查清单；示例改用明显假值（如 00000000-…-0001）。