suser_name()获取登录名、sys.dm_exec_connections.client_net_address获取ip是sql server唯一稳定原生方式；suser_name()返回连接时的windows/sql登录名，受execute as影响，审计需用original_login()；current_user返回当前库映射的数据库用户，与登录名常不同；client_net_address在代理或网关下仅显示最后一跳ip。
直接用 SUSER_NAME() 拿登录名、sys.dm_exec_connections.client_net_address 查 IP —— 这两个是 SQL Server 里唯一稳定、无需额外配置的原生方式。别碰 HOST_NAME() 或 xp_cmdshell，它们要么不可靠，要么被禁用。
怎么拿到真正的登录用户名（不是数据库用户）
SUSER_NAME() 返回的是连接时使用的 Windows/SQL 登录名，比如 'DOMAIN\alice' 或 'sa'；它不受当前数据库上下文影响，跨库调用也有效。但要注意：EXECUTE AS 会改变它的返回值 —— 如果你记录审计日志，想溯源最初是谁连进来的，得换用 ORIGINAL_LOGIN()。
-
CURRENT_USER（不加括号）返回的是当前数据库里的映射用户，比如'app_reader'，和登录名可能完全不同 -
SYSTEM_USER是USER_NAME()的别名，只查数据库用户，没映射时可能返回NULL或'dbo' - 如果存储过程由 SQL Server Agent 或 IIS 匿名账户调用，
SUSER_NAME()会返回NT AUTHORITY\IUSR这类代理账号，不是终端用户 —— 这时候必须靠应用层传参补充
怎么安全可靠地获取客户端 IP 地址
唯一推荐的方式是查动态管理视图：sys.dm_exec_connections，过滤 session_id = @@SPID。这个字段 client_net_address 在 SSL 加密、负载均衡、Azure SQL 网关下依然有效，只是可能显示代理 IP。
- 别用
HOST_NAME()：它返回的是客户端声明的机器名，不是 IP，且常被 DNS 或防火墙干扰 - 彻底放弃
xp_cmdshell + ping方案：需要开启高危配置，解析结果不稳定（多网卡、超时、空行），生产环境基本不可用 - 如果连接经过反向代理或云网关，
client_net_address显示的是最后一跳的 IP，不是终端真实 IP —— 这是网络架构决定的，SQL Server 本身无法穿透
MySQL 和 PostgreSQL 怎么办？不能套用 SQL Server 写法
MySQL 用 CURRENT_USER()（带括号），返回形如 'user@10.20.30.40' 的字符串，再用 SUBSTRING_INDEX(..., '@', -1) 提取 IP；PostgreSQL 里没有等价视图，pg_stat_activity 的 client_addr 字段才是真实客户端 IP，但需有 pg_read_all_stats 权限。
- MySQL 的
USER()返回连接时声明的地址（可能被代理篡改），CURRENT_USER()才反映权限系统实际匹配的账号 - PostgreSQL 的
CURRENT_USER（不加括号）是执行角色，SESSION_USER（也不加括号）才是初始登录者，两者语义不同 - Oracle 要用
SYS_CONTEXT('USERENV', 'IP_ADDRESS')，USER只返回 schema 名，完全不是一回事
真正难的不是查到值，而是理解每个函数背后代表的身份层级：登录名、数据库用户、执行角色、初始连接者 —— 审计日志写错一个，就可能把责任记到 DBA 头上。别默认 fallback，该要参数就明确要求应用传入。
