不能直接靠触发器实现安全、可靠的敏感数据加密保存——它最多只能当个脆弱的兜底层，真要落地得靠应用层主导；触发器仅适合简单固定密钥场景下的校验与拦截，而密钥管理、租户隔离、KMS集成等核心安全能力必须由应用层统一实现。
不能直接靠触发器实现安全、可靠的敏感数据加密保存——它最多只能当个脆弱的兜底层，真要落地得靠应用层主导。
MySQL BEFORE INSERT 触发器调用 AES_ENCRYPT() 的硬限制
能跑通，但必须同时满足：表引擎是 InnoDB、MySQL ≥ 5.7（推荐 8.0+）、目标字段类型为 VARBINARY 或足够长的 VARCHAR（如 VARCHAR(512)）。最常出错的是：
-
AES_ENCRYPT()返回VARBINARY，却把结果往VARCHAR(64)里插——直接截断，解密失败 - 密钥写成字符串
'mykey'，没用UNHEX('6D796B6579')转二进制，导致加密结果不稳定甚至NULL - 字段允许
NULL，但触发器里没写IF NEW.phone IS NOT NULL THEN ... END IF;，AES_ENCRYPT(NULL, key)返回NULL，掩盖逻辑问题
PostgreSQL 触发器 + pgcrypto 的权限与类型陷阱
不是装了扩展就能用。必须先由管理员执行：CREATE EXTENSION IF NOT EXISTS pgcrypto;，否则建触发器时直接报错 function encrypt does not exist。而且：
- 普通用户连不上
encrypt()函数——pgcrypto默认只对superuser开放，需显式授权：GRANT EXECUTE ON FUNCTION encrypt(bytea, text, text) TO your_app_user; - 加密结果必须存进
BYTEA字段，别用TEXT存 base64 编码结果，否则体积膨胀、读取解析易错 - 用
gen_salt('bf')生成 salt 后，解密时必须传相同 salt；若 salt 是动态生成的，就得额外存一列，否则根本没法解
SQL Server 存储过程里 ENCRYPTBYKEY() 为什么总返回 NULL
不是函数坏了，是密钥根本没打开。SQL Server 不会自动加载对称密钥，每次调用前都得手动 OPEN SYMMETRIC KEY。典型翻车点：
- 存储过程里漏掉
OPEN SYMMETRIC KEY your_key DECRYPTION BY CERTIFICATE your_cert，或者证书名/密钥名拼错 - 密钥用密码保护，但没在
OPEN语句里加WITH PASSWORD = 'xxx'，或密码写错 - 目标字段类型是
NVARCHAR，把ENCRYPTBYKEY()返回的VARBINARY直接插进去——SQL Server 静默转码，解密时字节错乱
真正该做的：触发器只做校验，加密交给应用层
触发器天生不适合处理密钥派生、KMS 调用、租户隔离这些事。它没法感知当前请求来自哪个用户、哪个租户，也没法安全地拿密钥。所以：
- 应用层统一处理
NULL和空字符串，加密前转成空字节b''，而不是留NULL - 密钥从 KMS（如 AWS KMS、Vault）运行时获取，绝不硬编码，更不塞进 SQL 文本里
- 数据库字段类型固定用
VARBINARY（MySQL）、BYTEA（PostgreSQL）、VARBINARY(8000)（SQL Server） - 触发器只干两件事：检查字段是否已加密（比如长度是否符合预期）、拦截明文直写（
IF NEW.ssn NOT LIKE '0x%' THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Plain text not allowed';）
密钥怎么来、谁有权解、密文查不了怎么办——这些问题全在 SQL 执行范围之外。触发器连密钥的影子都摸不到，硬塞进去只会让系统更难审计、更难轮换、更难排查。
