触发器中无法精确区分程序或人工修改，只能通过app_name()、host_name()、original_login()等会话函数粗略判断；app_name()依赖连接字符串显式设置，未设置时为空；program_name()不可直接在触发器中使用；强审计需结合登录触发器或扩展事件捕获上下文。
触发器里怎么知道是程序改的还是人直接连数据库改的
不能靠 SYSTEM_USER 或 CURRENT_USER，它们只返回登录名，不管是谁发起的操作。真正可用的是连接上下文信息：比如应用程序名、主机名、客户端程序名。SQL Server 中最稳定可靠的是 APP_NAME() 和 HOST_NAME()，但要注意它们可被伪造，仅适合内部可信环境做粗略区分。
APP_NAME() 在触发器中返回什么、为什么有时为空
APP_NAME() 返回客户端连接时显式设置的 Application Name（如 SQL Server Management Studio 默认设为 Microsoft SQL Server Management Studio - Query，.NET 的 SqlConnection 可通过连接字符串加 Application Name=MyApp 设置）。如果连接没设，它就返回空字符串或 NULL。
- ADO.NET 连接字符串必须显式包含
Application Name=xxx，否则默认为空 - SSMS 会自动填，但某些轻量工具（如 DBeaver、Azure Data Studio）默认不填，需手动配置
- 触发器中直接用
APP_NAME()是安全的，无需额外权限，也不影响性能
如何用 HOST_NAME() 和 PROGRAM_NAME() 辅助判断
HOST_NAME() 返回客户端机器名（Windows 主机名），PROGRAM_NAME() 是客户端进程名（如 sqlservr.exe 表示是 SQL Agent 作业，Microsoft SQL Server Management Studio 表示 SSMS）。但注意：PROGRAM_NAME() 在 SQL Server 中并不存在——这是常见误区，实际应查 sys.dm_exec_sessions 的 program_name 字段，而触发器里无法直接 JOIN 动态管理视图。
- 触发器内唯一能直接用的会话级函数只有
APP_NAME()、HOST_NAME()、ORIGINAL_LOGIN() - 想获取更细粒度信息（如 IP、登录时间、客户端版本），得在触发器外配合登录触发器或扩展事件捕获，再写入上下文表供触发器关联查询
- 不要试图在触发器里执行
SELECT program_name FROM sys.dm_exec_sessions WHERE session_id = @@spid—— 触发器运行在语句上下文中，sys.dm_exec_sessions不保证可见且可能报权限错误
手工修改 vs 程序修改的日志记录建议
单纯靠连接属性做“非黑即白”判断风险很高。更务实的做法是：把 APP_NAME() 当作标记字段存入日志表，同时保留 HOST_NAME() 和 ORIGINAL_LOGIN()，后续靠规则组合识别异常模式（比如某台开发机频繁出现生产应用名，或某个账号从非预期主机名发起 UPDATE）。
- 日志表字段建议至少包含：
AppName、HostName、LoginName、EventTime、SqlText（需用DBCC INPUTBUFFER(@@spid)配合临时表获取） -
DBCC INPUTBUFFER有性能开销，只在审计强需求场景启用；日常校验类触发器应避免调用 - 如果业务系统已统一使用特定
Application Name，那触发器里写IF APP_NAME() NOT LIKE 'MyApp%'就能快速拦截非授权客户端
真正难处理的不是识别来源，而是当多个服务共享同一连接池、或中间件抹掉了原始 Application Name 时，上下文信息就断了。这时候得倒推，在连接建立层强制注入标识，而不是指望触发器补救。
