能连上Redis的关键在于服务端运行、地址配置正确、context非nil；三者缺一不可，否则rdb.Set()等操作必然失败。
能连上 Redis 的关键不在 Go 代码写得多漂亮，而在于服务端真在跑、地址写对了、context 没传 nil——这三件事没做对，rdb.Set() 再多也白搭。
redis-server 没起来，Go 代码再对也没用
90% 的 connection refused 或超时，根源是 Redis 进程根本没启动。别急着改 Go，先验证服务本身：
- macOS：运行
brew services list | grep redis，或直接redis-cli ping—— 必须返回PONG - Linux：用
systemctl status redis或ps aux | grep redis确认进程存在 - Docker：检查容器是否运行
docker ps | grep redis，并确认端口映射正确（如-p 6379:6379） - 云服务器/远程机器：确认
redis.conf中bind包含0.0.0.0（非仅127.0.0.1），且protected-mode no（仅调试时临时关闭）
用错客户端库或 Addr 配置导致连接失败
当前唯一推荐的客户端是 github.com/redis/go-redis/v9，旧版 go-redis/redis/v8 已归档，v9 强制 context 控制生命周期，错误提示更明确。
- 安装命令必须是：
go get github.com/redis/go-redis/v9 -
Addr字段不能省略或留空，不会 fallback 到localhost；本地开发建议写死"127.0.0.1:6379"，避免 DNS 解析走 IPv6 导致[::1]:6379连不上 - 密码和 DB 是可选的，但
Password若为空字符串需显式写""，DB是整数（如0），不是字符串 - 初始化后必须调一次
rdb.Ping(ctx).Err()，这是唯一可靠的连通性验证方式
context 不传或超时未设，请求会卡死或 panic
所有操作方法（rdb.Get()、rdb.Set()、rdb.HGetAll()）第一个参数都必须是非 nil 的 context.Context。硬写 context.Background() 在 HTTP handler 里是危险操作。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
立即学习“go语言免费学习笔记（深入）”；
- HTTP 场景下应继承请求上下文：
ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)，然后 defer cancel() - 忘传 context 或传
nil，会 panic：context must be non-nil - 超时不是 client 全局配置项，必须由每次调用的 context 控制；不设 timeout，网络抖动时 goroutine 会无限阻塞
- Set 过期时间单位是
time.Duration，写10是 10 纳秒，必须写10 * time.Second
Docker 容器里连宿主 Redis，localhost 是错的
Go 程序若运行在 Docker 容器中，localhost:6379 指的是容器自己，不是你的开发机。
- macOS / Windows：用
host.docker.internal:6379 - Linux（Docker 默认桥接）：用
172.17.0.1:6379 - 如果 Redis 也在另一个容器里，应通过 Docker 网络名访问（如
redis:6379），而非 IP
最常被忽略的其实是连接池和超时配置：不设 PoolSize 和 Timeout，压测时容易出现 too many open files 或 I/O timeout；MaxConnAge 不设会导致连接长期空闲被 NAT 设备静默断开——这些不是“可选项”，是线上服务存活的基本条件。
