MySQL触发器无法直接获取真实业务用户，CURRENT_USER()仅返回认证账号；必须由应用层通过SET @current_operator显式传值，触发器用IF @current_operator IS NOT NULL兜底，否则记录CURRENT_USER()。
触发器里直接用 CURRENT_USER 可能记错人
很多开发者以为在触发器里调用 CURRENT_USER 就能拿到执行原始 SQL 的用户，结果发现日志里全是 'app_user'@'localhost' 或类似固定值。这是因为 CURRENT_USER 返回的是**认证用户**（即连接数据库时用的账号），不是发起变更的应用用户。如果所有请求都走同一个中间件账号（比如 Web 应用统一用 webapp 连接池），那所有记录都会显示这个账号，毫无区分度。
真正想记的，通常是业务层传下来的“操作人”，比如登录系统的员工工号或 token 解析出的 user_id。数据库本身不感知这个信息，必须由应用显式传入。
把操作人作为参数显式传给触发器
MySQL 触发器不支持接收外部参数，但可以用会话级用户变量（@variable）临时中转。前提是应用在执行变更前，先设置变量：
SET @current_operator = 'zhangsan';
然后在触发器里读取它。注意：该变量只在当前连接生命周期内有效，且必须在触发器执行前设置（不能在触发器里设再读）。
- 应用层需确保每次事务开始后、DML 语句前执行
SET @current_operator = ? - 触发器中要加空值判断：
IF @current_operator IS NOT NULL THEN ...，避免因忘记设置导致NULL写入 - 不要用
USER()或CURRENT_USER()替代——它们解决不了身份透传问题
触发器示例：记录变更人到 audit_log 表
假设有一张 orders 表，希望在每次 UPDATE 时把操作人写进 audit_log：
DELIMITER $$
CREATE TRIGGER orders_after_update
AFTER UPDATE ON orders
FOR EACH ROW
BEGIN
IF @current_operator IS NOT NULL THEN
INSERT INTO audit_log (table_name, record_id, action, operator, updated_at)
VALUES ('orders', NEW.id, 'UPDATE', @current_operator, NOW());
ELSE
INSERT INTO audit_log (table_name, record_id, action, operator, updated_at)
VALUES ('orders', NEW.id, 'UPDATE', CURRENT_USER(), NOW());
END IF;
END$$
DELIMITER ;
这里做了兜底：万一应用没设 @current_operator，至少还能记下数据库连接账号，比全空强。
注意 CURRENT_USER() 后面带括号是函数调用，不带括号（CURRENT_USER）在某些旧版本 MySQL 中会被当作字符串字面量，务必加括号。
PostgreSQL 和 SQL Server 怎么办？
PostgreSQL 没有等价的会话变量机制，但可以用 current_setting('app.operator', true) 配合 set_config() 实现类似效果，前提是在连接上启用 custom_variable_classes；SQL Server 则依赖 CONTEXT_INFO() 或更推荐的 SESSION_CONTEXT(N'operator')（SQL Server 2016+）。三者原理一致：应用先存，触发器再取。别指望数据库自动识别“真实操作人”——这从来就不是 SQL 层该解决的问题。
最容易被忽略的一点：连接池会复用连接，@current_operator 这类变量不会自动清空。如果上一个请求设置了它而下一个没重置，就会张冠李戴。稳妥做法是在每次业务逻辑开始时显式 SET @current_operator = NULL，再按需赋值。
