数据库触发器无法直接获取真实业务用户，需应用层透传用户标识（如会话变量、自定义配置、CONTEXT_INFO等），数据库侧配合读取，所有方案均依赖应用主动设置，无自动识别能力。
MySQL 触发器里拿不到 USER() 或 CURRENT_USER() 的真实操作人？
默认情况下，触发器内调用 USER() 返回的是连接池账号（比如 app@10.0.0.5），CURRENT_USER() 返回的是认证账号（比如 app@%），都不是发起 SQL 的具体业务用户。真要记录“谁改的”，得靠应用层透传 + 数据库侧配合。
- 数据库本身不保存 HTTP 请求头、JWT 用户 ID 或 session ID，触发器无法凭空知道前端登录态
- 如果应用用统一中间件或 ORM（如 MyBatis、Sequelize），可在执行 SQL 前显式设置会话变量，比如
SET @current_user_id = 12345; - 触发器中必须用
@current_user_id这种用户变量，不能用SYSTEM_USER()或SESSION_USER()—— 它们和USER()本质一样，反映的是连接身份，不是业务身份 - 注意变量作用域：每个连接独立，不会跨连接污染，但需确保每次请求都重设，否则可能残留上一个用户的值
PostgreSQL 怎么在触发器里拿到应用传来的用户名？
PostgreSQL 更灵活，支持通过 current_setting('app.user_id', true) 读取自定义配置项，前提是应用在事务开始前调用 SET app.user_id = 'u_789';。
- 必须提前用
ALTER DATABASE xxx SET app.user_id = '';或在postgresql.conf中声明该配置项，否则current_setting会报错 “unrecognized configuration parameter” - 第二个参数
true表示“找不到时不报错，返回 NULL”，建议始终带上，避免触发器因配置缺失而中断 DML - 触发器函数里别直接写死
current_setting('app.user_id')，先判空：COALESCE(current_setting('app.user_id', true), 'unknown') - 这个机制依赖应用主动 SET，如果某条 SQL 漏了（比如直连调试、脚本执行），就只能记成
unknown—— 日志里看到大量 unknown，大概率是客户端没统一处理
SQL Server 触发器怎么安全获取修改人？慎用 ORIGINAL_LOGIN()
ORIGINAL_LOGIN() 看起来像答案，但它返回的是最初建立连接的 Windows / SQL 登录名，不是当前 EXECUTE AS 用户，更不是 Web 应用里的 userId。真要用，得配合上下文切换。
- 如果应用启用了
EXECUTE AS USER = 'web_user_123'，那触发器里用USER_NAME()才能拿到它；但多数应用并不这么用，而是复用连接池账号 - 更可靠的做法是：应用在 UPDATE/INSERT 前，把用户标识写进临时表（如
#audit_context）或用CONTEXT_INFO()传二进制数据（需先转成VARBINARY(128)） -
CONTEXT_INFO()是会话级的，触发器里可用CONVERT(VARCHAR(128), CONTEXT_INFO())解码，但要注意长度限制和字符编码（建议 UTF-8 先转 base64） - 别依赖
HOST_NAME()或APP_NAME()—— 它们容易被伪造，且无法区分同一台机器上的多个用户
所有方案都绕不开一个事实：数据库不管理业务会话
触发器只是被动响应 SQL，它没有 API 调用栈、没有 request context、不解析 application/json。所谓“记录谁改的”，本质上是在应用层埋点 + 数据库侧约定好接收方式。
- 最简路径：所有 DML 都走存储过程，入参强制带
@operator_id，触发器从 stored procedure 参数里取值（但没法拦截直连修改） - 审计强要求场景，建议用数据库代理层（如 ProxySQL、pgBouncer 配合 auth query）或变更数据捕获（CDC）工具（如 Debezium），它们能在协议层抓到原始 client info
- 如果已经上线又没法改应用，唯一补救是查
information_schema.PROCESSLIST（MySQL）或pg_stat_activity（PostgreSQL）关联时间戳反推，但精度低、有竞态、且需要高权限
