视图中不写敏感字段即可隐藏，但必须同步撤回基表SELECT权限、仅授予视图权限，显式列出字段禁用SELECT*，脱敏字段需重命名并预处理NULL值，防止视图可更新。
视图里不写字段，它就不会出现
SQL 视图本身不存数据，只存 SELECT 语句。所以“减少不必要的字段”，最直接的办法就是：在定义视图时，**只写你需要的字段，一个不多，一个不少**。
比如基表有 id、name、email、password_hash、created_at 五个字段，但应用只需展示用户基本信息——那就只选前三个：
CREATE VIEW public_users AS SELECT id, name, email FROM users;
之后任何查询 SELECT * FROM public_users 都不会返回 password_hash 或 created_at，连元数据里都不存在这些列。
- 严禁在生产视图中使用
SELECT *，否则基表新增字段会自动透出，可能暴露敏感列 - 字段名必须显式写出，不能依赖别名推导（尤其 PostgreSQL 要求带别名时必须声明视图列名）
- 如果基表字段重命名或类型变更，视图会失效报错，需同步更新定义
为什么不能用 WHERE 或 CASE “隐藏”字段
有人试图用 CASE WHEN 1=0 THEN password_hash END 或 WHERE 1=0 来“屏蔽”字段，这完全错误。
CASE 表达式仍会生成一列，字段名、类型、是否可空等元信息全部保留，应用层或 ORM 仍会尝试映射该字段，容易引发 column not found 或序列化异常；WHERE 1=0 则让整个视图恒为空，不是隐藏，是废掉。
-
WHERE只能过滤行，不能消除列 -
CASE、COALESCE、NULLIF等表达式都会产出新列，且列名默认是表达式文本（如case when ... end），难以维护 - 数据库日志、慢查分析、执行计划里仍能看到这些字段参与计算，徒增开销
多表 JOIN 场景下字段冲突怎么处理
两个表都有 id 字段，直接 SELECT * 会报错“column 'id' ambiguous”。视图里必须显式指定来源并重命名：
CREATE VIEW user_order_summary AS SELECT u.id AS user_id, u.name, o.id AS order_id, o.amount FROM users u JOIN orders o ON u.id = o.user_id;
这样既避免歧义，又控制了输出字段粒度——你清楚知道哪些字段来自哪张表，也方便后续加索引或做权限隔离。
- 别名要用
AS显式声明，不要依赖隐式推断（MySQL 兼容性差，SQL Server 严格要求） - JOIN 后字段名重复时，不重命名会导致视图创建失败，或查询时报错
- 聚合字段（如
COUNT(*)、AVG(salary)）必须给别名，否则视图列名不可预测
视图字段缺失导致应用报错的典型现象
应用代码里写了 row.password_hash，但视图没包含该字段，运行时抛出 column not found（PostgreSQL/MySQL）或 undefined property（PHP/Python ORM）。这不是数据库问题，是视图契约和代码契约不一致。
排查路径很明确：查视图定义（SHOW CREATE VIEW view_name 或 pg_get_viewdef('view_name')），再比对应用层字段引用。
- ORM 自动映射
SELECT *时极易踩坑，务必禁用 - 视图字段变更属于接口变更，需同步更新文档、测试用例和调用方
- 开发阶段可用
DESCRIBE view_name或\d view_name快速确认字段列表
视图字段精简这事，表面是写法问题，本质是契约管理——你定义的每一列，都是对下游承诺的数据接口。漏写一个敏感字段，可能泄露隐私；多写一个冗余字段，可能拖慢查询、撑爆网络、误导应用逻辑。
