视图中用CASE WHEN做字段级脱敏最稳妥，直接在SELECT中条件替换敏感字段，兼容所有主流数据库且不改源表；需显式处理NULL，避免自定义函数（性能与权限风险），WHERE不可依赖脱敏字段，PostgreSQL可用行安全策略补充身份化脱敏。
视图里用 CASE WHEN 做字段级脱敏最稳妥
直接在 SELECT 里对敏感字段做条件替换，不改源表、不加中间层，是多数生产环境的首选。比如手机号只显示前3后4，邮箱只显示用户名首字母和域名。
- 别用
CONCAT拼接空字符串来“隐藏”，MySQL 8.0+ 的REGEXP_REPLACE或 PostgreSQL 的REGEXP_REPLACE()更可控，但兼容性差；CASE WHEN兼容所有主流数据库 - 注意 NULL 处理：如果原始字段可能为
NULL，CASE分支必须显式写WHEN col IS NULL THEN '***'，否则结果仍是NULL - 示例（MySQL）：
SELECT id, name, CASE WHEN phone IS NOT NULL THEN CONCAT(LEFT(phone,3), '****', RIGHT(phone,4)) ELSE '***' END AS phone_masked FROM users;
避免在视图中调用自定义函数做脱敏
看起来封装干净，实际容易踩性能和权限两个坑。
- MySQL 的存储函数在视图中会被逐行调用，大数据量下 CPU 拉满；PostgreSQL 的
STABLE函数虽可优化，但跨库部署时函数定义同步难 - 函数执行依赖
DEFINER权限，视图被其他用户查询时可能报ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist - 脱敏逻辑一旦写死在函数里，审计或策略调整就得改函数+重编译，不如把规则摊开在视图 DDL 里直观
WHERE 条件里不能依赖脱敏后的字段值
这是新手最常翻车的地方：以为 SELECT phone_masked FROM v_user WHERE phone_masked = '138****1234' 能查到数据，其实查不到。
- 视图里的
phone_masked是计算列，不是物理存储，WHERE阶段还没执行SELECT表达式，数据库根本不知道phone_masked是啥 - 真要按脱敏格式过滤，得回到原始字段：比如用
WHERE phone LIKE '138%1234'，或者加冗余索引字段（如phone_prefix CHAR(3)） - 某些 BI 工具会自动把筛选拖到视图字段上，生成无效 SQL，得提前在工具侧禁用该字段的过滤能力
PostgreSQL 中用 ROW SECURITY POLICY 替代部分视图场景
当脱敏规则和用户身份强绑定（比如 HR 可见全量身份证，普通员工只能看出生年份），视图就力不从心了。
-
CREATE POLICY可以让同一张表对不同角色返回不同行/列，且策略在查询计划早期生效，比视图嵌套更底层、更高效 - 但注意：策略只控制
SELECT/INSERT/UPDATE/DELETE行为，不改变字段内容本身；若仍需隐藏字段值（如把salary固定返回0），还得配合SECURITY DEFINER函数或视图 - 启用 RLS 后，超级用户默认绕过策略，测试时记得用普通角色连接验证
