UUID 生成与版本选择

UUID 是 128 位标识符，标准写法 550e8400-e29b-41d4-a716-446655440000。 真正需要关心的不是「怎么生成」，而是用哪个版本。

v4 vs v7

• v4：完全随机。最简单，但作为数据库主键时，插入位置随机 → B 树页分裂 → 写入变慢、索引膨胀。 百万行以上的表能明显感觉到。
• v7：前 48 位是毫秒时间戳，其余随机。既全局唯一，又大致单调递增，插入集中在索引尾部， 是 MySQL/PostgreSQL 主键场景目前最推荐的版本。

如果表不大（十万行以内）或者不做主键，v4 完全够，别过度设计。

方法 1：浏览器本地生成

UUID 生成器：v4，批量生成，大写/无横线可选，本地生成不联网。

生成 UUID →

方法 2：命令行

# Linux
uuidgen
cat /proc/sys/kernel/random/uuid

# Windows PowerShell
[guid]::NewGuid().ToString()
1..10 | ForEach-Object { [guid]::NewGuid().ToString() }   # 批量

# Python 3.12+
python -c "import uuid; print(uuid.uuid7())"
python -c "import uuid; print(uuid.uuid4())"

三个常见错误

• 用 UUID 做 URL 里的业务 id：36 个字符很长，而且在日志里难以阅读。业务 id 用短 id，UUID 只在内部用。
• 用时间戳拼随机数冒充 UUID：跨机器会撞。真的需要有序就用 v7，别自己发明。
• UUID 当密码/令牌用：v4 有 122 位随机，碰撞概率极低，但它不是加密安全的令牌生成方式； 令牌要用 secrets.token_urlsafe() 这类专门的接口。

存储建议

数据库里存 BINARY(16)（去掉横线再转成 16 字节）比存 36 字符的 VARCHAR 省一半以上空间， 索引也更快。如果一定要可读性，用 VARCHAR(36) 但把字符集固定成 ascii。