SQL Server中应优先使用ORIGINAL_LOGIN()获取操作用户，因其始终返回初始认证登录名，不受EXECUTE AS或连接池影响；SYSTEM_USER可能被上下文切换覆盖，仅在未使用权限切换时与ORIGINAL_LOGIN()结果一致。
SQL Server 中用 SYSTEM_USER 或 ORIGINAL_LOGIN() 获取操作用户
SQL Server 触发器里没有直接暴露“谁在应用层执行了这条语句”的机制，但能拿到连接层面的登录身份。关键区别在于：SYSTEM_USER 返回当前会话的上下文用户（可能被 EXECUTE AS 切换过），而 ORIGINAL_LOGIN() 始终返回最初建立连接时的实际 Windows 或 SQL 登录名——更可靠。
- 如果应用没用
EXECUTE AS，两者结果一样；一旦用了，SYSTEM_USER会变，ORIGINAL_LOGIN()不会 - 在触发器中直接写
INSERT INTO audit_log (user_name, action_time) VALUES (ORIGINAL_LOGIN(), GETDATE())是常见做法 - 注意：如果应用层用的是统一数据库账号（比如所有请求都走
app_user），那这两个函数返回的都是app_user，不是终端操作人——这时必须靠应用传参（如@current_user）或上下文字段（如CONTEXT_INFO()）补足
MySQL 触发器里拿不到真实客户端用户
MySQL 的触发器运行在服务端，USER() 和 CURRENT_USER() 都只反映连接认证信息，且受代理、连接池、中间件影响极大。比如用 PHP 的 PDO 连接，即使前端是不同用户，只要共用同一个数据库账号，USER() 就永远返回 app@10.0.1.5 这类固定值。
-
USER()返回“客户端声明的用户名@主机”，可能被伪造（如通过 MySQL 客户端指定-u） -
CURRENT_USER()返回“服务器验证通过的授权账号”，更可信但仍是连接级身份 - 想追溯到业务系统里的用户？只能让应用在 INSERT/UPDATE 时显式带上
created_by字段，触发器读这个列——别指望数据库自动识别
PostgreSQL 的 CURRENT_USER 和 SESSION_USER 区别要搞清
PostgreSQL 提供两个内置变量：CURRENT_USER 是当前执行上下文的角色（可能被 SET ROLE 切换），SESSION_USER 是连接建立时认证的角色，不可变。多数审计场景该用 SESSION_USER。
- 触发器里写
INSERT INTO logs (who, when) VALUES (SESSION_USER, NOW())更稳妥 - 如果应用用了
SECURITY DEFINER函数再调触发器，CURRENT_USER会变成函数定义者，而非调用者——这时候只有SESSION_USER能还原真实来源 - 注意：所有这些函数返回的是数据库角色名，不是应用层的 user_id 或邮箱；映射关系得靠应用自己维护
跨数据库统一方案：别依赖触发器自动取用户
真正可靠的审计，从来不是靠触发器“猜”用户，而是由应用层明确传递。数据库触发器只负责收下并存档，不负责解析或校验。
- 在 INSERT/UPDATE 语句里强制带一个
updated_by参数（如UPDATE orders SET status='shipped', updated_by='alice@company.com' WHERE id=123） - 触发器里用
NEW.updated_by（PostgreSQL / MySQL）或INSERTED.updated_by（SQL Server）取值，而不是查系统函数 - 如果字段为空，触发器应报错或记录为
'unknown'，而不是 fallback 到CURRENT_USER——模糊等于没审计
系统函数能帮你省事，但也会在权限切换、连接复用、中间件透传时悄悄失效。把用户标识当成必填业务字段来设计，比在触发器里反复调试 ORIGINAL_LOGIN() 的边界情况实在得多。
