密码不一致是导致哨兵切换后连接立即断开的确定性原因：requirepass与masterauth必须全局统一，否则新主无法被从节点同步、客户端也无法认证，CONFIG SET不持久化，需在redis.conf中显式配置并执行CONFIG REWRITE。
密码不一致不是切换失败的“可能原因”，而是生产环境中最常触发 +failover-abort-no-good-slave 或 +switch-master 后连接立即断开的确定性原因。问题不在哨兵选不出主，而在于它选出新主后，自己连不上、客户端也连不上——因为认证链断了。
为什么 requirepass 和 masterauth 必须对齐？
Redis 实例在角色切换前后，承担的认证职责完全不同：
- 旧主宕机前：用
requirepass控制所有客户端连接 - 从节点晋升为新主后：既要接受客户端连接（需
requirepass），又要被其他从节点反向同步（需提供masterauth给它们用于 AUTH） - 旧主恢复后：会尝试作为从节点去连新主，这时它必须用
masterauth去认证——如果这个值和新主的requirepass不一致，同步直接失败，整个集群卡住
所以 requirepass 和 masterauth 在所有节点上必须是同一个字符串，否则故障转移完成即意味着复制断裂。
CONFIG SET masterauth 不等于配置文件生效
很多人执行 redis-cli CONFIG SET masterauth "xxx" 后以为万事大吉，但这是运行时设置，不会写入磁盘。一旦实例重启，该值丢失，旧主恢复后仍无法连新主。
- 确认是否持久化：执行
redis-cli CONFIG GET masterauth，再执行redis-cli CONFIG REWRITE -
CONFIG REWRITE只会把当前运行时有效配置（包括CONFIG SET设置的）写回 redis.conf 中已存在的指令行；如果 conf 里原本没写masterauth，它不会自动添加 - 正确做法：所有节点的 redis.conf 中都显式写入
requirepass xxx和masterauth xxx，然后统一执行CONFIG REWRITE+ 重启
哨兵配置里的 sentinel auth-pass 不能替代实例级密码
哨兵进程自身需要连 Redis 实例执行命令（如 SLAVEOF NO ONE、CONFIG SET），所以它的配置文件中必须有 sentinel auth-pass <master-name> xxx</master-name>。但这只是哨兵自己的认证凭据，不影响 Redis 实例之间的认证逻辑。
- 错误认知：“我配了
sentinel auth-pass，所以 Redis 实例之间就自动同步密码了” - 真相：哨兵用这个密码连主/从节点发命令，但主从之间复制时仍依赖各自
masterauth和requirepass的匹配 - 验证方式：停掉哨兵，手动用
redis-cli -a xxx连任意从节点，执行INFO replication，看master_auth字段是否显示为预期值
客户端连接池缓存旧密码导致“切完就连不上”
这不是服务端问题，但现象完全一样：哨兵日志显示 +switch-master 成功，客户端却报 NOAUTH Authentication required 或连接拒绝。
- Lettuce 默认复用连接池，且不主动监听
+switch-master事件刷新认证信息 - Jedis 若使用
JedisSentinelPool，必须确保构造时传入的password参数与新主的requirepass一致；若用错密码初始化，后续所有连接都会失败 - Redisson 推荐显式配置
setPassword()并启用setMasterConnectionPoolSize()配合健康检查，避免旧连接残留
真正容易被忽略的是：密码不一致问题往往在切换发生后才暴露，而排查时却只盯着哨兵日志和 Redis 日志，忘了客户端连接池根本没换密码——它还在用旧主的密码连新主。
