PostgreSQL遍历记录生成GUID及URL用GUID替代主键的安全咨询

这个方案完全可行，属于业界常用的标识符脱敏手段，核心目的就是避免暴露递增式主键带来的安全风险——比如攻击者可以通过/user/1、/user/2这种URL遍历所有用户记录，或者通过主键数值推断你的业务数据量（比如订单主键到了10000，就知道你有一万个订单）。

用GUID作为对外暴露的标识符，和主键做映射，既能保持内部数据库的主键效率（比如自增ID的索引性能更好），又能对外隐藏敏感的主键信息，是个平衡安全和性能的不错选择。

虽然这个方案能解决主键泄露的问题，但也有几个容易忽略的风险点：

• 权限校验不能缺位：GUID只是难猜测，但不是不可猜测（虽然v4的GUID碰撞概率极低），更重要的是，不能把“知道GUID”等同于“有权访问资源”。比如用户A的订单GUID被用户B拿到，你的系统依然要校验B是否有权查看这个订单，否则GUID的防护意义就大打折扣。
• 要使用真随机的GUID版本：别用基于时间戳和MAC地址的UUID v1，这种GUID会泄露生成时间甚至服务器的MAC地址，存在被逆向追踪的风险。一定要用UUID v4（随机生成），比如PostgreSQL里的uuid_generate_v4()。
• 日志泄露风险：如果你的系统日志里会记录请求URL，要注意别把GUID直接暴露在日志中（尤其是日志可能被第三方访问的情况下），否则攻击者拿到日志依然能遍历资源。
• 缓存与CDN的坑：如果用GUID作为URL参数，要确保缓存策略正确。比如静态资源如果绑定GUID，可能会因为GUID不同导致重复缓存浪费空间；反过来，如果是动态页面，要避免缓存所有GUID对应的页面，防止返回错误的内容。

首先得确保PostgreSQL的UUID扩展已经安装（默认没有这个扩展）：

-- 安装uuid-ossp扩展（仅需执行一次）
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

情况1：已经有GUID字段，需要批量填充 #

假设你的表叫orders，主键是id，已经有一个public_uuid字段用来存储对外的GUID：

-- 为所有现有记录生成唯一的随机GUID
UPDATE orders SET public_uuid = uuid_generate_v4();

-- 为了确保唯一性，添加唯一约束（可选但推荐）
ALTER TABLE orders ADD CONSTRAINT unique_public_uuid UNIQUE (public_uuid);

情况2：还没有GUID字段，先新增再填充 #

-- 新增UUID类型的字段，先允许为空（后续更新后再设为非空）
ALTER TABLE orders ADD COLUMN public_uuid UUID;

-- 批量生成GUID填充字段
UPDATE orders SET public_uuid = uuid_generate_v4();

-- （可选）将字段设为非空，确保后续新增记录必须有GUID
ALTER TABLE orders ALTER COLUMN public_uuid SET NOT NULL;

-- 添加唯一约束
ALTER TABLE orders ADD CONSTRAINT unique_public_uuid UNIQUE (public_uuid);

针对大表的优化建议 #

如果你的表有百万级以上的记录，直接执行UPDATE会锁表很久，影响业务，建议分批更新：

-- 每次处理1000条记录，重复执行直到没有空的public_uuid
WITH batch AS (
    SELECT id FROM orders WHERE public_uuid IS NULL LIMIT 1000
)
UPDATE orders o
SET public_uuid = uuid_generate_v4()
FROM batch b
WHERE o.id = b.id;

后续新增记录的自动生成 #

为了避免手动生成GUID，给字段设置默认值，新增记录时自动生成：

ALTER TABLE orders ALTER COLUMN public_uuid SET DEFAULT uuid_generate_v4();

内容的提问来源于stack exchange，提问作者Phil