应使用SUSER_NAME()获取登录名，它稳定返回Windows/SQL登录名（如DOMAIN\alice或sa）；SYSTEM_USER和USER_NAME()仅返回数据库用户，不可靠。
直接用 SUSER_NAME() 拿登录名，别信 SYSTEM_USER 或 USER_NAME()
绝大多数人想查“谁连进来了”，实际要的是 Windows/SQL 登录名（如 DOMAIN\alice 或 sa），SUSER_NAME() 是唯一稳定返回这个值的函数。误用 SYSTEM_USER 会踩坑——它其实是 USER_NAME() 的别名，只查当前数据库用户映射，没映射时返回 NULL 或 dbo；USER_NAME() 同理，只反映数据库级主体，和登录身份无关。
-
SUSER_NAME()返回当前安全上下文的登录名，哪怕在EXECUTE AS后也有效（但注意：它返回的是切换后的登录名） - 真要溯源最初连接者？必须用
ORIGINAL_LOGIN()，它不受任何权限切换影响 - 如果存储过程被应用层调用且未显式登录，
SUSER_NAME()可能返回代理账号（如NT SERVICE\SQLSERVERAGENT），需结合调用上下文判断
机器名必须用 HOST_NAME()，APP_NAME() 不可靠
HOST_NAME() 返回客户端连接 SQL Server 时声明的主机名，由网络栈提供，不可伪造，适合做参数化筛选或分区标识。而 APP_NAME() 完全由客户端应用程序自己填，比如 .NET 的 SqlConnection 连接字符串里加 Application Name=MyApp 才有值，不设就是空字符串或默认名（如 .Net SqlClient Data Provider），不能用于鉴权或审计。
-
HOST_NAME()在合并复制中是合法参数化筛选函数，可直接写进WHERE子句（如WHERE ClientHost = HOST_NAME()） - 该函数返回值长度上限为 128 字符，超长会被截断，生产环境建议提前
LEFT(HOST_NAME(), 128)处理 - 某些云数据库网关或连接池中间件可能覆盖原始主机名，此时
HOST_NAME()反映的是中间件机器名，不是终端用户机器
合并复制场景下，SUSER_SNAME() 和 HOST_NAME() 必须成对使用
参数化行筛选器只认这两个系统函数（或包装它们的 UDF），其他自定义逻辑一律无效。发布端定义筛选时若写死字符串（如 WHERE LoginID = 'alice'），就退化成静态筛选，无法支持多订阅者动态分区。
- 筛选子句必须是两段式对象名，例如
[Schema].[Table]，禁用三段式（如db.schema.table） - UDF 包装时，函数体内只能调用
SUSER_SNAME()或HOST_NAME()，不能传参，也不能嵌套其他函数（如UPPER(SUSER_SNAME())会报错） - 测试时务必用真实订阅账号执行，因为
SUSER_SNAME()在合并代理连接发布服务器时才取到订阅者登录名，开发机本地 EXEC 不等于订阅上下文
审计敏感操作时，用户名+机器名要分开存，别拼成一个字段
把 SUSER_NAME() 和 HOST_NAME() 的结果硬拼成字符串（如 SUSER_NAME() + '@' + HOST_NAME()）看似省事，但后续查问题时无法单独索引或过滤。更糟的是，如果某天需要区分“同机器不同用户”或“同用户不同机器”，字段结构就废了。
- 审计表至少保留三列：
login_name NVARCHAR(128)、host_name NVARCHAR(128)、app_name NVARCHAR(128)（补足可信度） - 触发器里取值优先用
ORIGINAL_LOGIN()+HOST_NAME()，避免EXECUTE AS导致身份漂移 - 注意
HOST_NAME()在远程连接下可能为空（尤其 ODBC 驱动旧版本），应加ISNULL(HOST_NAME(), 'unknown')防 NULL
