USER() 和 CURRENT_USER() 仅返回授权账号和主机模式（如 'appuser@10.20.30.%'），无法获取客户端真实 IP；真实 IP 必须由应用层解析 REMOTE_ADDR 或 X-Forwarded-For 后显式传入字段，再在触发器中引用 NEW.client_ip。
USER() 只能拿到「连接用户@主机名」，不是客户端真实 IP，更不是跳板机或代理后的真实来源。想靠它记录操作者 IP，基本不可行。
为什么 USER() 和 CURRENT_USER() 都不能用
这两个函数返回的是 MySQL 认证时的账号和授权主机，例如 'appuser@10.20.30.%' 或 'admin@localhost'。它反映的是授权范围，不是当前连接发起的实际网络地址。即使客户端是 192.168.1.100，只要授权允许从 10.20.30.0/24 连入，USER() 就永远只显示那个通配符模式。
- 在中间有跳板机、ProxySQL、HAProxy、云数据库代理（如阿里云 RDS 的 proxy 层）时，
HOST部分几乎总是内网地址或'%' -
CURRENT_USER()更严格，只返回权限系统匹配到的账户定义，连通配符都不展开，实际值往往比USER()还“假” - 触发器里调用它们，结果和你在客户端执行
SELECT USER();完全一致——和请求来源无关
真正可用的 IP 来源只有应用层传入
MySQL 本身不解析 HTTP 头、不读取 TCP 包原始源地址（除非启用 performance_schema 并开启连接采集，但那不是触发器能访问的）。唯一可控、可信赖的方式，是让应用在写入业务表时，把 REMOTE_ADDR 或 X-Forwarded-For 解析后的 IP 作为字段一并插入。
- 比如业务表
users加一列client_ip VARCHAR(45)，应用代码中显式赋值：INSERT INTO users (name, email, client_ip) VALUES ('a', 'b', '203.0.113.42'); - 触发器里就可以安全引用
NEW.client_ip—— 它是确定写入的值，不会被 MySQL 自动替换或模糊化 - 如果担心应用绕过，可在触发器开头加校验：
IF NEW.client_ip IS NULL OR NEW.client_ip = '' THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'client_ip is required'; END IF;
INFORMATION_SCHEMA.PROCESSLIST 不适合在触发器里查
虽然 PROCESSLIST 的 HOST 列有时看起来像真实 IP，但它不稳定、不可靠，且在触发器中直接查询会引发并发问题。
- 触发器执行期间，
PROCESSLIST可能已刷新，HOST值可能为空、为'localhost'或为中间节点地址 - 游标遍历
PROCESSLIST是重操作，容易锁表或拖慢事务；MySQL 8.0+ 还默认禁用对PROCESSLIST的非 SUPER 权限查询 - 你看到的示例里用
_ipCursor拼接多个连接记录，逻辑本身就是错的——一个触发器只对应一个语句，不该去扫全局连接列表
替代方案：用 general_log 或审计插件捕获源头 IP
如果非要服务端自动记录（不依赖应用改字段），就得跳出触发器思路：
- 开启
general_log并设为表格式：SET GLOBAL log_output = 'TABLE'; SET GLOBAL general_log = ON;，然后查mysql.general_log表里的argument字段——但里面没有 IP，只有 SQL 文本 - 启用 MySQL 企业版审计插件或 Percona Server 的
audit_log，它能记录host字段（来自 TCP 连接的 peer 地址），但需额外配置且不进触发器上下文 - 最务实的做法：在连接池或 API 网关层统一注入
SET @client_ip = 'xxx';，再在触发器里读@client_ip变量——前提是应用配合执行这条 SET
触发器里硬要“自动”拿真实 IP，本质是把应用层该做的事塞给数据库，结果不是不准，就是不稳，还容易埋下性能雷。IP 必须由可信入口明确传入，而不是靠数据库猜。
