init中调用Redis的Ping会卡死，因init阶段禁止goroutine调度，超时机制失效，且日志不可见；正确做法是用sync.Once在main或首次使用时懒加载并显式错误处理。
别在 init 里连 redis，否则服务大概率卡死在启动阶段，且错误无迹可寻。
为什么 init 中调用 redis.NewClient 会卡住
很多人以为 redis.NewClient 只是构造一个客户端对象，其实它内部**不建连**；但只要紧接着在 init 里调 rdb.Ping(ctx).Result()，就触发同步阻塞 I/O。DNS 解析慢、防火墙拦截、Redis 服务未启，都会让整个程序停在 init 阶段——而此时 log 可能还没初始化，fmt.Println 也可能被缓冲或丢弃，你什么都看不到。
更糟的是：Go 运行时在 init 阶段禁止新 goroutine 调度，所以哪怕你传了 context.WithTimeout，ctx.Done() 也永远不会被 select 到，超时机制完全失效。
-
redis.NewClient本身安全，但后续任何带 I/O 的操作（如Ping、Set）都不该出现在init - 若用了封装层（比如自己写的
NewRedisClient()），内部若含WaitGroup或 channel 等等待逻辑，可能直接触发fatal error: all goroutines are asleep - deadlock! - 本地测试“碰巧”成功？那只是因为你 Redis 在跑、网络通畅、没并发依赖——上线后环境一变就崩
正确姿势：用 sync.Once + 显式初始化函数
把连接行为从“包加载期”挪到“业务首次需要时”，既可控，又可测，还能捕获并处理错误。
- 定义导出变量：
var RDB *redis.Client，初始为nil - 写初始化函数：
func SetupRedis() error，内部用sync.Once.Do包裹redis.NewClient和Ping验证 - 在
main()开头显式调用SetupRedis()，失败则log.Fatal(err)；或在第一个 HTTP handler 里检查RDB == nil后再懒加载 - 别在
init里调sync.Once.Do——它本身线程安全，但init阶段无法 recover 错误，也不该由包加载器替你决定何时连
Addr 和驱动错配是静默失败的主因
连接失败却不报错？十有八九是 DSN 地址和客户端配置对不上。这不是 Go 的问题，而是你告诉它连什么、它就信什么，连错了也默默等超时。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
redis.NewClient(&redis.Options{Addr: "localhost:6379"})中Addr必须显式写出，不会 fallback 到127.0.0.1:6379；留空或写成""就会卡住 - Docker 容器里连宿主 Redis：
localhost:6379指的是容器自己，Mac/Win 用host.docker.internal:6379，Linux 用172.17.0.1:6379 - 确认你用的是
github.com/redis/go-redis/v9，不是已归档的v8或更早版本；安装命令必须是go get github.com/redis/go-redis/v9 - 在
SetupRedis里加一行日志：log.Printf("connecting to %s", opts.Addr)，确保地址是你真想连的那个
defer 关闭不等于安全退出
defer rdb.Close() 放在 main 函数开头，只保证函数返回时执行；但若进程被 kill -9 或 os.Exit() 强制终止，它根本不会运行。
- 必须配合信号监听：
signal.Notify(sigChan, syscall.SIGTERM, syscall.SIGINT)，收到后调rdb.Close()再退出 -
rdb.Close()是阻塞操作，生产环境建议用context控制超时，避免关不掉卡住进程 - 别在 goroutine 里 defer 关闭共享
RDB——每个 goroutine 的 defer 作用域独立，无法替代主流程清理
真正难的不是写对那一行 redis.NewClient，而是把“什么时候连”“连不上怎么办”“连上了怎么关”这三件事，从隐式、不可控、不可测的 init 阶段，拉回到你手里可编排、可观察、可重试的主流程中。
