推荐优先使用miniredis：它实现resp协议子集，支持pipeline、事务、过期、pub/sub，直连原生redis.newclient()，启动时自动分配端口；redis-test仅stub少量命令，不覆盖连接与超时逻辑。
Redis Mock库选哪个：gomock vs miniredis vs redis-test
测试 Redis 交互时，别用 gomock 手动 mock redis.Client 接口——它不模拟协议行为，一调 Get().Result() 就 panic。真实可用的只有两个方向：纯内存 fake server（如 miniredis），或轻量 client stub（如 redis-test）。前者更贴近生产行为，后者启动快但覆盖命令少。
推荐优先用 miniredis：它实现了 RESP 协议子集，支持 pipeline、事务、过期、Pub/Sub，且能直接复用你的原生 redis.NewClient() 初始化逻辑，不用改业务代码。
-
miniredis启动后暴露真实 TCP 端口，redis.NewClient(&redis.Options{Addr: "127.0.0.1:9999"})可直连 -
redis-test是 client 层 mock，只 stub 几个常用方法（Get/Set），不处理连接、重试、context 超时等真实路径 - 别自己写
mockRedisClient实现redis.Cmdable——漏掉Process(ctx, cmd)或错误包装会导致 test pass 但线上 crash
怎么让 miniredis 和你的测试生命周期对齐
常见错误是全局复用一个 miniredis.Runner，导致测试间数据污染或端口冲突。它必须按测试用例粒度启停，且不能依赖 defer（因为并行测试里 defer 执行顺序不可控）。
正确做法是在每个 test 函数开头启动，在 t.Cleanup() 里关闭：
立即学习“go语言免费学习笔记（深入）”；
func TestCacheUser(t *testing.T) {
s, err := miniredis.Run()
if err != nil {
t.Fatal(err)
}
defer s.Close() // 错！这里 defer 不保证在 t.Parallel() 后 clean
t.Cleanup(func() { s.Close() }) // 对
client := redis.NewClient(&redis.Options{
Addr: s.Addr(), // 自动分配空闲端口
})
// ... 测试逻辑
}
- 每次调
miniredis.Run()都会绑定新端口，无需手动管理端口号 - 如果测试中需要预置数据，用
s.Set("key", "val")直接操作内存 store，比发 client 命令更快更稳 - 并发测试（
t.Parallel()）下，s.Close()必须在t.Cleanup()，否则可能关错实例
Mock 时绕不开的 context 超时和重试逻辑
真实 Redis client 默认带 5s 超时和重试，而 miniredis 响应极快，容易掩盖你代码里没正确传递 context.Context 的问题。比如写成 client.Get(ctx, "k").Result() 没检查 error，测试永远不报超时，但线上网络抖动就挂。
必须主动触发超时路径来验证健壮性：
- 用
context.WithTimeout(context.Background(), time.Microsecond)构造必超时 ctx，确认你的 handler 能返回context.DeadlineExceeded - 不要依赖
miniredis模拟网络延迟——它不提供延迟控制；真要测重试，得用redis.FailoverOptions+ 多节点 mock，成本高，一般单元测试里跳过 - 如果业务用了
redis.WithContext()包装 client，mock 时也得保持同构，否则 context 传递链断裂
为什么 DEL、EXPIRE 在 mock 里行为和线上不一致
miniredis 的过期逻辑是惰性删除：只有在 get/set/exists 等访问 key 时才检查 TTL。这意味着 DEL 后立刻 EXISTS 返回 false，但 KEYS * 还能看到已过期 key——这和 Redis 服务端行为一致，但很多人误以为 “过期=立即消失”。
测试里若依赖 KEYS 或 SCAN 列表断言，大概率失败。正确姿势是：
- 避免在测试中用
KEYS—— 它在生产环境禁用，测试也不该依赖 - 验证过期行为，用
GET+time.Sleep(ttl + 10ms)+ 再GET，而不是查 key 是否还在KEYS结果里 -
miniredis不支持CONFIG SET，所以没法开lazyfree-lazy-expire，但普通场景够用
最麻烦的其实是 Lua 脚本——miniredis 支持有限，EVAL 里用 redis.call("EXPIRE",...) 会 panic。真要用脚本，要么切到集成测试跑真 Redis，要么把脚本逻辑拆出单独函数单元测试。
