本文详解 redis 客户端因自动执行 select 命令切换数据库导致 llen 等命令返回异常值（如 0 而非预期 5）的问题，重点分析 simpleredis 库的行为机制，并提供可验证的修复方案。
在使用 simpleredis 库操作 Redis 时，你可能会遇到一个隐蔽但关键的问题：同一 key 在 redis-cli 中能正确返回 LLEN xyz = 5，而 Go 程序却始终返回 0。表面看是数据不一致或连接异常，实则根源在于库的默认行为——simpleredis 会在每次执行命令前自动发送 SELECT
这意味着：
- 如果你的 key xyz 实际存在于数据库 1（而非 0），而 simpleredis 强制 SELECT 0 后执行 LLEN xyz，它将在空的 db 0 中查找，自然返回 0；
- 而 redis-cli 默认连接 db 0，但你可能已在其他 db（如 db 1）中手动 SELECT 1 并写入了数据，或应用逻辑本身使用了非默认库；
- 其他命令（如 list.GetLastN(4)）看似正常，是因为 simpleredis.NewList(pool, key) 内部已封装了正确的 db 切换逻辑，而裸 Do("LLEN", "xyz") 则直接受 SELECT 干扰。
✅ 验证方法（立即确认问题）：
在 redis-cli 中显式切换并测试：
redis-cli -n 0 # 连接 db 0 127.0.0.1:6379[0]> LLEN xyz # 极可能返回 0 redis-cli -n 1 # 连接 db 1（假设你的数据在此） 127.0.0.1:6379[1]> LLEN xyz # 应返回 5
? 解决方案（二选一）：
方案 1：确保 pool 初始化时使用正确的数据库索引
// ❌ 错误：强制使用 db 0，但数据在 db 1
conn := pool.Get(0) // ← 这里 0 是 db index！
// ✅ 正确：根据实际数据所在库调整索引（例如 db 1）
conn := pool.Get(1)
infoL := HandleError(conn.Do("LLEN", "xyz")).(int64)方案 2：绕过自动 SELECT，直接复用连接执行命令（推荐）
// 获取连接后，先显式 SELECT 目标 DB（更可控）
conn := pool.Get()
defer conn.Close()
// 手动选择正确的数据库（例如 db 1）
HandleError(conn.Do("SELECT", 1))
// 再执行业务命令
infoL := HandleError(conn.Do("LLEN", "xyz")).(int64)
lengthJSON := HandleError(json.MarshalIndent(infoL, "", " ")).([]byte)
print("RETURN LEN = " + string(lengthJSON))
rw.Write(lengthJSON)⚠️ 注意事项：
- simpleredis 的 pool.Get(n) 中参数 n 不是连接池 ID，而是 Redis 数据库编号（0–15 默认），务必与数据实际存储位置一致；
- 若应用多模块共用同一 Redis 实例但分属不同 DB，请统一维护 DB 映射表，避免硬编码；
- 生产环境建议禁用多 DB（databases 1 in redis.conf），改用命名空间（如 user:123:items）提升可维护性；
- 使用 redis-cli --scan --pattern "xyz" 可跨库搜索 key 存在位置（需 Redis 7.0+ 或搭配 --scan 工具）。
通过精准匹配数据库索引，即可彻底解决 LLEN 等命令返回 0 的“幽灵问题”，让 Redis 客户端行为与 CLI 完全一致。
