ENCRYPTBYPASSPHRASE 不该用于生产环境敏感字段，因其依赖明文密码、无密钥管理、不支持轮换、易泄露且不满足等保2.0/GDPR要求；仅适用于开发测试阶段临时脱敏。
ENCRYPTBYPASSPHRASE 不是安全的字段级加密方案，它只适合临时脱敏或低敏感场景，不能替代 Always Encrypted 或对称密钥加密。
为什么 ENCRYPTBYPASSPHRASE 不该用于生产环境的敏感字段
这个函数用纯文本密码（passphrase）直接加密数据，不依赖密钥管理、不支持密钥轮换、密码明文常驻 SQL 脚本或应用配置中——一旦被读取，所有加密字段立刻可批量解密。它没有密钥 GUID、不参与 SQL Server 加密层次结构，也不受证书或主密钥保护。
常见错误现象包括：
- DBA 或运维人员在查询计划、日志或监控工具中意外看到
ENCRYPTBYPASSPHRASE('MySecret123', @data)这类语句，导致密码泄露 - 应用升级或重构时，硬编码的
passphrase被提交到 Git，触发安全审计告警 - 无法满足等保 2.0 或 GDPR 对“密钥与数据分离”的基本要求
ENCRYPTBYPASSPHRASE 的实际可用场景和参数陷阱
它唯一合理用途是：开发测试阶段快速生成不可逆但可比对的伪加密值，比如填充测试表、绕过前端校验逻辑、或临时隐藏日志中的手机号片段。
使用时必须注意：
-
ENCRYPTBYPASSPHRASE返回varbinary(8000)，超出长度会截断且无警告；若原始数据超长，应先CONVERT(varbinary(max), @data) - 第二个参数（明文）为
nvarchar时，函数按 UTF-16 编码处理；传varchar会导致乱码解密，例如ENCRYPTBYPASSPHRASE('x', 'abc')和ENCRYPTBYPASSPHRASE('x', N'abc')结果不同 - 不支持空密码；传空字符串
''会返回NULL，不是加密失败而是函数定义行为 -
DECRYPTBYPASSPHRASE解密失败时静默返回NULL，不会报错，容易掩盖类型或编码不匹配问题
真正该用什么替代 ENCRYPTBYPASSPHRASE
如果你正在设计用户密码、身份证号、银行卡号等字段的存储方案，直接跳过 ENCRYPTBYPASSPHRASE，选以下任一方式：
- 高安全性首选：
Always Encrypted（配合 Azure Key Vault 或 Windows Certificate Store），密钥完全不出数据库服务器，客户端驱动自动加解密 - 可控性优先：
CREATE SYMMETRIC KEY+ENCRYPTBYKEY，密钥由数据库主密钥保护，支持密钥轮换和权限隔离 - 仅防静态泄露：
TDE（Transparent Data Encryption），加密整个数据库文件，但对字段级访问控制无效
注意：pwdencrypt() 和 pwdcompare() 已废弃多年，SQL Server 2022 中仍保留但行为不稳定，严禁新项目使用。
如果非得用 ENCRYPTBYPASSPHRASE，请至少做三件事
这是底线操作，不能省略：
- 把
passphrase存在外部配置（如 SSIS 包参数、应用连接字符串扩展属性），绝不在 T-SQL 脚本里写死 - 加密字段必须设为
varbinary(8000)或更大，且应用层严格校验解密后是否为预期类型（比如尝试CAST(... AS bigint)失败就丢弃） - 在 SQL Server Agent 作业或触发器中避免调用它——执行上下文可能暴露密码，且无法审计调用链
真正棘手的地方在于：你很难判断一个字段“够不够敏感”。一旦开始用 ENCRYPTBYPASSPHRASE，后续替换成本远高于初期选对方案。别让第一个 SELECT ENCRYPTBYPASSPHRASE(...) 成为技术债起点。
