newclient直连哨兵地址会失败，因为哨兵只响应sentinel指令（如sentinel get-master-addr-by-name），不处理get等redis数据命令，协议不匹配导致err unknown command 'get'；必须用newfailoverclient自动与哨兵通信、获取主节点并监听故障转移事件。
必须用 NewFailoverClient，不能用 NewClient 直连固定地址，否则哨兵形同虚设。
为什么 NewClient 连哨兵地址会失败
有人试过把哨兵的地址（比如 127.0.0.1:26379）直接塞进 NewClient(&Options{Addr: "127.0.0.1:26379"})，结果一调用 Get() 就报 ERR unknown command `GET` 或连接被拒绝。这是因为哨兵节点本身不响应 Redis 命令——它只认 SENTINEL 系列指令。客户端误以为连的是 Redis 实例，实际连的是哨兵服务，协议不匹配自然失败。
真正该做的是让客户端主动跟哨兵“对话”，拿到当前主节点地址后再连过去。这个逻辑封装在 NewFailoverClient 里，不是你手动拼地址能替代的。
FailoverOptions 关键字段填错就等于没配哨兵
MasterName 必须和哨兵配置里 sentinel monitor mymaster 127.0.0.1 6379 2 的第一个参数完全一致（区分大小写），填错会导致初始化时反复打印 failed to resolve master，最终 client.Ping() 返回超时或空错误。
一款AI工具，主要用于通过后台进程运行 Codex CLI、Claude Code、OpenCode 或 Pi Coding Agent，实现程序化控制，适合需要提升相关任务效率的用户。
-
SentinelAddrs填的是哨兵地址列表，端口默认26379，不是 Redis 的6379；至少写一个，但生产环境建议写全（如[]string{"10.0.1.10:26379", "10.0.1.11:26379"}），避免单点失效 - 如果哨兵启用了认证，
SentinelPassword必须设；Redis 主从自己的密码是另一个字段Password，别混在一起 -
Username在哨兵模式下仅对 Redis 6+ ACL 生效，且需额外配SentinelUsername（哨兵用户）和Username（Redis 实例用户），两者独立
怎么验证哨兵链路真正在工作
只调 client.Ping().Err() 成功，不代表高可用已生效——它可能只是连上了某个哨兵，还没拉到主节点地址，或者主已切换但客户端没收到 +switch-master 事件。
可靠验证方式：
- 启动后立刻查日志，确认有没有类似
resolved master mymaster -> 10.0.1.20:6379的输出 - 手动 kill 当前主 Redis 进程，观察客户端是否在几秒内自动恢复写入（而不是持续报
connection refused） - 用
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster对比客户端实际使用的地址是否一致
最容易被忽略的是：哨兵配置里的 quorum 值（比如 sentinel monitor mymaster 127.0.0.1 6379 2 中的 2）必须 ≤ 实际运行的哨兵数，否则故障转移根本不会触发——客户端再怎么等也收不到新主通知。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
