PostgreSQL的md5()函数只接受text类型输入，因其底层封装强制要求文本格式，传入integer、bytea等会报错；需用::text显式转换，并用COALESCE处理NULL以确保结果稳定。
PostgreSQL 的 md5() 函数能直接生成 32 字符十六进制字符串，但要注意它只接受 text 类型输入，且对 NULL 返回 NULL —— 别直接套用在 bytea 或数字字段上，否则报错或结果意外。
为什么 md5() 输入必须是 text？
PostgreSQL 的 md5() 是纯文本哈希函数，底层调用的是 OpenSSL 的 MD5 实现，但 PostgreSQL 封装时强制要求输入为 text。传入 integer、bytea 或 jsonb 会触发类型不匹配错误，例如：
ERROR: function md5(integer) does not exist
常见误操作包括：md5(id)（id 是 int）、md5(password_hash)（password_hash 是 bytea）。解决方式统一转成 text：
- 数字字段：用
md5(id::text) - 二进制字段：先用
encode(bytea_col, 'escape')或convert_to(bytea_col, 'UTF8')::text，再哈希 - NULL 安全：加
COALESCE(col, '')避免整个表达式返回 NULL
散列敏感字段时的典型写法与陷阱
以用户邮箱脱敏为例，目标是生成不可逆、定长（32 字符）、便于索引的摘要：
SELECT email, md5(COALESCE(email, '')) AS email_md5 FROM users;
这里容易踩的坑有：
- 没处理 NULL：一旦
email为 NULL，md5(NULL)返回 NULL，导致后续去重或关联失败 - 忽略大小写：邮箱
Alice@Example.COM和alice@example.com哈希结果不同，若业务视其等价，应先LOWER() - 没加盐：仅用
md5(email)易受彩虹表攻击，生产环境建议拼接固定 salt，如md5('my-salt-' || COALESCE(email, '')) - 字符编码影响：若字段含非 UTF8 字节（如 legacy Latin1 数据），
::text强制转换可能出错，需先convert_from(bytea_col, 'LATIN1')
md5() 输出长度固定，但别当唯一键用
md5() 总是返回 32 字符的十六进制字符串（如 5f4dcc3b5aa765d61d8327deb882cf99），长度稳定，适合存入 CHAR(32) 或 TEXT。但它不是加密函数，碰撞概率虽低但存在，且无密钥机制。实际使用中：
- 可用于快速去重或匿名化展示，比如日志中隐藏手机号：
md5('138****1234') - 不适合替代
pgcrypto的gen_salt()+crypt()做密码存储 - 如果需要更高强度，改用
digest()（需pgcrypto扩展）支持 SHA-256：encode(digest('hello', 'sha256'), 'hex') - 索引效率：对
md5(col)建函数索引可行，但要注意表达式必须和查询中完全一致，否则索引不生效
MD5 本身已不推荐用于安全敏感场景，但作为轻量级字段摘要工具依然有效；真正关键的是输入预处理是否严谨——尤其是 NULL、编码、大小写和 salt 的组合，往往比选什么哈希算法更影响结果可靠性。
