不能。SQL触发器无法作为权限审核最后防线，因其运行在定义者权限上下文，CURRENT_USER()返回定义者而非调用者，且禁止执行GRANT/REVOKE等DDL语句，仅能做基于行数据的约束校验。
不能。SQL触发器不是权限审核的最后防线，它根本无法承担这个角色——因为它的执行权限是固定的、不可动态切换的，且无法感知调用者真实身份。
MySQL触发器里CURRENT_USER()返回的是谁？
返回的是触发器定义者（比如 'admin'@'localhost'），不是执行 INSERT 的应用用户。哪怕你用 app_user 连接数据库并修改了 users 表，触发器内 CURRENT_USER() 依然显示定义者账号。这意味着你根本拿不到实际操作人信息，自然无法做“按用户审核”。
- 触发器运行在定义者上下文，这是硬性安全模型，不是配置能改的
-
USER()和CURRENT_USER()在触发器中行为一致，都指向定义者 - 想从触发器里读取应用层传入的用户标识？必须靠显式字段（如
created_by列）传递，不能依赖会话变量或连接属性
为什么触发器不能执行GRANT/REVOKE？
不是权限不够，是 MySQL 明确禁止在触发器中执行 DDL 语句。只要触发器体里出现 GRANT 或 REVOKE，CREATE TRIGGER 就会直接报错：ERROR 1357 (HY000): Cannot use GRANT in stored function or trigger。
- PostgreSQL 虽允许触发器调用 DDL，但必须通过
SECURITY DEFINER函数间接执行，且函数所有者得提前拥有目标权限 - SQL Server 触发器调用
xp_cmdshell执行外部授权命令？属于高危绕过，生产环境应禁用 - 所谓“自动授权”，本质是把权限逻辑从数据库移到应用层或中间服务——监听变更、校验策略、再显式调用授权接口
触发器能做的“防线”仅限于数据层约束
它唯一能可靠干预的，是当前事务内的数据状态。比如在 BEFORE INSERT 中检查某字段是否为空、是否重复、是否超出业务阈值——这些判断基于行数据本身，不依赖外部身份或权限上下文。
- 可以阻止非法写入：
IF NEW.status NOT IN ('pending', 'approved') THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid status'; END IF; - 不能替代 RBAC：无法根据
app_user是否属于“财务组”来决定能否插入某条记录 - 审计日志可记，但“谁在什么时候改了什么”靠的是表里存的
updated_by字段，不是触发器猜出来的
真正容易被忽略的是：触发器越想当“审核者”，越容易变成漏洞入口。一旦它以高权限定义者身份运行，又拼接了未过滤的输入（比如用户名字段），就可能被诱导执行越权操作——这不是防线，是后门。
