miniredis 默认不监听tcp端口，需用m.addr()获取动态地址而非硬写127.0.0.1:6379；测试中数据不自动重置，应每例新建实例或调用flushall()；其对watch、pipeline错误处理、scan游标等行为与真实redis不一致，非全量模拟器。
miniredis 启动后连接不上，redis.Dial 报 dial tcp 127.0.0.1:6379: connect: connection refused
miniredis 默认不监听 TCP 端口，它是个纯内存的 Go 对象，不是真实进程。直接连 127.0.0.1:6379 肯定失败。
正确做法是用它提供的 Addr() 方法拿到一个临时监听地址（通常是 127.0.0.1:XXXX），再传给你的 Redis 客户端：
- 启动时调用
m := miniredis.NewMiniRedis()，然后m.Start() - 获取地址必须用
m.Addr()，不是硬写"127.0.0.1:6379" - 如果你用的是
github.com/go-redis/redis/v8，构造redis.Options{Addr: m.Addr()} - 如果用老版
github.com/gomodule/redigo/redis，则redis.Dial("tcp", m.Addr())
测试中多个 test case 共享同一个 miniredis 实例，数据互相污染
miniredis 实例是可复用的，但它的数据状态不会自动重置。一个 test case 写入了 key1，下一个 test 就能读到——这不是 bug，是设计如此。
解决方法很简单，每个 test case 创建独立实例，或者显式清空：
立即学习“go语言免费学习笔记（深入）”；
- 推荐：在
func TestXxx(t *testing.T)开头新建m := miniredis.NewMiniRedis()，并调用m.Start() - 如果想复用（比如为了加速），在每个 test 开头加
m.FlushAll() - 注意
FlushAll()是同步操作，不影响并发安全；但别在 goroutine 里误调m.Close()，否则后续操作 panic
用 miniredis 测试 pipeline 或事务（EXEC）时行为和真实 Redis 不一致
miniredis 支持 MULTI/EXEC 和 pipeline，但实现比 Redis 简化很多。比如它不校验命令语法、不模拟网络拆包、也不处理 WATCH 的乐观锁逻辑。
典型坑点：
-
WATCH key+EXEC在 miniredis 中永远成功，真实 Redis 可能返回 nil；别靠它测并发冲突逻辑 - pipeline 中某条命令出错（如对 string 执行
HGETALL），miniredis 会继续执行后续命令，而真实 Redis 的 redis-go 客户端默认会中断 pipeline 并返回 error - 不支持
SCAN游标迭代的完整语义，SCAN 0 MATCH *可能一次性返回全部 key，无法测分页逻辑
替换原有 Redis 客户端时，redis.Client 初始化失败或 panic
常见原因是没传对参数，尤其是 v8 版本的 redis.NewClient() 对 Addr 字段敏感，且要求非空。
实操检查项：
- 确保
m.Start()已调用，否则m.Addr()返回空字符串，redis.NewClient()会 panic - v8 客户端必须用
redis.NewClient(&redis.Options{Addr: m.Addr()})，不能漏掉&redis.Options{}这层包装 - 如果原代码用了密码（
Password）、DB 编号（DB），miniredis 默认不校验这些字段，但你得显式设为""或0，否则某些客户端版本会拒绝连接 - 不用关 client，但测试结束要调
m.Close()，否则可能泄漏 goroutine（尤其跑go test -race时会报 warn）
miniredis 不是 Redis 的全量模拟器，它只覆盖常用命令和线性执行路径。真正涉及集群、Lua 脚本、stream、module 的场景，得切回集成测试。这点容易被忽略——mock 得越顺，越要警惕它没拦住的边界。
