SQL Server触发器无法获取客户端MAC地址，因该信息不被记录且网络层已不可见；可靠方式是应用层传入client_hostname或IP等标识。
SQL Server 触发器中无法直接获取客户端 MAC 地址
SQL Server 的触发器运行在服务端，sys.dm_exec_sessions 和 sys.dm_exec_connections 可查到部分连接信息，但 **MAC 地址不会被 SQL Server 记录或暴露**。网络层的 MAC 地址在经过路由器、NAT、代理或负载均衡后已不可见，且 SQL Server 本身不解析或存储该字段。
常见误操作是尝试用 NET_ADAPTERS 或调用 xp_cmdshell 执行 ipconfig /all —— 这不仅失败（权限/安全策略拦截），而且返回的是服务器本机网卡信息，不是客户端的。
- 不要依赖
HOST_NAME()或APP_NAME()推断客户端物理位置 - 避免在触发器中调用扩展存储过程获取网络信息，风险高、不可靠、违反最小权限原则
- 若业务强依赖客户端标识，应在应用层主动传入（如通过
CONTEXT_INFO或新增审计字段）
SQL Server 中可用的客户端主机名获取方式（有限但稳定）
HOST_NAME() 函数返回的是客户端应用程序调用时设置的主机名，但它可被任意伪造（例如 ADO.NET 中设置 Workstation ID 连接字符串参数），并非操作系统真实主机名。
更可靠的来源是 sys.dm_exec_sessions 动态管理视图，需在触发器中 JOIN 当前会话 ID：
SELECT client_hostname FROM sys.dm_exec_sessions WHERE session_id = @@SPID;
注意：
- 该值依赖客户端是否如实上报；Java（JDBC）默认为空，.NET 默认为机器名，Python pyodbc 需显式设
WSID=xxx - 若连接池复用或中间件（如 IIS、Tomcat）转发，
client_hostname往往是中间层主机名 - 触发器内不能直接用子查询引用 DMV 做 SET 操作（如
SET @host = (SELECT ...)），需用 SELECT INTO 或 JOIN 方式
PostgreSQL 触发器中如何拿到客户端 IP 和主机名
PostgreSQL 提供 inet_client_addr() 和 inet_client_hostname()，可在触发器函数中直接调用：
CREATE OR REPLACE FUNCTION log_client_info() RETURNS TRIGGER AS $$ BEGIN INSERT INTO audit_log(ip, hostname, op, tbl) VALUES (inet_client_addr(), inet_client_hostname(), TG_OP, TG_TABLE_NAME); RETURN NEW; END; $$ LANGUAGE plpgsql;
但要注意：
-
inet_client_hostname()依赖反向 DNS 解析，若 DNS 不配置或超时，返回 NULL 或 IP 字符串 - 若客户端经代理（如 pgbouncer、HAProxy），
inet_client_addr()返回的是代理 IP，需配合proxy_protocol或自定义 GUC 参数传递原始 IP - 无内置函数获取 MAC 地址；同样不可行
替代方案：让应用层负责传递可信终端标识
真正可控的方式，是把主机标识逻辑前置到应用层，并通过上下文或数据字段带入数据库：
- SQL Server：使用
SET CONTEXT_INFO在事务开始时写入客户端信息，触发器中用CONTEXT_INFO()读取（需注意字节长度限制和二进制转换） - 所有数据库：在 DML 的 INSERT/UPDATE 语句中显式写入
client_hostname、client_ip等审计列（推荐，语义清晰、可索引、不依赖运行时环境） - 若用 ORM（如 Entity Framework、Django ORM），可在 save() 前自动注入
created_by_host字段，比触发器更可靠
绕过触发器去“猜”客户端硬件信息，本质上是在弥补架构设计的缺失——网络边界早已模糊，唯一能信的，是应用自己声明的东西。
