Go中redis.Incr原子计数必须直接使用*redis.Client实例，不可用ClusterClient或封装接口；需检查v8/v9版本混用、key存在性校验、显式设置TTL、避免依赖返回值做业务判断。
Go 用 redis.Incr 做原子计数，必须用 *redis.Client，不能用 pool 或其他封装
Go 官方 redis 客户端（github.com/go-redis/redis/v9）的 Incr 和 Decr 是原子操作，但前提是调用对象是 *redis.Client，不是 *redis.ClusterClient，也不是你自己包一层的“通用接口”。很多项目为了统一管理连接，会提前把 Client 封进 struct，结果传进去的是接口或指针别名，导致编译不报错、运行时 panic：panic: interface conversion: interface {} is nil, not *redis.Client。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 直接用
redis.NewClient()创建的实例调用Incr，不要中间再套一层结构体字段间接引用 - 如果必须封装，字段类型明确声明为
*redis.Client，且初始化时确保非 nil - 检查你的
go.mod是否混用了 v8 和 v9：v8 的Incr返回*redis.IntCmd，v9 返回*redis.IntCmd但方法签名不同，混用会导致cmd.Val()报nil pointer dereference
key 设计不当，Incr 会默默从 0 开始计，但业务可能要拒绝初始值
Redis 的 Incr 对不存在的 key 会自动设为 0 再加 1，返回 1。这在限流、投票、库存扣减等场景下容易出问题——比如你期望“只有已创建订单的用户才能累加支付次数”，但只要 key 一出现就允许 Incr，等于绕过了前置校验。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 关键业务计数前，先用
Exists检查 key 是否存在，再决定是否Incr；或者用 Lua 脚本把判断 + 自增打包成原子操作 - key 命名带业务上下文，例如
order:pay_count:{order_id}，避免和缓存 key 冲突，也方便后期 scan 清理 - 不要依赖
Incr的返回值做“是否首次”判断——它返回的是新值，不是增量；首次调用返回 1，第二次返回 2，无法区分“刚创建”和“已存在但值为 1”
没设过期时间，Incr 后的 key 会永久残留
Incr 不会继承任何 TTL，哪怕你之前对同一个 key 调用过 Expire，只要中间有任意一次 Incr（或 Set），TTL 就会被清除。线上常见 case：用 Incr 统计每小时请求量，key 是 req:hour:2024052014，但忘了给它设过期，半年后 Redis 内存爆满，排查发现几百万个过期的 hour key 还在。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每次
Incr后立刻跟一个Expire（注意：必须用同一个 conn，否则非原子；推荐用pipeline或 Lua） - 更稳妥的做法：用
SetNX初始化 key 并设 TTL，之后只用Incr；或改用INCRBYEX（Redis 7.0+），它支持带过期的自增 - 本地开发用
redis-cli --scan | grep 'req:hour' | head -20定期检查 key 存活情况，比等报警更早发现问题
并发高时，Incr 返回值可能被覆盖，别直接当最终结果用
Incr 本身是原子的，但 Go 里拿到返回值后，如果紧接着做“判断是否超阈值 → 写日志 → 发消息”，这一串不是原子的。多个 goroutine 同时 Incr 同一个 key，都拿到返回值 100，然后都去发告警，结果重复推送 10 次。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把临界逻辑放进 Lua 脚本：用
EVAL把“自增 + 判断 + 条件写入”锁死在 Redis 端 - 如果必须在 Go 层判断，用
CompareAndSwap思路：记录上一次触发阈值的值，当前值 > 上次值 + 阈值才执行后续动作 - 别用
if val == 100 { sendAlert() }这种精确匹配，改用if val%100 == 0或滑动窗口控制频率
真正麻烦的从来不是 Incr 本身，而是人总以为“原子操作 = 整个业务流程安全”。Redis 只保 key 级别指令原子性，剩下的得你自己兜底。
