ORIGINAL_LOGIN() 是唯一能稳定获取 Windows 登录账号的函数，因其绑定连接建立时的原始主体，不随 EXECUTE AS、上下文切换或连接池复用而改变；其他函数如 USER()、SUSER_NAME() 等在触发器中易被覆盖或返回错误值。
ORIGINAL_LOGIN() 是唯一能稳定拿到 Windows 登录账号的函数，别试 USER()、SUSER_NAME() 或 CURRENT_USER() —— 它们在触发器里要么返回 dbo，要么被 EXECUTE AS 覆盖，要么只反映数据库映射名。
为什么 ORIGINAL_LOGIN() 才是真实登录账号
SQL Server 的登录认证发生在连接建立时，ORIGINAL_LOGIN() 绑定的就是那一刻的 Windows 主体（如 DOMAIN\alice）或 SQL 登录名。它不随后续 EXECUTE AS、上下文切换或连接池复用而改变。而：
-
USER()和CURRENT_USER()返回当前数据库用户（常是dbo），跟谁连进来无关 -
SUSER_NAME()返回当前会话的登录名，但一旦触发器前执行了EXECUTE AS，它就变成切换后的账号 -
SYSTEM_USER和SESSION_USER行为不稳定，部分场景下甚至报错
在 DML 触发器里直接用 ORIGINAL_LOGIN()
适用于 INSERT/UPDATE/DELETE 触发器，记录“谁改了数据”。必须注意：它拿的是连接发起人，不是应用层业务用户（比如中间件统一用 appsvc 连接，则所有记录都是该账号）。
- 直接赋值给变量：
DECLARE @login NVARCHAR(128) = ORIGINAL_LOGIN(); - 写入审计字段时建议组合使用：
INSERT INTO audit_log (login_name, app_name, action_time) VALUES (ORIGINAL_LOGIN(), APP_NAME(), GETDATE()); - 不要在子查询或 UDF 里调用它——可能因执行上下文偏移取错值
- 如果用了连接池（.NET 默认开启），
ORIGINAL_LOGIN()仍是每个逻辑连接的原始凭据，这点比查sys.dm_exec_sessions可靠得多
登录触发器中用 EVENTDATA() 补充客户端信息
仅靠 ORIGINAL_LOGIN() 知道“谁连”，但不知道“从哪来”。登录触发器（ON ALL SERVER FOR LOGON）可配合 EVENTDATA() 提取完整上下文：
-
EVENTDATA().value('(/EVENT_INSTANCE/LoginName)[1]', 'nvarchar(128)')和ORIGINAL_LOGIN()值一致，但需 XML 解析开销，不推荐重复取 - 真正有用的是：
EVENTDATA().value('(/EVENT_INSTANCE/ClientHost)[1]', 'nvarchar(128)')拿客户端主机名/IP，EVENTDATA().value('(/EVENT_INSTANCE/IsPooled)[1]', 'bit')判断是否来自连接池 - 注意：不能在 DML 触发器里用
EVENTDATA()，它只对 DDL 和登录事件有效 - XML 解析失败会抛异常，务必包在
BEGIN TRY...END TRY里，否则触发器失败会导致登录拒绝或 DML 失败
容易被忽略的权限与部署细节
即使语法全对，上线后也可能失效，关键点藏在权限链和部署方式里：
- 登录触发器必须用
sysadmin权限创建，且不能在master以外的库执行CREATE TRIGGER ... ON ALL SERVER - DML 触发器所在表的拥有者（schema owner）若不是
dbo，而你又没显式指定WITH EXECUTE AS 'dbo'，可能因权限不足导致触发器静默失败 - 如果应用层用了
Application Name=xxx，记得在连接字符串里设好——APP_NAME()不是自动填的，没设就是空或默认值 - Windows 组登录（如
DOMAIN\developers）在ORIGINAL_LOGIN()中返回的是组名，不是成员个人账号；真要识别具体人，得靠应用层传参或 Kerberos 代理
