当前位置：首页 > 文章列表 > 数据库 > Redis > Redis AUTH 传用户名和只传密码有什么区别

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

来源：17golang原创 2026-11-11 05:00:38 0浏览收藏

我在把 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 的密码与预期不同而认证失败。

Redis AUTH 单参数和双参数分别对应 default 用户与自定义用户的静态结构说明图 — 图1：AUTH 参数选择结构说明图，查看单参数和双参数分别指向哪类用户。

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

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

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

写法	隐含/指定用户	适用理解
`AUTH password`	`default`	兼容旧式单密码客户端
`AUTH username password`	指定 ACL 用户	多用户、最小权限和服务隔离

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

这是排查 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 用户认证。实际项目应让客户端参数和部署环境中的用户设计保持一致，不要只因为密码相同就省略用户名。