必须改用 redis.NewClient() 替代已弃用的 redis.Dial()，传入 *redis.Options 配置 Addr/Password/DB，所有操作需传 context，连接池由客户端内置管理，Incr() 要注意类型和过期逻辑。
redis.Dial() 已被弃用，必须改用 redis.NewClient()
Go 生态里老教程还在用 redis.Dial() 或 redigo 的连接方式，但官方推荐的 github.com/go-redis/redis/v9 完全不兼容那套——它没有 Dial，只有 NewClient()。继续用旧方法会卡在连接建立、上下文超时、或根本拿不到 Cmdable 接口。
- 新客户端必须传入
*redis.Options，其中Addr、Password、DB是最常配的三项 -
Context要贯穿所有操作（如client.Incr(ctx, key)），漏传会导致阻塞或 panic - 别手动管理连接：连接池由
NewClient()内置处理，SetPoolSize()控制最大并发连接数，默认 10，高吞吐场景建议设为 20–50
计数器原子性靠 Incr()，但要注意 key 类型和过期逻辑
Incr() 看似简单，实际踩坑集中在两处：一是对非数字值执行会报 WRONGTYPE Operation against a key holding the wrong kind of value；二是没设过期导致 key 永久残留。
- 首次调用
Incr()时，若 key 不存在，Redis 自动初始化为 0 再 +1，无需SetNX()预热 - 想带过期时间，不能直接
Expire()—— 它和Incr()不是原子的；正确做法是用Set(key, 0, time.Minute).Err()初始化，再用Incr() - 如果业务要求“存在则 incr，不存在则跳过”，得用
Get()+SetNX()+Incr()组合，但注意这三步非原子，需用 Lua 脚本或改用Eval()
连接池打满后请求阻塞，不是超时报错
当并发量超过 PoolSize 且所有连接都在忙时，后续请求不会立刻失败，而是排队等待空闲连接——表现为延迟陡增，甚至卡住几秒。监控时容易误判为网络问题或 Redis 崩溃。
- 检查是否设置了
MinIdleConns：它控制保活的最小空闲连接数，设为 5–10 可缓解突发流量冷启动延迟 -
MaxConnAge和MaxConnLifetime用于轮换老连接，避免长连接内存泄漏或服务端连接老化断连 - 线上务必开启
client.Ping(ctx)健康检查，并捕获redis.Nil（key 不存在）和context.DeadlineExceeded（超时）两类错误，其他错误应记录并告警
本地调试时用 redis-cli 查 key 状态，别只信代码日志
缓存逻辑出问题，90% 的情况是 key 值、类型或 TTL 不符合预期。光看 Go 日志里的 val, err := client.Get(ctx, "counter:login").Int64() 返回值，掩盖了真实状态。
立即学习“go语言免费学习笔记（深入）”；
- 终端执行
redis-cli -p 6379连上后，用TYPE counter:login确认是不是 string；用TTL counter:login看剩余时间；用GET counter:login看原始值 - 如果看到
(integer) 0却代码里读出来是空，大概率是Get().Int64()对 nil 值 panic 了——得先if err == redis.Nil判断 - 开发阶段建议加一行
client.AddQueryHook(&debugHook{})，用自定义 hook 打印每条命令的耗时和参数，比埋点更直接
Redis 计数器看着就一行 Incr()，但连接生命周期、错误分类、key 状态验证、客户端配置粒度，哪一环松动都会让“简易”变成“玄学”。尤其上线前一定要用 redis-cli monitor 抓真实命令流，眼见为实。
