优先用CURRENT_USER：它返回权限生效的授权身份，用于审计、RLS和动态脱敏；USER返回登录认证身份，仅适用于记录连接来源。跨库需注意括号规则——MySQL/SQL Server需加()，PostgreSQL/Oracle不加。
SQL里用 USER 还是 CURRENT_USER？先看实际返回值差异
两者都返回当前会话的用户标识，但含义和行为完全不同：USER 是登录时使用的用户名（即认证身份），CURRENT_USER 是权限系统生效的用户（即授权身份）。在普通直连场景下它们通常一样，但一旦涉及代理用户、角色切换或数据库代理（如 MySQL 的 SET ROLE、Oracle 的 proxy user、PostgreSQL 的 SET SESSION AUTHORIZATION），就会分道扬镳。
实操建议：
- 查“谁连进来了”——用
USER - 查“当前语句以哪个身份执行、能访问哪些对象”——必须用
CURRENT_USER - 写审计日志或权限校验逻辑时，优先选
CURRENT_USER，否则可能绕过权限检查
MySQL 中 CURRENT_USER() 带括号，而 USER() 也带括号，但 PostgreSQL 不同
MySQL 要求两个函数都加括号：CURRENT_USER() 和 USER()；少括号会报错 ERROR 1305 (42000): FUNCTION db.CURRENT_USER does not exist。PostgreSQL 则相反：CURRENT_USER 是关键字，不带括号；加括号反而语法错误。而 USER 在 PostgreSQL 中是 CURRENT_USER 的同义词，也不带括号。
常见踩坑点：
- 跨数据库迁移 SQL 时硬套 MySQL 写法到 PG，
CURRENT_USER()直接报错 - 在 MySQL 存储过程中误写成
CURRENT_USER（无括号），触发隐式类型转换，返回空字符串而非报错，极难排查 - SQL Server 没有这两个函数，对应的是
SUSER_NAME()和USER_NAME()，别混用
权限上下文变化时，CURRENT_USER 会实时更新，USER 不会
比如在 MySQL 8.0+ 中执行 SET ROLE 'analyst'; 后，CURRENT_USER() 返回 'analyst'@'%'（如果该角色被映射为一个可认证用户），而 USER() 仍保持原始登录名，如 'alice'@'192.168.1.100'。PostgreSQL 中执行 SET SESSION AUTHORIZATION bob; 后效果类似。
这意味着：
- 用
CURRENT_USER做行级安全策略（RLS）条件时，能准确反映当前权限边界 - 用
USER做审计字段记录操作人，更符合“谁发起请求”的业务语义 - 不要在触发器中仅靠
CURRENT_USER判断是否允许修改，需结合SESSION_USER或应用层透传信息综合判断
SQL 标准只定义了 CURRENT_USER，USER 是各厂商扩展
CURRENT_USER 是 SQL:2003 标准关键词，在 MySQL、PostgreSQL、SQL Server、Oracle 中行为基本一致（除括号规则外）。而 USER 并非标准函数：MySQL 和 PostgreSQL 支持它作为 CURRENT_USER 的别名；SQL Server 中 USER 等价于 USER_NAME()（返回数据库用户名，不是登录名）；Oracle 根本不支持 USER 函数，只认 USER 伪列（等价于 USERENV('SESSION_USER')）。
所以如果你写的 SQL 需要跨平台兼容：
- 优先使用
CURRENT_USER（注意括号规则） - 避免依赖
USER，尤其不要假设它和CURRENT_USER总是相等 - 在 Oracle 中若需登录名，得用
SYS_CONTEXT('USERENV', 'SESSION_USER')，不是USER
最易被忽略的一点：很多 ORM 框架（如 Django 的 extra()、MyBatis 的 ${}）会直接拼接 SQL 字符串，若开发者没意识到不同数据库对 CURRENT_USER 的括号要求，生成的语句可能在某个环境跑通、另一个环境静默失败。
