PostgreSQL“多级级联安全视图”本质是权限隔离层、schema锁定层与RLS策略层三者叠加，缺一不可；仅靠视图内WHERE过滤无法保障安全，因视图不传递安全逻辑，基表未启用RLS或权限未回收即形同虚设。
安全视图不是“嵌套WHERE”，而是三层卡口
直接说结论：PostgreSQL 里所谓“多级级联安全视图”，本质是「权限隔离层 + schema 锁定层 + RLS 策略层」三者叠加，缺一不可。只在视图里写 WHERE tenant_id = current_setting('app.tenant_id') 或 JOIN users ON u.id = current_user_id()，根本不算安全——它既可被绕过，也不受策略强制约束。
为什么 CREATE VIEW v1 AS SELECT * FROM v2 不等于安全继承
视图链（比如 v_customer_secure → v_order_summary → v_product_detail）本身不传递任何安全逻辑。PostgreSQL 不会把上层视图的 WHERE 条件“注入”到下层查询中；它只是重写 SQL，最终仍落到基表上执行。如果基表没启用 RLS，整条链就形同虚设。
常见错误现象：
- 用
\d+ v_customer_secure看起来过滤了租户，但用EXPLAIN (VERBOSE) SELECT * FROM v_customer_secure发现执行计划里根本没有Filter: tenant_id = ... - 给用户只授
v_customer_secure的SELECT权限，但他仍能SELECT * FROM app.orders查出全量数据（因为基表权限没收回） -
v2里用了current_setting('app.user_id')，但没声明STABLE，导致策略被跳过或报错function cannot be called in this context
必须手动配置的三个硬性步骤
每级视图都要重复检查这三项，不能只做一次：
- 所有表引用必须带显式 schema 前缀，例如
SELECT * FROM core.customers，禁止SELECT * FROM customers（否则search_path变更时可能命中非预期 schema） - 视图创建后立即执行：
REVOKE SELECT ON TABLE core.customers FROM PUBLIC，再按角色GRANT SELECT ON secure_views.v_customer_secure TO analyst_role - 底层基表（如
core.customers）必须启用 RLS：ALTER TABLE core.customers ENABLE ROW LEVEL SECURITY，并定义策略，例如：CREATE POLICY tenant_isolation ON core.customers FOR SELECT USING (tenant_id = current_setting('app.tenant_id', TRUE)::UUID)
最容易被忽略的执行上下文陷阱
RLS 策略里的表达式必须能在策略求值上下文中安全运行。这意味着：
-
current_setting()必须配TRUE参数（current_setting('app.tenant_id', TRUE)），否则未设变量时直接报错而非静默跳过 - 自定义函数（如
get_current_tenant_id()）必须标记为STABLE或VOLATILE，且不能含事务控制、DDL 或外部调用 - 若使用
SET LOCAL app.tenant_id = 'xxx'，必须在同一个事务内完成查询，跨事务或连接池复用时变量会丢失 - 测试必须用目标角色连接，不能用
postgres超级用户——超级用户默认绕过 RLS，会掩盖策略失效问题
真正的“级联安全”不在视图定义里，而在每一层的权限回收、schema 锁定和策略绑定是否都严丝合缝。漏掉任意一个，就等于在防火墙上留了通风口。
