APP_NAME() 仅返回连接字符串中声明的应用名，未声明则为空或默认值；须在AFTER触发器中直接调用，不可嵌套或间接引用；.NET/Java需显式配置Application Name，连接池复用易致值污染。
不能直接“准确判断”，但可以用 APP_NAME() 拿到客户端声明的应用名——前提是连接字符串里真写了 Application Name，否则它就返回空、默认值，或被连接池污染的假名。
APP_NAME() 在触发器里怎么调用才有效
它必须在 AFTER INSERT、AFTER UPDATE、AFTER DELETE 触发器主体内直接读取，不能缓存、不能间接引用，也不能放在子查询或函数里。
- 正确写法：
DECLARE @app NVARCHAR(128) = APP_NAME();紧跟在BEGIN后面立即执行 - 错误写法：在
INSTEAD OF触发器中先做INSERT再查APP_NAME()—— 此时会话上下文可能已变 - 错误写法：把
APP_NAME()放进INSERT INTO ... SELECT的子查询中，嵌套触发器下容易拿到错的值 - 错误写法：在自定义函数或视图里调用它并用于触发器逻辑 —— 会报错或返回 SSMS 这类默认名
.NET 和 Java 应用必须显式传 Application Name
SQL Server 不会自动识别程序来源，它只原样返回连接初始化时客户端声明的名称。没声明，APP_NAME() 就是空的。
- .NET：连接字符串必须含
Application Name=MyOrderService；用SqlConnection.ConnectionString动态拼接后不生效，因为该属性是只读的 - Java（JDBC）：URL 中必须加
applicationName=InventoryService，例如jdbc:sqlserver://;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 参数稳定
为什么 APP_NAME() 经常返回空、重复或奇怪的值
根本问题不在函数本身，而在连接生命周期管理机制破坏了“一次连接 = 一次业务归属”的假设。
- 连接池复用：同一个物理连接被多个请求复用，
APP_NAME()可能残留上一个请求的值 - 中间件/代理转发：如 SQL Server Agent、某些 ORM 或网关会覆盖原始连接属性
- 未设置或设错：很多开发环境默认不设
Application Name，导致触发器里看到的是空或.Net SqlClient Data Provider - 权限与可见性无问题：
APP_NAME()是标量函数，无需额外权限，也不影响性能，但它不是审计级证据
真正难的不是怎么写那行 APP_NAME()，而是让每个连接都真实、稳定、可追溯地带上业务标识——这需要从连接初始化、连接池配置、中间件透传全链路对齐，而不是只靠触发器里一句话解决。
