选用miniredis是因为单元测试需快速、可重复且不依赖外部服务；它是纯Go实现的内存版Redis，兼容主流命令协议，启动零延迟并支持直接嵌入测试进程。
为什么不用真实 Redis 而选 miniredis
因为单元测试要快、可重复、不依赖外部服务。启动真实 Redis 进程会拖慢测试速度，还可能因端口占用、数据残留、网络波动导致随机失败。而 miniredis 是纯 Go 实现的内存版 Redis，兼容大部分 Redis 命令协议，能直接嵌入测试进程，启动零延迟。
它不是 mock（比如用 gomock 手写接口桩），而是真跑命令、真响应协议——所以你的 redis.Client 完全不用改，连连接地址都只是从 "localhost:6379" 换成 srv.Addr()。
怎么在测试里启动并注入 miniredis
核心是两步：启动服务实例 + 把它的地址喂给你的 Redis 客户端。别手动管理生命周期，用 testify/suite 或普通 func(t *testing.T) 都行，但记得在测试结束时调用 srv.Close()，否则端口可能被占住影响后续测试。
-
srv := miniredis.NewMiniRedis()创建实例，它默认监听随机空闲端口 -
defer srv.Close()必须加，不然并发测试容易报bind: address already in use - 初始化客户端时，把
srv.Addr()当作 Redis 地址传进去，例如：redis.NewClient(&redis.Options{Addr: srv.Addr()}) - 如果代码里用了
redis.Dial（旧版）或redis.NewFailoverClient（哨兵），miniredis不支持——它只模拟单节点 Redis server
miniredis 支持哪些命令？哪些会踩坑
覆盖了常用读写命令（GET/SET/HGETALL/LPUSH/EXPIRE），也支持事务（MULTI/EXEC）、发布订阅（PUBLISH/SUBSCRIBE），但不支持 Lua 脚本（EVAL）、集群命令（CLUSTER）、模块（MODULE）和部分冷门命令（如 CLIENT PAUSE）。
立即学习“go语言免费学习笔记（深入）”；
- 调用未实现命令会返回
ERR unknown command，不是 panic，但你的业务逻辑可能没处理这个错误分支 -
EXPIRE和TTL有效，但时间不会真正流逝——得手动调用srv.FlushDB()或srv.SetTime(time.Now().Add(10 * time.Second))来推进“虚拟时钟” - 如果你的代码依赖 Redis 的原子性边界（比如用
WATCH+EXEC做乐观锁），miniredis的实现和真实 Redis 略有差异，极端并发下行为可能不一致
如何验证测试中 Redis 状态是否符合预期
不能只靠业务函数返回值判断；得直接查 miniredis 内部状态。它提供了 srv.GetKeys()、srv.Get("key")、srv.HGetAll("hash") 这类调试方法，专为测试断言设计。
- 避免用客户端去查——那样绕了一圈，还可能受连接池、pipeline 缓存干扰
- 例如想确认
SET user:123 '{"name":"a"}'是否成功，直接写assert.Equal(t, `{"name":"a"}`, srv.Get("user:123")) -
srv.Keys("*")返回当前所有 key，适合检查是否误删/多写 - 注意：这些方法不走 Redis 协议，是直接读内存，所以即使客户端连接已关闭也能调用
最麻烦的是时间相关逻辑——比如你设了 EXPIRE key 5，5 秒后 key 应该消失。这时候必须显式调用 srv.SetTime(time.Now().Add(6 * time.Second))，再查 srv.Exists("key")，否则永远为 true。
