Redis HELLO 3 怎样确认客户端已切换到 RESP3

Redis 连接默认从 RESP2 开始。想尝试 RESP3 时，关键不是看到 HELLO 3 被发送出去，而是读取成功响应里的 proto 字段：返回 proto=3，才说明当前连接已经切换到 RESP3；如果命令报错，连接可能仍停留在 RESP2。

确认 Redis HELLO 3 是否生效，只看成功响应中的 proto。认证失败、服务端不认识 HELLO，或者协议版本不支持时，不要提前把后续响应按 RESP3 解码。

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

这个判断适合放在连接初始化阶段。先完成握手，再决定客户端后续使用哪套协议解析；旧 Redis 服务无法升级时，则保留 RESP2 回退分支。

HELLO 3 返回的 proto 才是判断点

HELLO 同时承担协议握手和连接信息查询。Redis 6 及以后支持 RESP2 与 RESP3，但新连接默认仍从 RESP2 开始。发送 HELLO 3 后，成功响应会包含服务器版本、连接 ID、角色等属性，其中 proto 表示当前连接使用的协议版本。

HELLO 3
server: redis
version: 8.x
proto: 3
id: 12
mode: standalone
role: master

上面是便于阅读的响应示意，不代表固定字段顺序或某台服务器的实际输出。真正要保留的是 proto: 3 这一判断信息；版本、ID、角色和模块列表都可能随服务端环境变化。

为什么发出了 HELLO 3 仍可能是 RESP2

发送命令本身不等于握手成功。协议规范给出了几个容易混淆的边界：

特别是把认证信息和握手合并成 HELLO 3 AUTH ... 时，认证失败不会“半成功”：Redis 会报错、保持原状态。客户端如果只记录“连接建立了”，却没有记录 HELLO 的结果，就可能把后续 RESP2 返回误当成 RESP3。

在客户端连接初始化时怎么留住判断结果

应用层可以把握手结果收敛成一个简单的协议状态。下面用 Go 的 go-redis 展示思路：调用通用命令接口取得 HELLO 3 的返回映射，再读取 proto。示例重点是判断边界，不把某次输出当成固定数据。

package main

import (
    "context"
    "fmt"

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

func negotiate(ctx context.Context, client *redis.Client) (int64, error) {
    // HELLO 3 请求把当前连接切换到 RESP3，并返回连接属性。
    values, err := client.Do(ctx, "HELLO", "3").Map()
    if err != nil {
        // 服务端不支持 HELLO、协议版本不支持或认证失败都在这里处理。
        return 0, fmt.Errorf("HELLO 3 failed: %w", err)
    }

    raw, ok := values["proto"]
    if !ok {
        // 没有 proto 时不猜测协议，交给上层决定是否降级。
        return 0, fmt.Errorf("HELLO response has no proto")
    }

    proto, ok := raw.(int64)
    if !ok || (proto != 2 && proto != 3) {
        // 只接受协议规范中的已知版本，避免误启用 RESP3 解码。
        return 0, fmt.Errorf("unsupported negotiated proto: %v", raw)
    }
    return proto, nil
}

在真实项目里，proto=3 只是“握手确认”这一层的结论，后续还要确认所用客户端是否完整支持 RESP3 的 map、set、push 等回复类型。不要因为握手成功，就假设所有业务命令的返回类型都与 RESP2 相同。

旧服务怎样保留 RESP2 回退路径

兼容逻辑最好按错误类型分开记录：服务端不认识 HELLO，说明它可能是较旧版本；-NOPROTO 说明请求的协议版本不被支持；认证失败则是凭据问题，不能悄悄当作协议降级。只有确认旧服务可以继续用 RESP2 时，才进入 RESP2 分支。

部署时可以把协议协商结果写入连接诊断字段，例如 redis_proto=2 或 redis_proto=3，同时保留原始错误类型。这样排查“某些节点返回结构不同”时，能先判断是不是连接落在了不同协议上，而不是盲目修改业务反序列化代码。

常见问题

HELLO 3 没有返回 proto，能否默认按 RESP3？ 不能。缺少协议字段时应视为协商信息不完整，继续使用原协议或走明确的降级策略。

Redis 7 还需要 HELLO 3 吗？ 如果客户端需要明确协商 RESP3，仍可使用 HELLO 3；Redis 7 及以后两种协议都能调用核心命令，但连接使用哪种回复格式仍应由握手结果和客户端能力共同决定。

HELLO 3 AUTH 失败后要不要重试 RESP3？ 先修复用户名或密码，再重新建立清晰的握手流程；不要把认证失败当成协议切换成功。