从 Redis 3.2 升级到 6.0 时，若仅使用默认用户和 requirepass 配置，客户端代码通常无需修改。只有在启用 6.0 新增的 ACL 多用户功能或原生 TLS 时，才需要调整认证参数和连接配置。
先说结论：Redis 6.0 兼容 3.2 的单密码认证方式，代码适配仅在启用 ACL 多用户或 TLS 时必要。
- 适合：现有使用 requirepass 单密码认证的生产环境升级。
- 先准备：确认客户端驱动版本支持 Redis 6.0 协议。
- 验收：通过 redis-cli 和业务日志验证认证通过且无权限报错。
命令速用版
升级前后使用以下命令确认认证配置状态，避免连接失败。
CONFIG GET requirepass ACL LIST redis-cli -h <host> -p <port> -a <password> PING
若启用 ACL 多用户，连接命令需增加用户名参数。
redis-cli -h <host> -p <port> -u <username>:<password> PING
为什么会这样
Redis 6.0 引入了 ACL 访问控制系统，但保留了旧版 AUTH 命令的兼容性。
Redis 3.2 至 5.0 版本主要依赖 requirepass 配置项进行单密码认证，所有客户端使用同一密码。Redis 6.0 版本引入了 ACL 系统，支持多用户和细粒度权限控制，AUTH 命令语法扩展为支持用户名和密码。为了平滑升级，6.0 版本默认保留 default 用户，且允许继续使用 AUTH <password> 形式，因此旧代码在不启用新特性时无需改动。
分步处理
按以下步骤操作可确保升级过程中认证机制不中断业务。
步骤一：备份配置与数据
在升级前 dump.rdb 或 appendonly.aof 文件必须备份，同时保存 redis.conf 配置文件。
步骤二：检查客户端驱动版本
确认业务代码使用的 Redis 客户端库支持 Redis 6.0 协议。老旧驱动可能无法正确处理 6.0 的新响应格式。
步骤三：配置兼容性验证
在测试环境部署 Redis 6.0，保留原有 requirepass 配置，不启用 ACL 多用户。使用现有代码连接测试。
步骤四：逐步切换流量
先切换只读流量到 6.0 实例，观察日志无 AUTH 失败报错后，再切换写流量。
怎么验证是否生效
通过客户端连接状态和服务器日志确认认证机制工作正常。
检查命令：使用 redis-cli 执行 PING 命令，返回 PONG 表示认证通过。
日志位置：查看 Redis 服务器日志，确认没有 NOAUTH Authentication required 或 ERR invalid password 错误。
业务表现：监控业务应用日志，确认没有因连接拒绝导致的异常堆栈。
常见坑
升级过程中容易忽略客户端库兼容性和 TLS 配置差异。
客户端库过旧：部分早期版本的客户端库可能无法识别 6.0 的某些新响应字段，导致解析错误，建议升级到稳定版。
用户名认证混淆：若尝试使用 ACL 多用户，代码中 AUTH 命令需发送用户名和密码，仅发送密码会被视为 default 用户认证。
TLS 配置缺失：Redis 6.0 支持原生 TLS，若开启 tls-port，客户端必须配置 SSL 连接参数，否则无法握手。
常见问题
升级后原有密码还能用吗
能继续使用。Redis 6.0 默认保留 default 用户，原有 requirepass 密码对 default 用户依然有效。
代码需要修改 AUTH 命令吗
不需要修改。只要不使用 ACL 多用户功能，原有的单密码 AUTH 调用方式在 6.0 中完全兼容。
什么时候必须改代码
只有当需要为不同业务创建独立 Redis 用户并分配不同权限时，才需要在代码中传入用户名。
参考来源
Redis Official Documentation, Redis 6.0.0 Release Notes, GitHub redis/redis repository.
- Redis Documentation: https://redis.io/documentation
- Redis 6.0 Release Notes: https://github.com/redis/redis/releases