触发器中不可用 SESSION_USER/CURRENT_USER 做权限判断，因其返回数据库用户而非应用用户；校验失败须 RAISE/SIGNAL 而非仅修改 NEW；不支持 SELECT 触发器，读权限需用 RLS 或视图；避免嵌套与重查询以防性能与死锁问题。
触发器里不能用 SESSION_USER 或 CURRENT_USER 做权限判断
多数人写权限校验触发器时，第一反应是读取当前用户身份再查权限表——但 PostgreSQL 的 BEFORE INSERT/UPDATE/DELETE 触发器里，SESSION_USER 和 CURRENT_USER 返回的是执行语句的用户，不是发起请求的应用用户（比如用了连接池或代理层）。MySQL 更麻烦：USER() 返回的是「host@user」格式，且触发器中无法可靠获取应用传来的上下文标识。
实操建议：
- 把权限判定逻辑从触发器里移出去，改由应用层在 SQL 执行前拼装
WHERE条件，或使用行级安全策略（PostgreSQL 的RLS） - 如果非要用触发器，必须让应用显式传入用户 ID 或角色标识，例如通过
SET LOCAL app.user_id = 'u123'（PostgreSQL），再在触发器里用current_setting('app.user_id', true)读取 - MySQL 没有等效机制，强行用触发器做动态权限控制基本不可靠，容易绕过
INSERT/UPDATE 触发器中修改 NEW 字段会改变写入值
这是最常被忽略的副作用：在 BEFORE 触发器里给 NEW.role_id 赋值，实际插入的就是这个新值。很多人想“校验后放行”，结果一不小心把权限字段给覆盖了。
常见错误现象：
- 用户 A 尝试插入一条记录，触发器检查其无权操作某字段，本应报错，却悄悄把
NEW.status改成默认值并放行 - 触发器中误写
NEW.created_by := current_user，导致所有插入记录的创建者都变成数据库用户，而非真实业务用户
实操建议：
- 校验失败必须用
RAISE EXCEPTION（PostgreSQL）或SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'xxx'（MySQL），不能只改NEW就返回 - 若需补全字段（如自动填
updated_at），确保只操作应用允许被覆盖的字段，且不与业务逻辑冲突 - 测试时务必用不同角色用户直连数据库执行 DML，绕过 ORM 和中间件验证真实行为
触发器无法拦截 SELECT，动态权限必须靠视图或 RLS
有人以为建个 BEFORE SELECT 触发器就能拦查询——但 SQL 标准根本不支持 SELECT 的触发器。PostgreSQL 和 MySQL 都没有这个语法，写了直接报错 ERROR: syntax error at or near "SELECT"。
使用场景限制很明确：想对读操作做行级过滤，只能选以下路径：
- PostgreSQL：启用
row level security，对表执行ALTER TABLE orders ENABLE ROW LEVEL SECURITY，再加CREATE POLICY - MySQL：没有原生 RLS，只能用视图封装，例如
CREATE VIEW user_orders AS SELECT * FROM orders WHERE created_by = USER()，但注意视图无法防止用户直接查基表 - 通用兜底：所有
SELECT必须走应用层构造的带权限条件的 SQL，禁止裸表查询
触发器嵌套和性能陷阱：一次 UPDATE 可能触发 N 层校验
当权限表本身也被其他触发器监听，或主表更新又级联更新关联表时，一个简单语句可能触发数十次权限检查。更糟的是，有些触发器会去查权限树、调用函数、甚至发 HTTP 请求——这些在事务内执行，会拖慢整个事务，还可能死锁。
性能影响明显：
- 单条
UPDATE在高权限层级下，触发器内查 3 层角色继承关系 + 5 张权限映射表，耗时从 2ms 涨到 180ms - 并发写入时，多个触发器争抢权限缓存表的行锁，出现
deadlock detected
实操建议：
- 触发器内只做轻量校验：查一张扁平化的
user_role_permissions表，不要 JOIN 多张表或递归查角色继承 - 权限数据变更频率低，可预热到应用内存或 Redis，触发器只比对缓存 key，不查库
- 上线前用
EXPLAIN ANALYZE看触发器实际执行计划，确认没走全表扫描
真正难的不是写触发器，而是让权限模型和数据库能力匹配——多数业务根本不需要在 DB 层做动态权限，反而该把复杂度留在应用可控范围内。触发器一旦嵌套、一旦要查外部状态、一旦涉及读操作，就大概率踩坑。
