redis 客户端因自动执行 select 切换数据库索引，可能导致命令作用于空数据库，从而返回错误结果（如 llen 返回 0）；需确保客户端连接与目标 key 所在数据库一致。
在使用 Redis 客户端库（如 simpleredis）时，一个容易被忽视但极具破坏性的行为是：该库会在每次执行命令前，自动发送 SELECT
你观察到的现象完全符合这一机制：
- Go 程序中 LLEN xyz 返回 0 → 表明当前连接被 simpleredis 强制切到了某个不含 xyz 列表的数据库（例如 DB 0），而 xyz 实际存在于其他 DB（如 DB 1）；
- redis-cli 中 LLEN xyz 返回 5 → 因为 redis-cli 默认连接后处于你上次 SELECT 的上下文（或配置的 database 参数），恰好访问的是正确的 DB；
- simpleredis.NewList(pool, key) 等操作正常 → 说明网络、认证、连接池均无问题，且 list.GetLastN() 内部可能已隐式处理了 DB 选择（或 key 恰好也在默认 DB），进一步佐证问题出在 DB 上下文错位，而非数据丢失或命令错误。
✅ 验证与修复方法
1. 显式确认 key 所在数据库
在 redis-cli 中执行：
# 若不确定 xyz 在哪个 DB，可遍历所有 DB（需管理员权限）
for db in {0..15}; do echo "DB $db:"; redis-cli -n $db EXISTS xyz; done或直接检查：
Session Handoff
下载
创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。 时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。 关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接
redis-cli -n 1 EXISTS xyz # 假设怀疑在 DB 1
2. 强制客户端使用正确 DB 索引
simpleredis 的 NewPool 支持传入 dbIndex 参数。请确保初始化连接池时指定与 key 匹配的 DB：
// ✅ 正确：显式指定目标数据库（例如 DB 1）
pool := simpleredis.NewPool("localhost:6379", 1, 10, 0, "", 1) // 最后一个参数为 dbIndex
// ❌ 错误：使用默认 dbIndex=0（即使 key 在 DB 1）
pool := simpleredis.NewPool("localhost:6379", 1, 10, 0, "")3. （临时调试）手动 SELECT 后再执行命令
若无法立即修改连接池配置，可在业务逻辑中显式切换：
conn := pool.Get(0)
HandleError(conn.Do("SELECT", 1)) // 切到 DB 1
infoL := HandleError(conn.Do("LLEN", "xyz")).(int64)
// ...后续处理⚠️ 注意：simpleredis 的 Do() 方法会自动 SELECT，因此上述 SELECT 调用后，后续同连接上的命令仍将保持在 DB 1 —— 但务必确保 conn 未被归还池中（否则下次获取可能重置 DB）。
? 根本原因总结
simpleredis 的设计假定“每个连接池只服务于单一数据库”，因此通过预置 SELECT 来隔离上下文。但若应用混合使用多个 DB（如缓存用 DB 0、会话用 DB 1），而连接池未按 DB 分离，则必然出现跨库查询失败。这不是 bug，而是连接池语义与实际部署不匹配所致。
✅ 最佳实践建议
- 避免跨 DB 混用：生产环境推荐单应用单 DB，通过 key 命名空间（如 cache:xxx, session:yyy）替代 DB 切换；
- DB 感知连接池：若必须多 DB，应为每个 DB 创建独立 simpleredis.Pool 实例；
- 启用 Redis 日志辅助诊断：在 redis.conf 中设置 slowlog-log-slower-than 0 + slowlog-max-len 1000，配合 SLOWLOG GET 查看实际执行的命令流（含隐式 SELECT）。
通过校准数据库索引上下文，即可让 LLEN 及所有其他命令回归预期行为——数据从未丢失，只是“找错了房间”。
