app_name()能获取客户端声明的应用名，但仅当连接字符串显式设置application name参数时有效；未设置则返回空、默认值或被连接池/代理污染的假名，且必须在after触发器主体内直接调用才可靠。

APP_NAME() 可以拿到客户端声明的应用名，但不是“自动识别程序来源”，它只返回连接字符串里 Application Name 参数的值；没设就是空、默认值，或被连接池/代理污染后的假名。

APP_NAME() 在触发器里怎么写才有效

必须在 AFTER INSERT、AFTER UPDATE、AFTER DELETE 触发器主体内直接调用，不能缓存、不能间接引用。

• 正确：用 DECLARE @app NVARCHAR(128) = APP_NAME(); 立即赋值，再插入日志表
• 错误：在 INSTEAD OF 触发器里先执行 DML 再查 APP_NAME() —— 此时会话上下文可能已变
• 错误：把 APP_NAME() 放进 INSERT INTO ... SELECT 的子查询中，尤其当目标表有嵌套触发器时，容易拿到错的会话名
• 错误：在函数或视图里调用 APP_NAME() 并用于触发器逻辑 —— 会报错或返回会话默认名（如 Microsoft SQL Server Management Studio）

Java 和 .NET 应用怎么传真实应用名

客户端不主动声明，SQL Server 就永远拿不到。关键不是函数怎么写，而是连接初始化时有没有带标识。

• Java JDBC URL 必须显式加 applicationName=xxx，例如：jdbc:sqlserver://localhost;databaseName=test;applicationName=InventoryService
• .NET 的 SqlConnection 连接字符串必须含 Application Name=xxx，不能靠代码拼接后忽略该字段 —— ConnectionString 属性是只读的，改了也不生效
• SSMS、sqlcmd 默认不带 Application Name，直接执行触发器看到的是 Microsoft SQL Server Management Studio 或空字符串
• Spring Boot + HikariCP 场景下，需在 datasource.hikari.connection-init-sql 里额外执行 SET APPLICATION_NAME TO 'xxx'（部分驱动支持），但不如 URL 参数可靠

为什么 APP_NAME() 经常返回空、重复或奇怪的值

根本问题不在函数本身，而在连接生命周期管理机制破坏了“一次连接 = 一次业务归属”的假设。

• 连接池复用：第二次请求复用第一次的物理连接，APP_NAME() 仍返回首次登录时的值，和当前业务无关
• 数据库代理（如 ProxySQL、AG 监听器）可能剥离或重写连接属性，后端 SQL Server 收不到原始 Application Name
• ORM 框架（如 Entity Framework、MyBatis）若未配置透传，会在连接层覆盖或丢弃该参数
• 某些中间件（如 Apache ShardingSphere）会统一使用固定连接池名，所有请求都显示为同一个 APP_NAME()

比 APP_NAME() 更靠谱的替代方案有哪些

如果审计日志要精准归因到接口、服务实例甚至用户操作上下文，单靠 APP_NAME() 不够稳定，得结合其他手段补全。

• 在业务层显式写入上下文字段：比如在修改数据前，用 SET CONTEXT_INFO 存入服务名+traceId，触发器里用 CONTEXT_INFO() 读取
• 用扩展事件（Extended Events）捕获 sql_batch_completed 或 rpc_completed 事件，自带 client_app_name 字段，且不受连接池影响
• 对关键表启用变更数据捕获（CDC）或临时表审计，把应用层传入的 modified_by 字段作为必填项，绕过服务端识别难题
• 在网关或 API 层注入唯一请求 ID，并通过 sp_set_session_context 注入会话变量，触发器中读 SESSION_CONTEXT(N'modified_by')

真正难的不是“怎么拿到名字”，而是名字背后代表的语义是否可信 —— 连接池、代理、ORM 都可能让一个看似干净的 APP_NAME() 实际上失去业务粒度。如果日志要用于追责或合规审计，建议至少叠加一层业务侧可控的标识。