SQL Server 2022 存储过程不支持动态脱敏输出，因其要求所有执行路径返回完全一致的列结构，且 CURRENT_USER() 在编译时静态解析；动态脱敏应使用行级安全（RLS）配合 SESSION_CONTEXT 实现。
SQL Server 2022 的存储过程**不适合做动态脱敏输出**——它无法根据调用者身份、会话上下文或环境变量返回不同结构或内容的结果集；所谓“按角色掩码手机号”的需求，必须交由行级安全（RLS）或查询重写策略实现，不是靠 CREATE PROCEDURE 封装 SELECT 就能解决的。
为什么不能在存储过程中用 CURRENT_USER() 做脱敏分支
你写不出这样的逻辑：
IF CURRENT_USER() = 'analyst'
SELECT id, name, phone FROM users
ELSE
SELECT id, name, CONCAT(LEFT(phone,3),'****',RIGHT(phone,4)) AS phone FROM users
这不是语法错误，而是语义冲突：SQL Server 要求同一存储过程所有执行路径返回**完全一致的列名、数量和数据类型**。两个 SELECT 的列数/类型不匹配，编译阶段就失败。
更关键的是：CURRENT_USER() 在存储过程体中是静态解析的（编译时值），不是运行时上下文变量，优化器不会把它当作可变谓词来生成多计划。强行绕开会触发不可预测的缓存污染或权限泄漏。
真正可用的脱敏场景：批量更新测试库敏感字段
只有当目标明确是「把测试环境表里的手机号全替换成固定掩码格式并写回原表」时，存储过程才合理且高效。此时它只是个带参数的封装壳，核心仍是单条 UPDATE。
- 必须加
WHERE phone LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'或正则等价写法（SQL Server 2017+ 支持WHERE phone NOT LIKE '%[^0-9]%' AND LEN(phone) = 11），否则空值、短字符串会导致LEFT(phone, 3)返回NULL，整列脱敏失效 - 别用
REPLACE(phone, SUBSTRING(phone,4,4), '****')—— 这种写法依赖内容匹配，若中间4位含重复数字（如13811111234），可能误替换多次 - 推荐写法：
UPDATE users SET phone = STUFF(phone, 4, 4, '****') WHERE ...，STUFF是 SQL Server 原生函数，语义清晰、性能稳定、兼容 2012+
想实现“查询时按角色脱敏”？用行级安全（RLS）+ 安全策略
这才是 SQL Server 2022 官方支持的动态脱敏路径。它在查询执行计划生成阶段注入过滤/掩码逻辑，应用层无感知，且权限隔离严格。
步骤很简单：
- 建一个标量函数，比如
f_mask_phone(@p VARCHAR(20))，内部用STUFF或CONCAT实现掩码 - 创建安全策略：
CREATE SECURITY POLICY dbo.PhoneMaskPolicy ADD FILTER PREDICATE dbo.f_mask_phone(phone) ON dbo.users（注意：实际需配合SCHEMABINDING和权限控制） - 关键点：函数里可通过
SESSION_CONTEXT(N'role')获取应用层传入的角色标识，再决定返回明文还是掩码值——这比存储过程里硬编码CURRENT_USER()可控得多
如果没启用 RLS，又想临时规避，唯一退路是视图 + CASE WHEN + 严格回收基表权限。但视图无法响应运行时角色，只能做到“静态分组脱敏”，比如按部门预设掩码规则。
容易被忽略的陷阱：加密 ≠ 脱敏，别混用
看到资料里提 HASHBYTES、ENCRYPTBYKEY 就以为能当脱敏用？错。加密是可逆的，脱敏是不可逆的；加密后字段类型变成 VARBINARY，前端展示要解密，违背了“只读脱敏”初衷；而且密钥管理、轮换、历史数据兼容全是额外负担。
真要上线脱敏，优先走 STUFF/CONCAT + 正则清洗 + RLS 策略这条线。存储过程只在需要定时批量清洗测试数据时才值得动——其他情况，它只是给问题套了一层不必要的壳。
