视图无法真正实现安全的行级权限隔离，仅RLS能兜底；因视图可被绕过直查基表，而RLS绑定基表，对所有访问路径自动注入tenant_id过滤，并支持WITH CHECK拦截非法写入。
视图无法真正实现安全的行级权限隔离，它只是个查询封装，绕过太容易。真要隔离数据，必须用 ROW LEVEL SECURITY（RLS）策略。
为什么SQL视图做不了可靠的行级权限
视图里写 WHERE user_id = current_user 看似可行，但实际漏洞明显：
- 用户只要绕开视图、直接查底层表，过滤就完全失效——除非你显式收回对基表的
SELECT权限，而很多系统做不到这点（比如DBA要用基表做运维） -
current_user是数据库角色名，不是业务用户ID；多数应用用一个连接池账号连库，所有请求的current_user都一样 - 无法区分同一租户下的不同角色（如管理员 vs 普通成员），视图逻辑僵硬，改一次就得重建
- 视图定义不可参数化，
tenant_id只能靠会话变量传入，而变量传递在连接池（如 PgBouncer）中默认被忽略
current_setting() + 视图的典型误用场景
有人用 SET app.current_tenant = 'acme' 配合视图里的 current_setting('app.current_tenant', true)，这看似灵活，但隐患不少：
- 必须确保每次连接都执行
SET，否则变量为空，::int转换会报错（哪怕加了第二参数true，返回NULL后跟INT字段比较仍为UNKNOWN，导致全表无匹配） - PgBouncer 默认丢弃
SET语句，需配置ignore_startup_parameters = application_name并启用application_name透传，否则变量根本到不了后端 - 应用若复用连接但忘记重置变量，前一个请求的
tenant_id会污染下一个请求 - DBA 或监控工具直连时未设变量，查视图返回空结果，排查困难
RLS 才是唯一推荐的行级隔离方案
PostgreSQL 的 RLS 在查询重写阶段自动注入 WHERE 条件，不依赖应用是否走视图、是否拼对字段，也不怕连接复用或变量遗漏：
- 策略绑定在表上，对所有访问该表的操作生效（包括
SELECT、UPDATE、DELETE），无需修改任何应用代码 - 支持基于会话变量（
current_setting()）、角色属性（current_role）、甚至自定义函数（如is_admin(current_user)）构造策略表达式 - 可为不同角色定义不同策略，例如：普通用户只能查自己租户，管理员可查全部，审计角色只读特定字段
- 启用 RLS 后，即使用户有基表
SELECT权限，也会被策略拦截——这是视图永远做不到的强制性
示例：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_policy ON orders
FOR ALL
USING (tenant_id = current_setting('app.current_tenant', true)::uuid);
如果非要用视图，至少守住这三条底线
极少数遗留系统无法立刻切 RLS，那用视图至少得做到：
- 对所有相关基表，执行
REVOKE SELECT ON TABLE xxx FROM PUBLIC，再只给视图GRANT SELECT——否则等于没设防 - 视图中避免使用
current_user，改用current_setting('app.user_id', true)并在应用层每次请求前强制SET，同时加 DB 层触发器或应用中间件校验该变量非空 - 禁止任何角色拥有
VIEW DEFINITION权限（除非 DBA），否则用户能SELECT pg_get_viewdef('my_view')看穿过滤逻辑，进而反推绕过方式
真正的隔离不在 SQL 怎么写，而在数据库是否“不给你机会写错”。RLS 是那个不给你机会的机制；视图只是帮你少打几个字，仅此而已。
