SQL Server触发器无法直接识别INSERT语句编写者，仅能通过APP_NAME()、HOST_NAME()、ORIGINAL_LOGIN()获取上下文信息；APP_NAME()依赖连接字符串显式设置，未设置则为空；HOST_NAME()和ORIGINAL_LOGIN()可辅助判断执行来源；追溯具体存储过程需调用方透传SESSION_CONTEXT，而非依赖触发器内查会话视图或DBCC命令。
SQL Server 触发器本身无法直接识别“谁写的 INSERT 语句”，只能拿到连接层声明的上下文信息——APP_NAME()、HOST_NAME()、ORIGINAL_LOGIN() 这三个函数是触发器内唯一能安全、直接调用的来源标识手段。
APP_NAME() 返回什么？为什么经常为空？
APP_NAME() 只返回连接字符串里显式设置的 Application Name 值，不是程序自动上报的。没设，它就返回空字符串或 NULL，不是“检测失败”，而是根本没提供。
- .NET 应用必须在连接字符串中写明：
Application Name=OrderService；用SqlConnection.ConnectionString动态改不生效（该属性只读） - Java/JDBC 需在 URL 中加：
applicationName=InventoryService，例如jdbc:sqlserver://localhost;applicationName=InventoryService - SSMS 默认填了
Microsoft SQL Server Management Studio - Query，但 DBeaver、Azure Data Studio 默认不填，需手动配置连接属性 - Spring Boot + HikariCP 场景下，
connection-init-sql=SET APPLICATION_NAME TO 'xxx'是备选，但不如 URL 参数稳定，且可能被连接池复用污染
HOST_NAME() 和 ORIGINAL_LOGIN() 怎么辅助判断？
HOST_NAME() 返回客户端机器名（Windows 主机名），ORIGINAL_LOGIN() 返回最初登录的账号（不受 EXECUTE AS 影响）。它们不能单独定性“程序 or 手工”，但组合起来有参考价值：
- 开发机名 + 生产应用名 → 可能是测试环境误连生产库
- 运维账号 + SSMS 默认
APP_NAME()→ 很可能是人工执行 - 同一主机名频繁切换不同
APP_NAME()→ 可能是共享连接池未隔离上下文 - 不要尝试在触发器里查
sys.dm_exec_sessions或PROGRAM_NAME()—— 后者根本不存在于触发器可用函数列表，前者权限不可靠且会话视图不一定可见
想追溯到具体存储过程？别在触发器里硬刚
触发器响应的是 DML 事件，不是函数调用栈。即使 INSERT 语句写在 sp_update_order 里，触发器也拿不到这个过程名——@@PROCID 指向触发器自己，OBJECT_NAME(@@PROCID) 返回的是触发器名。
- 可靠方案：调用方主动透传，比如在存储过程中先执行
sp_set_session_context @key = N'caller_proc', @value = N'sp_update_order'，触发器里用SESSION_CONTEXT(N'caller_proc')读取 - 临时排查：用 Extended Events 抓
sql_batch_completed事件，配合session_id关联触发行为，比在触发器里塞DBCC INPUTBUFFER更安全稳定 - 避免踩坑：不要在触发器里执行
DBCC INPUTBUFFER(@@SPID)—— 它返回的是当前批处理的原始语句，但触发器运行时上下文已变，结果不可靠，且性能开销明显
真正难的从来不是写那行 APP_NAME()，而是让每个连接都真实、稳定、可追溯地携带业务归属信息。连接池复用、中间件覆盖、工具默认不设值——这些才是源头问题，函数只是照镜子的人。
