SQL Server动态数据掩码（DDM）是列级静态定义、仅对无特权用户在SELECT结果中自动生效的机制，不能在存储过程中动态调用或绕过；EXECUTE AS会以高权限上下文执行导致掩码失效；真正动态脱敏需应用层或视图层实现。
存储过程里不能直接用 MASKED WITH 语法
动态数据掩码（DDM）是列级定义的，不是运行时行为。你在存储过程中写 SELECT 或 INSERT 都不会触发掩码逻辑——它只在查询结果返回给**无特权用户**时，由 SQL Server 引擎自动应用。所以别试图在存储过程里“调用”掩码函数或动态拼接 MASKED WITH；那语法根本不在运行时生效，建表或改列时就固定了。
EXECUTE AS 是绕过掩码的常见误操作点
如果你在存储过程中用 EXECUTE AS OWNER 或 EXECUTE AS 'dbo'，那么所有查询结果都会以高权限上下文执行，掩码直接失效——用户看到的是原始数据。这不是 bug，是设计使然：掩码只对“被限制的用户”起作用。
- 确认当前执行上下文：用
SELECT USER_NAME(), ORIGINAL_LOGIN()查看实际生效身份 - 若需保留掩码效果，存储过程必须以普通用户身份运行，且该用户**未被显式授予
UNMASK权限** - 不要在过程开头加
REVERT后再查掩码列——只要中间某步用了EXECUTE AS，后续语句仍继承该上下文
真正“数据驱动”的掩码只能靠条件逻辑 + 字符串处理
SQL Server 的 DDM 不支持按行、按参数、按角色动态切换掩码规则。所谓“数据驱动”，实际只能靠你在存储过程中手写逻辑模拟部分效果，比如：
- 用
CASE WHEN判断当前用户角色，再决定是否调用LEFT(email, 1) + 'xxx@xxx.com'这类硬编码脱敏 - 把掩码规则存进配置表（如
mask_rules表含column_name、mask_type、prefix_len等字段），然后用STRING_AGG+ 动态 SQL 拼出脱敏表达式——但注意：这不等于 DDM，只是应用层模拟，且无法防止用户绕过存储过程直查基表 - 对数值型字段，可用
RAND(CHECKSUM(NEWID())) * (high - low) + low模拟random(low, high)效果，但每次执行结果不同，不满足 DDM 的“一致性”要求
真正要实现权限感知的动态输出，得靠外部控制层
SQL Server 本身不提供运行时掩码开关。如果你的需求是“同一存储过程，对 A 用户返回全量手机号，对 B 用户只返回后四位”，那必须把权限判断和脱敏逻辑移到应用层或视图层：
- 用视图封装逻辑：
CREATE VIEW v_customer_masked AS SELECT ..., CASE WHEN IS_MEMBER('mask_reader') = 1 THEN partial_mask(phonenumber) ELSE phonenumber END - 让存储过程只返回原始数据，由调用方（如 .NET 应用）根据登录身份决定是否脱敏
- 结合行级安全（RLS）+ DDM 双重控制：RLS 控制“能不能查”，DDM 控制“查到什么样子”，但 RLS 规则也不能在存储过程中动态改
最易被忽略的一点：掩码只作用于 SELECT 结果集，对 INSERT、UPDATE、DELETE 或变量赋值完全无影响——你往 @phone 变量里塞的永远是明文，哪怕它来自一个被掩码的列。
