支付回调并发 200 时，计数器报表 3 月 1 日少 12,040 次，日志里回调成功数却对得上。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，代码先读当前值再加一写回，两个请求读到同一个旧值，后写的覆盖前一个。Redis 单命令是原子的，但 GET 和 SET 是两次往返。缺一个真正的原子自增。
「并发计数丢数」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
redis-cli INCR stat:pay:20260301 redis-cli GET stat:pay:20260301
同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
具体做法是，改用 INCR 或 INCRBY 单命令累加；需要按维度计数时把维度拼进 key；对账时用数据库明细重算 与计数器比对；压测 200 并发跑一轮 看差额是否归零。
最后用这个标准收尾，200 并发压测后计数器与数据库明细一致，差额为 0。