HOST_NAME()常为空或不可靠，因其依赖客户端连接方式：本地Windows认证常返回空，远程经代理/容器时返回中间节点名，且不等同系统hostname或client_net_address；APP_NAME()为空则因连接字符串未显式设置Application Name，如.NET需写Application Name=xxx，Java需applicationName=xxx，DBeaver等工具默认不填。
只能用 HOST_NAME() 和 APP_NAME()，但它们都不可靠——不是函数有问题，而是值本身依赖客户端是否如实填写。
为什么 HOST_NAME() 返回的经常是“”或空？
SQL Server 从 TCP/IP 层或共享内存连接中提取主机名，但行为不一致：
• 本地 Windows 身份验证连接（如 SSMS 用 Windows 登录）常返回 '<local machine>'</local> 或 NULL，而非真实机器名
• 远程连接若经由代理、负载均衡器或容器网络，HOST_NAME() 可能返回中间节点名（如 k8s service 名）
• 它不等于操作系统 hostname 命令结果，也不等同于 CONNECTIONPROPERTY('client_net_address')
• 不建议用于权限控制或审计归因，仅适合内部日志打标作辅助参考
APP_NAME() 为空的常见原因和修复方式
APP_NAME() 完全依赖连接字符串里是否显式声明了 Application Name 参数：
• SSMS 默认填了，所以触发器里通常能拿到 'Microsoft SQL Server Management Studio - Query'
• .NET SqlConnection 必须写成 "Server=...;Database=...;Application Name=MyApp.Web;"，漏掉 Application Name= 就返回空字符串
• Java JDBC 需加 applicationName=xxx 到连接参数，否则也是空
• DBeaver、Azure Data Studio 默认不设，需在连接配置里手动勾选/填写 Application Name
• 连接池复用时，如果第一个连接没设名，后续复用它的会话也继承空值
替代方案：什么时候该放弃触发器内获取，转而用登录触发器+上下文表？
当需要稳定记录 IP、主机名、程序名、登录时间等组合信息时，触发器内直接调用函数已到极限：
• PROGRAM_NAME() 在触发器中根本不可用（它是 sys.dm_exec_sessions.program_name 字段，触发器无法 JOIN DMV）
• CONNECTIONPROPERTY('client_net_address') 虽可用，但和 HOST_NAME() 来源不同，两者可能不一致
• 真实生产环境应搭配 LOGON 触发器，在登录瞬间把 EVENTDATA().value('(/EVENT_INSTANCE/ClientHost)[1]','NVARCHAR(128)') 和 CONNECTIONPROPERTY('client_net_address') 写入一张 session_context_log 表，并用 @@spid 关联
• 后续业务触发器再通过 SELECT TOP 1 client_host FROM session_context_log WHERE spid = @@spid ORDER BY login_time DESC 关联查询——注意必须加索引和清理策略，否则表膨胀
最易被忽略的一点：所有这些函数返回的值，都可以被客户端伪造。哪怕你看到 APP_NAME() = 'FinanceApp'，也不能证明就是财务系统改的——只要连接字符串可控，任何工具都能伪装。真要防绕过，得在应用网关层做签名或 Token 校验，而不是指望数据库端的函数返回值。
