Redis ACL GETUSER 怎么查看用户实际生效的权限

你可以直接在Redis命令行执行`ACL GETUSER 对应用户名`，得到的返回内容就是该用户当前实际生效的全量权限配置，不需要额外去比对服务端的ACL配置文件做校验。

ACL GETUSER 命令返回的权限结果会覆盖配置文件里的默认规则、运行时动态调整的权限设置，是用户当前连接后真正能使用的权限范围，直接读取返回值即可拿到准确结果。

Redis 权限排查时，先不要只看客户端返回的“权限不足”。用 ACL GETUSER 用户名 读取用户当前的状态、命令规则和 key pattern，再用 ACL LIST 对照完整规则串，通常能很快判断问题是在用户配置、key 范围，还是连接仍沿用旧的认证状态。

官方文档：https://redis.io/docs/latest/commands/acl-getuser/

先读懂 ACL GETUSER 的返回结构

ACL GETUSER 的参数只有用户名，返回的是 Redis 为该用户保存的 ACL 规则摘要。常见字段可以按“状态、密码、命令、键、频道”五个层次阅读：

用命令和 key pattern 分开判断

下面的命令用于展示最小检查方式。代码块中的返回内容是说明格式，重点是观察字段，不把它当作某个实例的运行截图。

# 读取指定用户的 ACL 规则摘要；需要具备管理权限
redis-cli ACL GETUSER app_reader

# 用 ACL LIST 查看同一用户展开后的规则串
redis-cli ACL LIST | grep '^user app_reader '

如果结果中出现 commands 的 +@read，它表示允许读命令类别；若同时有 -get，还要结合规则顺序判断最终效果。Redis ACL 规则按从左到右处理，因此不能只截取一段规则就下结论。

再看 keys：~app:* 允许匹配以 app: 开头的 key，~cache:* 则是另一段范围。即使命令类别允许 GET，访问不匹配的 key 仍可能被拒绝；反过来也一样，key 匹配并不自动授予命令权限。

用 ACL LIST 对照规则与连接边界

当 GETUSER 看起来正确而业务仍报权限错误时，按下面顺序缩小范围：

1. 确认应用实际连接的用户名，不要把 default 用户的结果当成业务用户。
2. 对照 commands 与 keys，分别确认命令和 key 是否都命中。
3. 用 ACL LIST 查看完整规则串，检查是否存在后置的排除规则。
4. 让测试客户端断开并重新 AUTH username password，再做一次最小命令验证。

特别要注意 off：它阻止新的认证，但 Redis 文档明确说明，已经认证的连接仍可能继续工作。因此“GETUSER 已显示 off，但旧连接还能读到数据”并不矛盾。排查权限变更时，连接生命周期必须和 ACL 配置一起记录。

常见问题

ACL GETUSER 能看到用户实际拥有的 key 吗？

不能。它返回的是 key pattern，例如 ~app:*，用于表达允许匹配的范围；具体 key 是否存在需要另行查询，而且查询本身也受权限限制。

为什么有 +@read 仍然执行不了 GET？

先检查是否有排除规则，再检查目标 key 是否匹配 keys 中的 pattern。命令类别和 key 范围缺一不可。

修改 ACL SETUSER 后是否需要重启 Redis？

通常不需要重启，但应让客户端重新认证并重新检查。若只复用旧连接，可能观察到修改前的连接行为。

实际操作可以把 ACL GETUSER 当作快速读数，把 ACL LIST 当作规则对照表，再把“新连接重新认证”作为最终确认动作。这样既能保留最小权限边界，也不会把密码、命令和 key pattern 混成一个问题。