最可靠方式是直接在视图select子句中排除敏感字段，显式列出所需列并禁用select*，同步撤回基表select权限、仅授予视图权限，且须防止视图可更新。
直接在视图 SELECT 子句里不写敏感字段，是最可靠、最无副作用的限制方式。其他手段（如 CASE 掩码、WHERE 1=0）看似“隐藏”，实则暴露元数据或引入性能/安全风险。
显式列出字段，禁用 SELECT *
视图不投影没写进 SELECT 的列，这是数据库引擎级行为，不是逻辑过滤。只要定义里没出现 password_hash、ssn、credit_card_number 这类字段，用户查视图就根本看不到它们——连字段名、类型、是否可空都不会出现在结果集元信息里。
- 必须手写完整字段列表：
CREATE VIEW safe_users AS SELECT id, username, email, created_at FROM users - 严禁生产环境用
SELECT *：基表新增敏感列后，视图会无意暴露它 - 字段拼写要核对真实名称：比如
cc_number和credit_card_no可能是不同字段 - PostgreSQL 要求含表达式的列必须显式指定别名，否则建视图失败
权限必须单独授予视图，且收回基表权限
视图权限和基表权限完全独立。用户有基表 SELECT 权限，不代表能查视图；反之，只授视图权限，也不代表能绕过视图去查原表——前提是基表权限已被显式回收。
- 执行
GRANT SELECT ON safe_users TO 'app_user'@'%'（MySQL）或GRANT SELECT ON safe_users TO app_user（PostgreSQL） - 必须同步执行
REVOKE SELECT ON users FROM 'app_user'@'%'，否则用户仍可直连原表 - MySQL 8.0+ 可用角色批量管理：
CREATE ROLE analyst; GRANT SELECT ON safe_users TO analyst; - PostgreSQL 中若未设
SECURITY DEFINER，默认按调用者权限检查，用户仍需基表权限——必须加WITH (security_invoker = false)
避免在视图中使用脱敏表达式或函数
用 CASE WHEN 把邮箱变成 ***@***.com 或调用 MD5(email)，看起来更“安全”，但实际埋了三个坑：字段仍在结果集中、索引失效、逻辑可被反推。
-
CASE表达式仍生成同名或别名列，应用层可能误读为原始字段 - 函数计算列无法走索引：如果后续要在
WHERE email_masked = 'xxx'过滤，必然全表扫描 - 视图定义可被有权限用户查看：
pg_get_viewdef()（PG）或SHOW CREATE VIEW（MySQL）直接暴露脱敏逻辑 - 非确定性函数（如
NOW()、RANDOM()）会让查询计划不稳定，还可能触发权限校验异常
注意可更新视图带来的隐式越权风险
单表、无聚合、无表达式的视图在 MySQL 和 PostgreSQL 中默认允许 UPDATE。用户虽看不到 is_deleted 列，但执行 UPDATE safe_users SET name = 'x' WHERE id = 1 时，底层仍会更新整行——可能意外恢复软删除记录或改写隐藏字段。
- 如需禁止更新，建视图时加
WITH CHECK OPTION（MySQL）或显式拒绝UPDATE权限 - SQL Server 中若基表列启用了 Always Encrypted，视图无法解密，但列本身仍存在——必须从
SELECT中剔除才能真正隔离 - 测试时务必用真实业务账号连接，
sa或dbo直连会绕过所有权限检查，掩盖问题
最容易被忽略的是：视图定义一旦上线，基表结构变更不会自动同步。新增敏感字段、重命名列、修改类型，都得人工检查并更新视图定义——没人看守的视图，迟早会漏掉新冒出来的 internal_notes 或 audit_log。
