在PostgreSQL中保护敏感字段时，开发团队常面临一个选择：到底是把加密逻辑放在应用层，还是直接利用数据库内置能力。pgcrypto作为官方贡献的扩展，提供了从单向哈希到对称加密的一整套函数，让数据库管理员和后端开发者都能以SQL语句完成数据保护，而不必依赖外部库。它随PostgreSQL安装包一同发布，只需一条命令即可启用，是许多合规场景下的首选方案。
pgcrypto扩展的启用与基础函数分类
在使用任何加密函数之前，必须先在目标数据库中加载pgcrypto扩展。这一步只需要超级用户或具备CREATE权限的账号执行一条SQL命令：CREATE EXTENSION IF NOT EXISTS pgcrypto;。扩展安装后，相关的函数会注册到public模式下，后续普通用户就能直接调用。如果是在云数据库环境，部分托管服务已经在模板库里预装了该扩展，可以通过查询pg_extension系统表确认。
pgcrypto提供的函数大致分为三类。第一类是单向摘要函数，例如digest和md5，它们把任意长度输入转换为固定长度散列值，无法逆向还原，适合存密码或校验文件完整性。第二类是带盐值的密码哈希函数crypt与gen_salt，专门解决传统哈希容易被彩虹表攻击的问题。第三类是可逆的加解密函数，包括pgp_sym_encrypt、pgp_sym_decrypt以及对应的非对称版本，能够对字段做真正的加密存储，并在查询时解密使用。
理解这三类函数的边界非常关键。很多初学者误以为digest出来的字符串还能反解，于是把身份证号digest后存库，后续业务又要明文展示，结果只能重新采集用户数据。正确做法是用可逆的PGP函数加密，或者把明文留在应用层缓存、只把哈希值落库做比对。下面的代码展示了扩展启用与简单分类测试：
-- 启用扩展
CREATE EXTENSION IF NOT EXISTS pgcrypto;
-- 单向摘要，sha256
SELECT digest('hello', 'sha256');
-- 带盐密码哈希
SELECT crypt('mypassword', gen_salt('bf'));
-- 对称加密（密码短语方式）
SELECT pgp_sym_encrypt('13800138000', 'my-secret-pass');
digest与crypt在密码存储中的实战对比
digest函数支持md5、sha1、sha256、sha512等算法，调用形式为digest(data text, type text)。它的输出是bytea二进制，通常用encode转成十六进制方便查看。由于同一个输入永远得到同一个输出，如果没有加盐，攻击者拿到用户表后可以用预先算好的常见密码哈希库直接反查。因此在现代系统中，单纯使用digest存登录密码已经不被推荐。
crypt函数则专门应对上述缺陷。它配合gen_salt生成随机盐，并把盐和计算次数编码进结果字符串里。常用类型有bf（Blowfish，即bcrypt）和md5。每次调用crypt('pwd', gen_salt('bf'))都会得到不同前缀的字符，但验证时只需crypt(输入密码, 库中存储值)是否等于存储值即可，因为盐已经从存储值里解析出来。这样即使两个用户密码相同，库里痕迹也完全不同。
从性能角度看，bf类型可以通过调整代价因子拉长计算时间，从而抵抗暴力破解，但这也会稍微增加登录验证的CPU开销。相比之下digest速度极快，更适合做数据完整性标记而非密码保护。下面的例子演示了用户表如何设计以及登录校验SQL：
-- 建表
CREATE TABLE app_user (
id serial PRIMARY KEY,
username text UNIQUE,
pwd_hash text
);
-- 注册时插入
INSERT INTO app_user(username, pwd_hash)
VALUES ('alice', crypt('alice123', gen_salt('bf')));
-- 登录校验
SELECT id FROM app_user
WHERE username = 'alice'
AND pwd_hash = crypt('alice123', pwd_hash);
如果业务只需要判断某条记录未被篡改，比如日志摘要，用digest就足够且高效。但凡涉及身份验证凭证，都应优先采用crypt方案，避免自行拼接盐值带来的实现漏洞。
使用pgp_sym_encrypt实现字段级可逆加密
当敏感信息如手机号、银行卡号必须在库中加密且业务侧还要偶尔解密使用时，pgp_sym_encrypt和pgp_sym_decrypt提供了对称加密能力。它遵循OpenPGP标准，默认使用CAST5等算法，也可以指定cipher-algo为aes256。加密时需要一个密码短语，解密时也必须提供同样的短语，否则返回乱码或报错。
这种方式的优势在于即使数据库文件被拖库，没有密码短语就无法还原明文。但它也带来运维复杂度：密码短语不能写死在应用代码里明文分发，通常需要借助密钥管理服务（KMS）在连接时动态注入，或者由应用层在会话变量中临时设置。另外，加密后的字段是bytea类型，体积变大，无法直接Like查询，必须在解密后再过滤，这会影响索引使用。
一个常见的落地模式是把密码短语放在会话级变量中，通过安全通道下发，然后封装视图来简化开发。以下示例展示了加密写入与解密读取，以及如何通过函数隐藏短语细节：
-- 加密写入
INSERT INTO customer(id, phone_enc)
VALUES (1, pgp_sym_encrypt('13912345678', 'session-pass', 'cipher-algo=aes256'));
-- 解密读取
SELECT id, pgp_sym_decrypt(phone_enc, 'session-pass') AS phone
FROM customer;
-- 封装函数避免暴露短语
CREATE FUNCTION dec_phone(p bytea) RETURNS text AS $$
BEGIN
RETURN pgp_sym_decrypt(p, current_setting('app.sec_pass'));
END;
$$ LANGUAGE plpgsql;
需要提醒的是，pgcrypto的所有加解密操作都在数据库进程内完成，若数据库与应用的网络链路未加密，短语或明文仍有被嗅探的风险。因此配合SSL连接以及严格的角色权限控制，才能让pgcrypto真正发挥防护价值。
pgcryptoPostgreSQL加密数据脱敏修改时间：2026-08-14 23:27:36