触发器不能替代RLS实现合规性过滤，因其无法在SELECT前自动注入WHERE条件，仅能响应DML事件；RLS在查询重写阶段统一注入策略谓词，覆盖SELECT/INSERT/UPDATE/DELETE全操作类型，且与会话变量天然集成。
触发器不能替代行级安全（RLS）策略来实现合规性过滤——它不是设计用来做“自动 WHERE 过滤”的，强行用触发器拦截或丢弃数据，会破坏语义、引发不可预测错误，甚至绕过权限检查。
为什么不能用触发器代替 RLS 做动态行过滤
触发器是 DML 事件的响应程序，不是查询重写器。它无法在 SELECT 执行前悄悄加一个 WHERE tenant_id = current_setting('app.current_tenant') 条件；它只能在 INSERT/UPDATE/DELETE 发生时干预数据本身或抛错。
- 想“不让用户查到别人的数据”？
SELECT不触发任何触发器，BEFORE/AFTER 都无效 - 想“INSERT 时自动塞入 tenant_id”？可以，但这是数据填充，不是过滤
- 想“UPDATE 时拒绝跨租户修改”？可做，但需在
BEFORE UPDATE中显式RAISE EXCEPTION，且必须配合应用层传参校验，否则容易漏判 - 误用
AFTER触发器做拦截，会导致事务已提交再报错，出现数据不一致
真正该用 RLS 的地方：SELECT/INSERT/UPDATE/DELETE 全链路自动过滤
PostgreSQL 的行级安全（RLS）才是专为“动态过滤不合规记录”设计的机制。它在查询解析阶段就注入谓词，对所有操作类型生效，且与角色、会话变量天然集成。
- 启用 RLS：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY; - 定义租户隔离策略：
CREATE POLICY tenant_isolation ON orders FOR ALL USING (tenant_id = current_setting('app.current_tenant', true)::uuid); - 关键参数说明：
current_setting('app.current_tenant', true)的第二个参数true表示“不报错，返回 NULL”，避免因未设变量导致全表不可见 - INSERT 必须带
WITH CHECK子句验证新行归属：CREATE POLICY insert_tenant_check ON orders FOR INSERT WITH CHECK (tenant_id = current_setting('app.current_tenant', true)::uuid); - 策略只对启用了 RLS 的用户生效；超级用户默认绕过，如需强制执行，需加
ALTER TABLE ... FORCE ROW LEVEL SECURITY;
触发器能补什么？——仅限 RLS 无法覆盖的强校验场景
RLS 管“能不能看到/改到”，触发器管“改得对不对”。比如业务规则要求“订单金额变更不得超过原值 20%”，这种逻辑无法用 RLS 表达，必须用触发器兜底。
- 使用
BEFORE UPDATE检查：IF NEW.amount > OLD.amount * 1.2 THEN RAISE EXCEPTION 'amount increase exceeds 20%%'; END IF; - 务必引用
OLD和NEW，不能查表——触发器内禁止SELECT同表 - 避免在触发器里调
CURRENT_USER或SESSION_USER做权限判断，应统一走current_setting()读取应用注入的上下文 - 高并发下触发器函数若含复杂计算或外部调用（如 HTTP），会拖慢主事务，建议只做轻量断言
最容易被忽略的坑：RLS + 触发器组合时的上下文一致性
RLS 策略依赖 current_setting('app.current_tenant')，而触发器函数里也得用同一个会话变量——如果应用忘记在每次请求开始时 SET app.current_tenant = 'xxx'，那 RLS 失效、触发器校验失准，两个机制同时崩。
- 不要在触发器里硬编码租户 ID，也不要依赖
CURRENT_USER推导租户（角色名 ≠ 租户 ID） - 测试时务必用普通角色连接，并确认
SHOW app.current_tenant;返回预期值 - pgAudit 日志里看不到 RLS 过滤掉的行，但能看到触发器抛出的异常；监控要覆盖这两类信号
