Redis AUTH 传用户名和只传密码有什么区别

我在把 Redis 从“一个密码就能连上”迁移到 ACL 用户时，最容易混淆的地方不是密码本身，而是 AUTH 到底让 Redis 选择了哪个用户。结论很明确：只传密码时，Redis 按 default 用户认证；传用户名和密码时，认证对象就是指定的 ACL 用户。两种写法都可能认证成功，但后续能执行的命令和能访问的 key 可能完全不同。

官方地址：https://redis.io/docs/latest/commands/auth/

旧式 AUTH password 是兼容写法，隐含用户名 default；ACL 场景更适合明确使用 AUTH username password，这样客户端配置和目标用户的权限边界一致。

• 只传密码：等价于对 default 用户提交密码。
• 传用户名和密码：明确选择某个 ACL 用户，再验证该用户的密码。
• 判断重点：认证成功只说明身份确认，不代表该身份拥有所有命令和 key 权限。

AUTH 的两个写法到底差在哪里

Redis 官方把命令语法写成 AUTH [username] password。省略用户名时，使用的是单参数兼容形式；在 ACL 系统里，这个省略的用户名就是 default。因此下面两条命令的区别，不是“有没有启用密码”，而是是否明确选择用户：

# 兼容旧式单密码配置：目标用户隐含为 default
redis-cli -h 127.0.0.1 -p 6379 AUTH '默认用户密码'

# ACL 场景明确选择用户：密码只用于校验 app-reader
redis-cli -h 127.0.0.1 -p 6379 AUTH app-reader '读取用户密码'

如果 Redis 只配置了 default 用户，单参数写法通常足够；如果已经创建了多个 ACL 用户，单参数写法不会“自动猜测”某个自定义用户。漏传用户名时，常见结果是认证到了 default，或者因为 default 的密码与预期不同而认证失败。

default 用户和自定义用户不是同一个权限集合

default 是 Redis ACL 中的特殊默认用户。官方文档说明，旧的 requirepass 配置现在对应的是给 default 用户设置密码，这就是旧客户端仍能使用单密码认证的兼容来源。它并不意味着所有新建用户都会共享同一个密码或权限。

自定义用户则有自己的启用状态、密码和 ACL 规则。比如一个只读用户可能允许读取某个 key 模式，却不允许执行写命令；一个业务写入用户也可能只开放有限的命令集合。认证时传入哪个用户名，后续连接就会绑定到哪个用户的权限判断上。

认证成功不等于什么都能做

这是排查 Redis 客户端问题时最值得分开的两层：第一层是“你是谁”，由 AUTH 的用户名和密码决定；第二层是“你能做什么”，由这个用户的命令权限、key 访问模式等 ACL 规则决定。即使 AUTH 返回成功，后续命令仍可能因为 ACL 限制被拒绝。

package main

import (
    "context"
    "fmt"

    "github.com/redis/go-redis/v9"
)

func main() {
    ctx := context.Background()
    client := redis.NewClient(&redis.Options{
        Addr:     "127.0.0.1:6379",
        Username: "app-reader", // ACL 场景显式选择目标用户
        Password: "读取用户密码",  // 这里只校验该用户的密码
    })
    defer client.Close() // 客户端结束时释放连接池资源

    if err := client.Ping(ctx).Err(); err != nil {
        panic(fmt.Errorf("Redis 认证或连接失败: %w", err))
    }
}

在 Go 客户端中，Username 为空时，客户端通常会走只提供密码的兼容路径；填写 Username 后，才是明确的 ACL 用户认证。实际项目应让客户端参数和部署环境中的用户设计保持一致，不要只因为密码相同就省略用户名。

遇到认证问题时先分清是哪一层

如果返回的是认证失败，先检查用户名是否漏传、用户名拼写是否一致，以及密码是否属于目标用户。若 AUTH 已成功，但读取或写入命令被拒绝，就不要继续修改密码；这更像是对应 ACL 用户没有获得该命令或 key 的权限。

迁移旧客户端时，可以暂时保留单参数形式来兼容只面向 default 用户的连接；新服务则建议在配置中显式保存用户名和密码的对应关系。这样日志、连接串和权限审查都更容易对齐，也能避免“认证成功了却连到了错误用户”的隐性问题。

常见问题

只传密码是不是不能使用 ACL？

不是。它会按 default 用户认证，因此仍然会受到 default 用户 ACL 规则的约束；只是不能用它选择某个自定义用户。

用户名和密码都正确，为什么命令仍然被拒绝？

认证和授权是两层判断。先确认连接绑定的用户，再查看该用户是否允许目标命令，以及目标 key 是否匹配它的访问规则。

旧的 requirepass 还适用吗？

Redis 官方文档说明它仍可工作，并表现为给 default 用户设置密码。是否继续使用，应结合多用户隔离和最小权限需求决定。

Go 客户端什么时候必须填写 Username？

当目标不是 default 用户，或服务已经按 ACL 用户做权限隔离时，应填写 Username；只面向默认用户的兼容连接才可以只提供密码。

可以把这件事记成一句话：AUTH password 选择 default，AUTH username password 选择明确用户；认证解决“是谁”，ACL 规则再决定“能做什么”。