MySQL触发器可读会话变量@var_name，但需应用层显式SET；未设置、连接池复用、大小写/拼写错误、混淆USER()函数均致NULL；触发器内SET无法还原业务上下文，必须由应用在DML前统一赋值。
MySQL触发器能直接读取会话变量，但前提是应用层必须提前设置——它本身不自动继承、也不捕获任何上下文。
触发器里读@var_name失败，通常不是语法问题，而是没设值
触发器运行在当前 SQL 所属的同一会话中，所以@user_id、@trace_id这类用户变量只要在 INSERT/UPDATE 前由应用显式执行过SET @user_id = 123;，就能在触发器里直接用。但以下情况会导致读出来是NULL：
- 应用没在每次请求开头统一执行
SET @xxx（比如某次直连调试漏了） - 连接池复用了会话，上一个请求设的
@user_id被覆盖或清空了 - 触发器里写了
@USER_ID但实际设的是@user_id——MySQL 默认不区分大小写，但某些客户端或字符集配置下可能表现异常 - 变量名拼错，比如
@current_uservs@current_user_id，而应用只设了后者
USER()和CURRENT_USER()不是会话变量，别混淆
这两个函数返回的是连接认证信息，跟@开头的用户变量完全无关：
-
USER()返回'app@10.0.1.5'——这是 TCP 连接来源，常是连接池或代理 IP，不是终端程序 -
CURRENT_USER()返回'app@%'——这是权限系统匹配的账户定义，更不反映调用方 - 它们在触发器里可用，但对“谁发起这次修改”毫无意义；不能替代
@变量
为什么不能在触发器里自己SET @xxx来补救？
可以设，但没用——因为触发器无法感知原始请求的业务上下文：
- 你没法从
NEW或OLD里反推出是哪个前端用户、哪个微服务实例、哪个 API 路径发起的请求 - 即使在触发器开头写
SET @caller = 'unknown';，也只是硬编码，不是识别 - 真正可靠的方案只有一条：应用层在执行 DML 前，必须主动
SET @current_user_id = ?;并确保这个动作不被跳过
最容易被忽略的一点：没有中间件兜底时，脚本、命令行、定时任务这些非标准调用路径，几乎从不设@变量——日志里一旦出现大量NULL或unknown，先查这些地方。
