在构建现代应用程序，特别是分布式系统或微服务架构时，我们经常面临一个棘手的挑战：如何生成既安全又全局唯一的标识符？传统的自增 ID（SERIAL）在单机数据库中表现出色，但在多数据库合并或分布式环境下，它们往往力不从心。为了解决这个问题，PostgreSQL 为我们提供了强大的 UUID 数据类型 支持。
在这篇文章中，我们将深入探讨 PostgreSQL 中 UUID 的方方面面。我们不仅会解释它比自增 ID 更适合特定场景的原因，还会结合 2026 年的最新技术趋势，探讨如何在 AI 辅助开发、云原生架构以及高并发环境下高效地使用它。无论你是刚接触 PostgreSQL 的新手，还是希望优化数据库架构的资深开发者，这篇文章都将为你提供实用的指导和最佳实践。
目录
为什么在 2026 年我们依然选择 UUID？
在我们深入代码之前，先来看看为什么 UUID 在当今的技术栈中依然占据核心地位。过去，我们可能为了几个字节的存储空间而犹豫不决，但在 2026 年，存储成本已不再是瓶颈，而开发效率和系统安全性成为了首要考量。
- 全局唯一性与分布式架构：随着云原生和微服务的普及，数据不再局限于单一数据库。UUID（通用唯一标识符）设计之初就是为了确保在任何时间、任何地点生成的 ID 都不会重复，这天然契合了我们的分布式需求。
- 安全性与不可预测性：在网络安全威胁日益复杂的今天，防止枚举攻击至关重要。自增 ID 是连续的，恶意用户可以通过观察 URL 中的 ID（例如
/api/users/1001）轻易推断出系统的用户总量或遍历数据。UUID 是随机且不连续的，这使得这种攻击变得几乎不可能。
- AI 辅助开发的友好性：在我们最近的项目中，我们发现使用 UUID 可以大大减少 AI 编程工具（如 GitHub Copilot 或 Cursor）在生成数据迁移脚本或 API 关联代码时的上下文理解成本。AI 不需要去推断外键关系的自增步长，UUID 的“无状态”特性让 AI 生成的代码更加健壮。
当然，UUID 也有其缺点，主要是索引性能问题。但随着硬件性能的提升和数据库算法的优化，只要我们掌握正确的使用姿势，这些性能开销在现代应用中几乎可以忽略不计。
第一步：现代化环境中的扩展启用
在 PostgreSQL 中，虽然我们可以存储 UUID 类型的数据，但核心数据库默认并没有包含“生成” UUID 的函数。这是为了保持核心引擎的轻量化。为了生成 UUID，我们需要加载一个扩展模块。
最常用的扩展是 uuid-ossp。安装它非常简单，只需运行以下 SQL 命令：
-- 启用 uuid-ossp 扩展，以便使用生成 UUID 的函数
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
2026 开发者提示：从 PostgreSQL 13 开始，如果你想使用最常用的随机 UUID（版本 4），其实还有一个轻量级的替代方案。我们可以使用内置的 gen_random_uuid() 函数，无需安装任何扩展即可获得更好的性能。但在现代 DevOps 实践中，为了脚本的可移植性和对旧版本的支持，显式地创建扩展依然是很多团队的首选。
进阶探索：UUID 的版本之争与性能调优
这不仅仅是一个关于“如何生成 ID”的问题，更是关于系统架构的决策。让我们深入对比不同的生成策略。
1. UUID 版本 4（完全随机）- Web 应用的首选
这是目前开发中最常用的方式。INLINECODE1ed73e68 或 INLINECODEff1b107f 完全依赖随机数生成器。
特点：
- 安全性：不包含任何机器或时间信息，最适合作为公开的 ID。
- 适用性：绝大多数互联网应用。
SQL 示例：
-- 使用 PG13+ 内置函数生成随机 UUID (推荐)
SELECT gen_random_uuid() as random_uuid;
2. UUID 版本 7（时间有序）- 高并发写入的救星
如果我们把目光投向 2026 年的前沿领域，UUID v7 正在成为新宠。传统的 v4 UUID 是完全随机的，这会导致 B-Tree 索引频繁发生页分裂，因为在插入新数据时，新值可能会落在索引的任何位置，导致磁盘随机 I/O。
而 UUID v7 将时间戳编码进了 UUID，保证了它是大致按时间排序的。这意味着它既有 UUID 的全局唯一性，又有自增 ID 的索引友好性。
如何在 PG 中实现 v7：
虽然 PostgreSQL 核心尚未直接内置 v7 生成函数（截至主流版本），但我们可以通过扩展或逻辑模拟来实现。以下是一个生产级别的实现思路，利用 uuid-ossp 和时间戳函数模拟有序 UUID：
-- 模拟生成一个时间有序的 ID (实际生产建议使用 uuidv7 扩展)
-- 这里我们演示如何利用 v1 的特性来达到类似效果
-- v1 基于时间和 MAC 地址，因此天然是排序的
SELECT uuid_generate_v1() as v1_uuid;
注：在严肃的生产环境中，我们强烈建议安装专门的 INLINECODE682926f0 扩展或 INLINECODE082d29c7 扩展来原生支持 v7 标准。
实战演练：在企业级表中应用 UUID
理论讲完了，让我们通过实际的代码示例来看看如何在数据库设计和日常操作中应用 UUID。
场景一：创建带有 UUID 主键的表
假设我们正在为一个多租户 SaaS 平台设计“用户”表。我们希望每个用户都有一个全局唯一的 ID，并且希望数据库能自动处理它，以简化我们的应用层代码。
-- 创建示例表：users
-- contact_id 被设为 UUID 类型，默认值使用 v4 算法自动生成
CREATE TABLE users (
-- 设置主键为 UUID 类型，并使用 DEFAULT 关键字自动填充
-- 使用 gen_random_uuid() 比 uuid_generate_v4() 稍快且无需扩展
user_id UUID DEFAULT gen_random_uuid(),
username VARCHAR(50) NOT NULL,
email VARCHAR(100) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
-- 将 user_id 设为主键
PRIMARY KEY (user_id)
);
-- 插入数据：注意我们不需要提供 user_id，数据库会自动处理
INSERT INTO users (username, email) VALUES
(‘alice_chen‘, ‘[email protected]‘),
(‘bob_zhang‘, ‘[email protected]‘);
-- 查询结果
SELECT * FROM users;
AI 辅助编程视角：当你使用 Cursor 或 Copilot 编写 Insert 语句时，如果数据库 Schema 定义了 DEFAULT，AI 会自动识别并在生成的代码中忽略该字段，从而避免了常见的“字段缺失”错误。
场景二：处理外键关联与数据完整性
在为子表创建外键时，确保引用的类型也是 UUID。这在微服务架构中尤为重要，因为服务间传递的 ID 通常已经是 UUID 格式。
-- 订单表引用用户表
CREATE TABLE orders (
order_id UUID DEFAULT gen_random_uuid(),
user_id UUID NOT NULL, -- 类型与 users.user_id 保持一致
amount NUMERIC(10, 2),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(user_id)
);
2026 开发者的陷阱指南：性能与存储
作为经验丰富的开发者，我们需要了解它的底层机制，以避免潜在的坑。我们见过很多项目因为忽视这些细节而导致生产环境故障。
1. 永远不要使用 VARCHAR 存储 UUID
我们经常能看到有些开发者为了图省事，把 UUID 定义为 INLINECODE4a9b35f1 或 INLINECODE55ceaa73。这是极其错误的做法。
- 性能损耗：UUID 原生类型仅占用 16 字节，而 VARCHAR 不仅占用更多空间（取决于编码），还会因为字符集校对规则导致索引查询变慢。
- 索引膨胀：PostgreSQL 的 B-Tree 索引对 UUID 类型有专门的优化。
错误做法：
id VARCHAR(36)
正确做法：
id UUID
2. 警惕“随机 I/O”带来的写入瓶颈
正如我们之前提到的，UUID v4 是随机的。如果你的系统每秒需要写入数万条数据，随机 UUID 会导致硬盘磁头频繁跳跃（即使是 SSD，也有写入放大的问题）。
解决方案：
- 使用 UUID v7 或 v1：让 ID 带有时间顺序。
- 分表策略：在应用层通过 Sharding-JDBC 或类似工具，按时间维度将数据分散到不同的物理表中，降低单表索引压力。
迁移策略：从自增 ID 平滑过渡
你可能已经拥有了一个成熟的系统，使用的是 BIGSERIAL。如何在不停止服务的情况下迁移到 UUID？
最佳实践路径：
-- 1. 添加一个新的 UUID 列（ nullable 初始阶段）
ALTER TABLE users ADD COLUMN user_id_uuid UUID;
-- 2. 为现有数据生成 UUID，并创建唯一索引
-- 这一步可能需要较长时间，建议在低峰期执行
UPDATE users SET user_id_uuid = gen_random_uuid() WHERE user_id_uuid IS NULL;
CREATE UNIQUE INDEX idx_users_uuid ON users(user_id_uuid);
-- 3. 应用层双写模式
-- 修改代码，在插入时同时写入旧 ID 和新 UUID，查询优先使用 UUID
-- 4. 逐步切换外键引用
-- 这是一个漫长的过程，需要逐步解除旧外键，建立新外键
-- 5. 收尾：将 UUID 列设为 NOT NULL 并设为主键
ALTER TABLE users ALTER COLUMN user_id_uuid SET NOT NULL;
ALTER TABLE users DROP CONSTRAINT users_pkey; -- 删除旧主键
ALTER TABLE users ADD PRIMARY KEY (user_id_uuid);
这种“双写双读”的灰度发布策略，能确保我们在迁移过程中即使出现问题，也能瞬间回滚。
结语：构建面向未来的数据架构
让我们回顾一下。在 PostgreSQL 中实施 UUID 数据类型，为我们在分布式系统设计、安全性和解耦方面提供了极大的灵活性。虽然它比传统的整数 ID 占用更多的空间，但在现代硬件条件下，这种权衡通常是值得的。
关键要点：
- 推荐
UUID v4用于一般用途，但在高频写入场景请考虑 UUID v7。 - 始终使用原生的 INLINECODE117da4d3 数据类型，拒绝 INLINECODE336f55a4。
- 利用
DEFAULT gen_random_uuid()简化应用程序逻辑。 - 在 AI 辅助开发时代，规范的 Schema 定义能让 AI 更好地理解你的意图。
现在，让我们在下一个项目中尝试应用这些策略。通过合理地应用这些技术，我们能够构建出更加健壮、安全且易于扩展的数据库架构，从容应对 2026 年的技术挑战。祝你的编码之旅顺利！