Redis ACL SETUSER 的 reset 和追加规则有什么区别

如果你对同一个 Redis 用户连续执行两次 ACL SETUSER，第二次并不会自动把第一次的命令权限和 key 模式覆盖掉。对已有用户来说，普通规则默认是追加；只有把 reset 放在规则列表开头，才会先清掉原有能力，再按同一条命令后面的规则重新声明。

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

把 ACL SETUSER user +get 理解为“在现有权限上加一条”，把 ACL SETUSER user reset on +get ~report:* 理解为“清空后重建一份完整权限”。两者的风险和适用场景完全不同。

问题现场：第二次 SETUSER 为什么没有删掉旧权限

常见现象是脚本第一次给用户授予 +get 和 ~report:*，第二次只写了 +set 和 ~job:*，但用户最后仍然可以读取报表。原因不是 Redis 忽略了第二次命令，而是 ACL SETUSER 的默认动作就是把新规则应用到已有规则上。

因此，下面两条命令表达的是两次增量变更，而不是第二条替换第一条：

# 第一次：为已有或新建用户增加读取能力和报表 key 范围
redis-cli ACL SETUSER report-reader '+get' '~report:*'

# 第二次：继续增加写入能力和任务 key 范围，旧规则仍然保留
redis-cli ACL SETUSER report-reader '+set' '~job:*'

如果业务想表达“最终权限只能是 +get 和 ~report:*”，就不能只把目标规则写在第二次调用里。要么显式清理不需要的局部规则，要么用 reset 从完整声明开始。

先读基线：ACL GETUSER 能确认哪些东西

排查时不要只看脚本里“准备写入什么”，还要先读取 Redis 当前保存的用户状态。ACL GETUSER 可以把用户是否启用、密码摘要状态、命令规则、key 规则和 channel 规则列出来，适合确认旧规则是否仍在。

# 读取用户当前 ACL 状态，重点观察 flags、commands 和 keys
redis-cli ACL GETUSER report-reader

# 只读取用户列表，确认排查的用户名没有拼错
redis-cli ACL USERS

如果返回中的命令规则同时出现 +get、+set，或者 key 范围同时包含 ~report:*、~job:*，就说明第二次调用确实是在已有规则上继续叠加。这个判断不需要把“第二次写入”误认为“完整配置替换”。

另外，ACL SETUSER 的规则是从左到右应用的；本文只讨论规则含义，不把 ACL GETUSER 的展示顺序当成权限优先级。

reset 清空的不是一条规则，而是用户能力集合

reset 的语义比“删除某个命令权限”更强：它会移除用户已有能力，使用户恢复为关闭、无密码、不能执行命令、不能访问 key 的默认状态。也就是说，旧的命令权限、key 访问范围以及已有密码都不能假设会被保留。

要从头声明一份用户配置，应把 reset 放在本次规则列表的第一项，然后在同一条调用中补回需要的状态和权限：

# reset 必须作为首条规则，先清空旧能力，再声明最终配置
redis-cli ACL SETUSER report-reader 'reset' 'on' '+get' '~report:*'

# 用 GETUSER 读取重建后的状态，确认只留下本次声明的边界
redis-cli ACL GETUSER report-reader

这条写法的关键不在于命令更长，而在于它把“最终状态”集中表达了：on 重新启用用户，+get 授予命令能力，~report:* 授予 key 范围。若还需要密码，应在同一份完整声明里明确添加，而不要依赖 reset 前的旧密码。

三种写法怎么选：追加、局部清理还是完整重建

如果只想撤销 key 范围，Redis 还提供 resetkeys；只想清理 Pub/Sub channel 范围，可以使用 resetchannels。这些局部规则与总的 reset 不是同一强度，脚本应根据变更对象选择最小影响的命令。

权限脚本里最容易踩的四个边界

1. 把“声明文件”写成了“增量脚本”。 每次只追加几条规则，长期会让权限集合越来越大；需要可重复收敛时，用 reset 加完整声明。
2. 忘记 reset 后用户默认是关闭的。 如果目标用户要能认证，完整重建里要明确写 on，不能假设旧状态会自动回来。
3. 把 reset 和 resetkeys 混用。 前者影响整组用户能力，后者只处理 key 模式；变更前先写清楚要清理的对象。
4. 只检查命令返回 OK，不检查最终用户状态。 写入后用 ACL GETUSER 复查当前配置；如果是生产发布脚本，还要把目标用户名和期望规则记录到变更日志。

还要注意一个独立边界：把用户设为 off 后，已经认证的连接不会因为这个动作自动停止；如果变更目标包含旧连接，还需要按 Redis 的连接管理策略另行处理。这个行为不改变 reset 的规则清空语义。

用一句话记住区别

ACL SETUSER user rule... 是“在当前用户上应用规则”，适合小步追加；ACL SETUSER user reset rule... 是“先恢复默认，再按本次列表重建”，适合把权限配置收敛到唯一声明。排查旧权限为什么还在时，先用 ACL GETUSER 建立基线，再决定是局部清理还是完整重建。

相关问题

• ACL SETUSER 重复执行会覆盖密码吗？ 普通规则是增量应用，密码规则也要按明确的添加、删除或清空语义处理；不要把第二次调用当成整份用户配置替换。
• 什么时候用 resetkeys 而不是 reset？ 只需要换 key 访问范围时优先考虑局部清理，避免同时移除命令、用户状态和密码能力。
• reset 之后为什么用户登录失败？ reset 会让用户回到关闭且无密码的默认状态，完整重建时需要明确写入启用状态和认证规则。