直接授视图权限能实现基础隔离，但必须同步处理基表schema的USAGE权限、DEFINER账号有效性、行级策略干扰等隐性依赖，漏任一环即失败；需禁用SELECT*、显式列名、加WITH CHECK OPTION，并采用role_readonly角色+v_前缀命名实现可持续授权。
直接授视图权限能实现基础隔离，但必须同步处理基表 schema 的 USAGE 权限、DEFINER 账号有效性、行级策略干扰等隐性依赖——漏掉任一环，视图执行时就会失败。
GRANT SELECT ON view 为什么常报 permission denied for table
视图不存数据，执行时仍要访问底层表。不同数据库对「谁的权限生效」处理不同：
- PostgreSQL 和 SQL Server 默认走
DEFINER模型：检查视图创建者的权限，不是调用者 - MySQL 8.0+ 默认是
INVOKER，但生产环境普遍显式设为DEFINER统一管控
哪怕你 GRANT SELECT ON v_active_users TO analyst，如果 analyst 对 orders 表所在 schema 缺少 USAGE 权限，照样报错 permission denied for table orders。
所以，授视图权限只是第一步；必须确认基表所在 schema 的 USAGE 权限已授予对应角色。
CREATE VIEW 时必须避开的三个硬伤
视图定义本身决定权限能否真正隔离：
- 禁用
SELECT *：字段增减会导致下游应用解析失败，比如 Java 应用遇到新增列可能抛SQLFeatureNotSupportedException - 敏感字段必须显式列出：靠
GRANT SELECT (id,name) ON users做列级授权不可靠——MySQL 5.7 不支持列级授权；PostgreSQL 列授权对UPDATE无效；加新列后必须补授权，运维不可持续 - 需要行级过滤时，务必加
WITH CHECK OPTION：例如CREATE VIEW v_finance_daily AS SELECT * FROM transactions WHERE type = 'revenue' WITH CHECK OPTION，否则用户可通过INSERT INTO v_finance_daily插入type='expense'记录
role_readonly + v_* 前缀才是可持续的分发模式
当有多个角色（如 BI 工程师、运营专员、风控分析师）需要不同维度的数据时，手动逐个 GRANT SELECT ON v_user_basic TO analyst 会迅速失控：
- 建统一基础角色
role_readonly，只赋予对所有v_*视图的SELECT - 让各业务角色继承它：
GRANT role_readonly TO analyst - 视图命名带域前缀，如
v_finance_revenue_daily、v_marketing_campaigns，方便后期用正则批量审计或授权（例如SELECT table_name FROM information_schema.views WHERE table_name LIKE 'v_finance%'）
这样，新增一个 v_finance_pnl_monthly 视图，只需确保它在 role_readonly 授权范围内，所有下游角色自动获得访问权，无需改用户。
租户隔离不能只靠视图 WHERE tenant_id = ...
PostgreSQL 中写 CURRENT_SETTING('app.tenant_id') 在视图里常失效，因为视图定义是静态编译的，函数在创建时就被当成常量求值或直接报错。常见现象包括：
- 创建视图时报
ERROR: function current_setting(unknown) is not allowed in view definitions - 查询时返回空结果，或全量数据（
app.tenant_id未设、拼写错误、没注册到custom_variable_classes） - 多个租户并发查同一视图，结果互相污染（连接池复用导致会话变量残留）
真正能跑通的前提是：postgresql.conf 中已配置 custom_variable_classes = 'app'，且应用每次建连后立即执行 SET app.tenant_id = 't123'。
MySQL / SQL Server 用户别试 CURRENT_SETTING 或 SESSION_CONTEXT() 直接进视图：这两个数据库压根不支持会话变量在视图中动态解析。
最易被忽略的是：即使视图逻辑和权限都配对了，只要有人绕过视图直查基表，隔离就形同虚设。RLS（行级安全策略）才是 PostgreSQL 下真正兜底的方案，而 MySQL 必须靠应用层强制拼 WHERE tenant_id = ? ——视图在这里只负责字段裁剪和语义封装，不该承担核心隔离职责。
