数据库触发器无法直接获取真实业务用户，需应用层透传用户标识（如会话变量、自定义配置、CONTEXT_INFO等），数据库侧配合读取，所有方案均依赖应用主动设置，无自动识别能力。MySQL 触发器里拿不到 USER() 或 CURRENT_USER() 的真实操作人？默认情况下，触发器内调用 USER() 返回的是连接池账号（比如 app@10.0.0.5），CURRENT_USER() 返回的是认证账号（比如 app@%），都不是发起 SQL 的具体业务用户。真要记录“谁改的”，得靠应用层透传 + 数据库侧配合。数据库本身不保存 HTTP 请求头、JWT 用户 ID 或 session ID，触发器无法凭空知道前端登录态如果应用用统一中间件或 ORM（如 MyBatis、Sequelize），可在执行 SQL 前显式设置会话变量，比如 SET @current_user_id = 12345;触发器中必须用 @current_user_id 这种用户变量，不能用 SYSTEM_USER() 或 SESSION_USER() —— 它们和 USER() 本质一样，反映的是连接身份，不是业务身份注意变量作用域：每个连接独立，不会跨连接污染，但需确保每次请求都重设，否则可能残留上一个用户的值PostgreSQL 怎么在触发器里拿到应用传来的用户名？PostgreSQL 更灵活，支持通过 current_setting('app.user_id', true) 读取自定义配置项，前提是应用在事务开始前调用 SET app.user_id = 'u_789';。必须提前用 ALTER DATABASE xxx SET app.user_id = ''; 或在 postgresql.conf 中声明该配置项，否则 current_setting 会报错 “unrecognized configuration parameter”第二个参数 true 表示“找不到时不报错，返回 NULL”，建议始终带上，避免触发器因配置缺失而中断 DML触发器函数里别直接写死 current_setting('app.user_id')，先判空：COALESCE(current_setting('app.user_id', true), 'unknown')这个机制依赖应用主动 SET，如果某条 SQL 漏了（比如直连调试、脚本执行），就只能记成 unknown —— 日志里看到大量 unknown，大概率是客户端没统一处理SQL Server 触发器怎么安全获取修改人？慎用 ORIGINAL_LOGIN()ORIGINAL_LOGIN() 看起来像答案，但它返回的是最初建立连接的 Windows / SQL 登录名，不是当前 EXECUTE AS 用户，更不是 Web 应用里的 userId。真要用，得配合上下文切换。 There’s An AI For That 全球领先的 AI 聚合器，收集10,225个AI工具，可用于超过2,548个任务。