应优先使用CURRENT_USER——它返回实际生效的授权主体，USER（或SESSION_USER）仅返回连接时声明的用户名，二者在权限切换或代理连接时可能不同，审计、RLS等场景必须依赖前者。

SQL里用USER还是CURRENT_USER查当前用户名？

多数情况下，CURRENT_USER更可靠——它返回的是**实际用于认证的用户身份**，而USER（或SESSION_USER）返回的是**连接时声明的用户名**，两者在权限切换（如MySQL的SET ROLE、PostgreSQL的SET SESSION AUTHORIZATION）或代理连接场景下可能不同。

MySQL中两者的实际差异

MySQL里USER()和CURRENT_USER()都是函数，括号不能省；它们返回字符串，但语义不同：

• USER()：返回「客户端声明的用户名@主机名」，哪怕你用root连上来后又SET ROLE 'app_user'，它仍显示root@localhost
• CURRENT_USER()：返回「服务器当前生效的授权主体」，上例中会变成app_user@%（取决于角色定义）
• 如果没做任何角色切换，二者通常一致，但不能依赖这种一致性

PostgreSQL和SQL Server的对应写法

不同数据库语法不统一，别硬套MySQL习惯：

• PostgreSQL：用CURRENT_USER（不带括号，是关键字），SESSION_USER等价于MySQL的USER()；USER是SESSION_USER的同义词，不推荐用
• SQL Server：用SYSTEM_USER或ORIGINAL_LOGIN()——前者类似USER()，后者才接近CURRENT_USER()语义
• Oracle：用USER（不带括号，是预定义变量），它等价于CURRENT_USER，没有独立的USER()函数

为什么生产环境必须优先用CURRENT_USER？

审计日志、行级安全策略（RLS）、动态数据脱敏都依赖「当前实际执行权限主体」，而不是连接时填的那个名字：

• MySQL开启activate_all_roles_on_login=ON后，USER()可能长期固定为DBA账号，但业务逻辑已按角色权限运行
• PostgreSQL的RLS策略里写user = CURRENT_USER才能正确过滤，写user = SESSION_USER会导致越权
• ORM（如Django、SQLAlchemy）底层连接池复用时，USER()可能返回连接池初始化时的用户，而非当前请求上下文

真正难的不是记住哪个函数名，而是意识到：数据库里的「用户」从来不是静态字符串，而是会随权限上下文流动的身份标识。