视图无法替代rls实现行级隔离，因其仅是查询封装，用户可绕过视图直查基表；必须启用rls（alter table ... enable row level security）并创建策略（create policy），视图仅作安全壳和字段简化。
视图本身不能实现行级权限隔离，它只做列级过滤和静态条件封装；真要隔离行，得靠 CREATE POLICY + ENABLE ROW LEVEL SECURITY。视图可以配合RLS用，但别指望单靠 CREATE VIEW 就能拦住越权查询。
为什么视图无法替代RLS做行级隔离
视图是“查询时展开”的虚拟表，它不改变底层权限模型。只要用户对基表有 SELECT 权限，就能绕过视图直接查原表——哪怕你只暴露三列、加了 WHERE is_active = true，攻击者或误操作者一句 SELECT * FROM customers 就全出来了。
- 视图不参与权限检查链，它只是语法糖
- 没有机制阻止用户
SET search_path TO pg_catalog后直连基表 - DBA、运维账号或带
BYPASSRLS属性的角色默认无视所有策略 - 物化视图更危险：它实际存数据，且刷新后可能包含本不该见的行
正确组合：视图 + RLS 的实用姿势
把视图当“安全壳”用，但核心防线必须是RLS。典型做法是：先在基表上开RLS并定义策略，再基于该表建视图，仅暴露必要字段。这样即使有人误查视图，也受RLS双重保护。
- 先开启RLS：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY - 再建策略：
CREATE POLICY tenant_isolation ON orders FOR ALL USING (tenant_id = current_setting('app.tenant_id', true)::uuid) - 最后建视图（可选）：
CREATE VIEW orders_summary AS SELECT id, status, amount FROM orders - 授权时只给视图权限：
GRANT SELECT ON orders_summary TO analyst，同时收回基表权限：REVOKE SELECT ON orders FROM analyst
注意：current_setting('app.tenant_id', true) 中的 true 表示“未设置时不报错”，避免连接初始化阶段崩掉；应用层必须在每次会话开始时执行 SET app.tenant_id = 'xxx'。
容易被忽略的坑：视图可更新性与RLS冲突
如果视图映射到单表且含主键，PostgreSQL允许通过视图执行 INSERT/UPDATE/DELETE。但一旦基表启用了RLS，这些写操作会受策略中的 WITH CHECK 子句约束——而视图定义里没声明这个逻辑，容易导致静默失败。
-
USING控制读取可见性，WITH CHECK控制写入合法性，二者必须显式区分 - 比如租户只能改自己订单，策略得写成：
CREATE POLICY update_own ON orders FOR UPDATE USING (tenant_id = current_setting('app.tenant_id')::uuid) WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid) - 否则
UPDATE orders_summary SET status = 'shipped' WHERE id = 123可能返回0行影响，却不报错 - 测试时务必用非管理员角色连库，手动跑
SELECT * FROM pg_policies确认策略已生效
最易翻车的点是：以为建了视图就万事大吉，忘了关RLS开关、漏设 WITH CHECK、或者应用没传 app.tenant_id 导致 current_setting 返回空值——这时策略条件恒为 false，整张表变不可见。
