查当前登录用户名用suser_name()，查数据库用户用current_user（不加括号），查客户端ip用sys.dm_exec_connections.client_net_address；三者语义不同，不可混用或替代。
SQL Server 存储过程中，用 SUSER_NAME() 拿登录名、CURRENT_USER 拿数据库用户、sys.dm_exec_connections.client_net_address 拿 IP —— 三者语义不同，不能混用，也不能靠 USER 或 SYSTEM_USER 替代。
怎么查当前登录用户名（Windows/SQL 账号）
用 SUSER_NAME()，它返回的是实际建立连接的登录主体，比如 'DOMAIN\alice' 或 'sa'。注意：EXECUTE AS 会覆盖它，但多数审计场景更关心原始登录者，这时该换用 ORIGINAL_LOGIN()。
-
SUSER_NAME()受EXECUTE AS影响；ORIGINAL_LOGIN()始终稳定，适合写入操作日志表 - 别用
SYSTEM_USER，它是USER_NAME()的别名，查的是当前库的数据库用户（如'db_owner'），不是登录名 - 如果存储过程跨库执行，
USER_NAME()可能返回NULL（因未在目标库映射），而SUSER_NAME()不受库上下文影响
怎么查当前会话的数据库用户名（不是登录名）
CURRENT_USER（不带括号）是正确写法，它返回当前会话在**当前数据库**中映射到的数据库用户，比如 'app_user'。它和 SUSER_NAME() 常常不同 —— 登录名可能叫 'svc_sql'，但在库 A 里被映射为 'reader'，在库 B 里是 'writer'。
- 在触发器或存储过程中做权限相关判断时，真正起作用的是
CURRENT_USER，不是SUSER_NAME() -
USER_NAME()是函数，需传 SID 参数；直接写USER_NAME()（无参）等价于USER_NAME(SUSER_SID())，但不如CURRENT_USER直观可靠 - 如果登录名没在当前库建用户，
CURRENT_USER默认返回'dbo'（不报错），这点容易误判权限边界
怎么查客户端 IP 地址（最简可靠方式）
查 sys.dm_exec_connections 视图，过滤 session_id = @@SPID：
一款AI数据处理工具，主要用于用于查询 Massive 市场数据端点的 Bash CLI 封装和 OpenClaw 技能，适用于 Codex 或 OpenClaw 代理从 shell 调用，适合需要提升相关任务效率的用户。
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id = @@SPID;
这是唯一推荐的原生方式。所有基于 xp_cmdshell + PING + HOST_NAME() 的老方案都不可靠：
-
HOST_NAME()返回的是客户端机器名，不是 IP，且常被防火墙或 DNS 配置干扰 -
xp_cmdshell需开启高危配置，多数生产环境禁用；PING结果解析极易失败（空行、超时、多网卡） -
client_net_address在连接加密（如 SSL/TLS）或代理（如 Azure SQL 网关、负载均衡）下仍有效，只是可能显示代理 IP
为什么 CURRENT_USER() 加括号就报错
因为 CURRENT_USER 是关键字，不是函数 —— 它是 ANSI SQL 标准定义的“会话级上下文值”，SQL Server 实现为无参标识符。写成 CURRENT_USER() 会被解析为调用函数，立刻报错 Incorrect syntax near '()'。
- 同理，
SESSION_USER、CURRENT_ROLE、CURRENT_DATABASE都不加括号 - 只有
SUSER_NAME()、ORIGINAL_LOGIN()、USER_NAME()这类才是真函数，必须加括号 - MySQL 的
CURRENT_USER()是函数（带括号），PostgreSQL 的CURRENT_USER不带括号 —— 跨数据库迁移时这个细节最容易翻车
真正容易被忽略的是：IP 和用户名不是原子绑定的。一个连接可能有合法 SUSER_NAME()，但 client_net_address 是 '::1'（本地回环）或 '127.0.0.1'（代理转发），此时单靠 IP 做访问控制会失效；同样，CURRENT_USER 可能被 SET ROLE 动态切换，但 SUSER_NAME() 不变。日志字段要分开存，别强行拼成一个字符串字段。
