SQL Server 触发器中唯一稳定获取客户端IP的方式是CONNECTIONPROPERTY('client_net_address')，需在开头立即读取；PostgreSQL需查pg_stat_activity但有竞态和代理遮蔽风险；MySQL触发器无法获取真实客户端IP，必须由应用层传入。
SQL Server 触发器中必须用 CONNECTIONPROPERTY('client_net_address')
这是唯一能在触发器内稳定拿到 TCP 层客户端 IP 的方式，HOST_NAME() 不可靠（只返回主机名，可能为空或被伪造），USER() 和 CURRENT_USER() 返回的是登录名+认证主机（如 app_user@10.20.30.40），但该地址来自登录握手阶段，DNS 可能已解析覆盖，且无法区分通配符配置（如 app_user@%）。
关键点：
-
CONNECTIONPROPERTY('client_net_address')在会话级有效，必须在触发器开头立即读取，延迟调用可能因连接重用而失效 - 返回值是
NVARCHAR(45)，支持 IPv6，需用IN或=比较，不能用模糊匹配 - 在 Always On、镜像、AG 环境下仍返回原始连接发起方 IP，不受故障转移影响
- 无需额外权限，但触发器执行者需有
EXECUTE权限；在 contained database 中若无登录映射，可能返回NULL
PostgreSQL 触发器里得查 pg_stat_activity，但有竞态风险
PostgreSQL 没有内置触发器上下文函数，只能通过 pg_stat_activity 关联当前后端进程 ID 获取 IP：
SELECT client_addr FROM pg_stat_activity WHERE pid = pg_backend_pid();
这个查询本质是查系统视图，不是实时上下文，存在两个硬伤：
- 如果连接走 pgbouncer（transaction pool 模式）或 SSL 代理，
client_addr显示的是代理地址，不是真实客户端 - 高并发写入时，
pg_stat_activity记录可能在触发器执行间隙被清理或覆盖，导致查不到或查错 - 普通用户默认无权访问
pg_stat_activity，必须用SECURITY DEFINER函数封装，且 DBA 需显式授权 - 建议高频场景下改用会话变量缓存：
SET LOCAL app.client_ip = '1.2.3.4';，再在触发器中读取
MySQL 触发器根本拿不到真实客户端 IP
MySQL 触发器完全不暴露网络层信息。USER() 和 CURRENT_USER() 返回的主机部分（如 'app@192.168.1.100'）仅来自认证阶段，受 skip_name_resolve 配置和 DNS 解析影响极大，不可信。
常见误操作及后果：
- 用
SUBSTRING_INDEX(USER(), '@', -1)提取 IP：一旦 MySQL 启用了 DNS 解析或配置了通配符主机（app@%），结果就是%或空字符串 - 依赖
INFORMATION_SCHEMA.PROCESSLIST：该表在 8.0+ 已弃用，且普通用户无权查询 - 试图在触发器里调用 UDF 或外部命令：违反事务原子性，且多数生产环境禁用
唯一可行路径是应用层显式传入：INSERT INTO logs (data, client_ip) VALUES ('x', '1.2.3.4');
所有数据库都绕不开“中间层遮蔽”这个现实
无论用哪种方式，只要请求经过连接池（如 .NET SqlConnection）、Web 应用服务器、负载均衡器或反向代理，你拿到的就不是最终用户 IP，而是中间设备的出口地址。
这意味着：
- SQL Server 的
client_net_address显示的是应用服务器 IP，不是浏览器 IP - PostgreSQL 的
client_addr在 Nginx + pgbouncer 架构下恒为127.0.0.1 - Oracle 的
sys_context('USERENV', 'IP_ADDRESS')在 F5 或 AWS ALB 后也失真
真正要绑定“谁改了数据”，不能只靠数据库层。必须由应用在每次写入时，把可信 IP 作为字段值或会话变量传入，并在触发器里校验该字段非空——触发器只做守门员，不做侦探。
