视图本身不脱敏，真正有效的是“显式字段处理+权限隔离”组合；必须手动编写覆盖NULL、空值及长度异常的CASE WHEN脱敏表达式，并严格回收基表SELECT权限、仅授予视图权限，否则用户可绕过视图直接查出明文。
视图本身不脱敏，只封装查询逻辑；真正起作用的是“显式字段处理 + 权限隔离”组合。单独建视图但不收基表权限，等于没做任何脱敏。
视图里必须手动写脱敏表达式，不能靠别名或注释
很多人以为把 phone 改名叫 phone_masked 就算脱敏了，其实只是换了个名字，值还是明文。MySQL、PostgreSQL 都没有 MASKED WITH 这种语法，SQL Server 的该语法也仅限于 CREATE TABLE 或 ALTER TABLE，根本不能用在视图里。
-
CASE WHEN phone IS NOT NULL THEN CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) ELSE '***' END AS phone_masked是可行写法，但必须覆盖NULL、空字符串、长度异常三种情况 - 别用
CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))直接写——phone为NULL时整个结果是NULL，前端容易崩 - PostgreSQL 要注意
''和NULL区分，得分开判：WHEN phone IS NOT NULL AND phone != '' - JSON 字段如
meta必须先提取再脱敏：meta->>'phone'（PostgreSQL）或TRIM(BOTH '"' FROM JSON_EXTRACT(meta, '$.phone'))（MySQL），否则返回带引号字符串或NULL
权限隔离比脱敏逻辑更重要
用户只要还有 SELECT 权限在基表上，就能绕过视图直接查出明文。视图不是防火墙，它只是个查询模板。
- 必须显式执行：
REVOKE SELECT ON db_name.users FROM 'user_a'@'%' - 只授视图权限：
GRANT SELECT ON db_name.v_user_safe TO 'user_a'@'%' - 检查是否误授宽泛权限：
SHOW GRANTS FOR 'user_a'@'%'，重点看有没有SELECT ON db_name.* - MySQL 8.0+ 可用角色打包权限，避免漏授；PostgreSQL 需确认
SET ROLE是否激活
WHERE 条件不能依赖脱敏后字段
视图里的 phone_masked 是计算列，数据库优化器无法对其建立索引，WHERE 中使用它会导致全表扫描。
-
WHERE phone_masked = '138****1234'查不到数据，也不走索引 - 真要按格式过滤，得回到原始字段：
WHERE phone LIKE '138%1234'或加冗余前缀字段（如phone_prefix CHAR(3)） - BI 工具常自动把筛选拖到视图字段上，需提前禁用该字段的过滤能力
- 脱敏列不可用于
JOIN或GROUP BY，否则结果不可控
最容易被忽略的是：视图定义里用了 SELECT * 或漏写了某个敏感字段，就会让脱敏形同虚设；更隐蔽的是 DEFINDER 权限缺失——如果创建视图的账号本身没权限读某列，那连视图都查不出来，报错却看不出原因。
