视图无法直接实现动态字段掩码，必须通过CASE结合当前用户角色判断（如PostgreSQL的pg_has_role、SQL Server的IS_MEMBER）来实现；硬编码用户名或依赖WHERE过滤均无效，且需注意各数据库角色校验函数的语义差异与安全限制。
视图里不能直接做字段掩码，得靠条件表达式
SQL 视图本身不支持“按当前用户角色动态隐藏字段值”，它只是静态查询的封装。真正实现字段掩码（比如 phone 字段对普通用户显示为 ***-****-1234，对管理员显示明文），必须在视图定义中用 CASE + 当前用户上下文判断——而这个“当前用户”得靠数据库提供的会话变量或函数来获取，比如 PostgreSQL 的 current_user 或 session_user，MySQL 8.0+ 的 USER() 或自定义会话变量，SQL Server 的 IS_MEMBER('role_name')。
常见错误是直接在视图里写 WHERE role = 'admin' ——这根本无效，因为视图不感知调用者身份；或者试图用存储过程替代视图，结果失去视图的透明访问优势。
- PostgreSQL 示例：用
current_user匹配角色名，配合CASE掩码phone - MySQL 注意：内置
USER()返回'user@host'，需用SUBSTRING_INDEX(USER(), '@', 1)提取用户名，且必须提前给用户授角色标签（如通过注释或额外权限表） - SQL Server 更稳妥：用
IS_MEMBER('db_datareader_admin')判断是否在特定角色内，比依赖用户名更符合 RBAC 原则
PostgreSQL 中用 current_user + pg_roles 实现角色校验
仅靠 current_user 字符串匹配不够安全——用户可能重名，或账号未绑定角色。应结合系统目录 pg_roles 和成员关系 pg_auth_members 确认真实角色归属。
实操建议：
- 不要写
CASE WHEN current_user = 'admin_user' THEN phone ELSE mask_phone(phone) END——绕过角色体系，权限变更时视图要重改 - 正确做法：用
pg_has_role(current_user, 'sensitive_reader', 'member')返回布尔值，再进CASE - 注意
pg_has_role第三个参数必须是'member'（检查是否为该角色成员），不是'usage'或省略（后者查的是使用权限，非成员资格） - 示例片段：
CASE WHEN pg_has_role(current_user, 'hr_analyst', 'member') THEN phone ELSE concat('***-****-', right(phone, 4)) END AS phone
MySQL 8.0+ 需手动维护角色映射表
MySQL 原生不提供类似 pg_has_role 的函数，IS_ROLE_IN_SESSION() 仅限企业版。开源版必须自己建一张 user_roles 表，并在视图中 JOIN 或子查询关联。
容易踩的坑：
- 把角色存成逗号分隔字符串（如
'admin,finance'）——无法走索引，FIND_IN_SET()性能差，且不支持嵌套角色 - 忽略连接空值：如果某用户没在
user_roles表里，LEFT JOIN后角色字段为NULL，CASE必须显式处理WHEN role IS NULL，否则掩码逻辑失效 - 视图定义里写
SELECT ... FROM users u LEFT JOIN user_roles ur ON u.username = ur.username是可行的，但要求users表有稳定、唯一的用户名字段（不能只靠USER()解析）
SQL Server 视图中避免硬编码 SID 或 login_name
SQL Server 的 SYSTEM_USER 或 ORIGINAL_LOGIN() 返回的是登录名，不是数据库用户；而角色判断要用数据库级用户上下文。直接比对登录名会出错，尤其当 Windows 组登录或包含同名不同域账号时。
关键点：
- 优先用
IS_MEMBER('role_name')——它查的是当前会话在当前数据库中的角色成员资格，自动适配用户映射 - 若角色名含特殊字符（如空格、连字符），必须用方括号包裹：
IS_MEMBER('[data-analyst-v2]') - 不要用
USER_NAME()获取用户名再查sys.database_principals——多此一举，且在跨数据库上下文中不可靠 - 性能提示：每个字段掩码都调一次
IS_MEMBER()不影响性能，但若掩码逻辑复杂（如 AES 加密），应考虑移至应用层，视图只做轻量脱敏
最易被忽略的点：所有数据库的角色判断函数都只反映“当前会话”的权限状态，而视图一旦创建就固化执行计划。如果用户权限在会话中动态变更（如 EXECUTE AS 切换），PostgreSQL 和 SQL Server 能实时响应，MySQL 则完全无感知——这意味着 MySQL 场景下，掩码结果可能与用户当前实际权限不符，必须靠应用层二次校验或定期刷新会话变量。
