数据库触发器无法直接获取真实业务用户需应用层透传用户标识如会话变量、自定义配置、CONTEXT_INFO等数据库侧配合读取所有方案均依赖应用主动设置无自动识别能力。MySQL 触发器里拿不到 USER() 或 CURRENT_USER() 的真实操作人默认情况下触发器内调用 USER() 返回的是连接池账号比如 app10.0.0.5CURRENT_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个任务。