Go中redis.Client.Get返回*redis.StringCmd，须调.Val()取值且先用errors.Is(err, redis.Nil)判键是否存在；ctx控制全链路超时，建议设100–300ms。
Go 用 redis.Client.Get 读字符串值，返回的是 *redis.StringCmd，不是直接的 string
很多人写完 client.Get(ctx, "key") 就直接拿结果当字符串用，结果 panic 或编译报错。因为 Get 返回的是命令对象，得显式调用 .Val() 才能拿到实际值。
常见错误现象：cannot use cmd (type *redis.StringCmd) as type string，或运行时报 panic: runtime error: invalid memory address（没检查 .Err() 就调 .Val()）。
- 必须链式调用
.Val()获取值，比如client.Get(ctx, "user:name").Val() - 必须先检查
.Err()，Redis 键不存在时不会报错，而是返回redis.Nil错误，此时.Val()返回空字符串，但逻辑上可能要区分“键不存在”和“值为空” - 如果上下文超时或连接断开，
.Err()会返回非nil值，此时调.Val()是未定义行为
遇到 redis.Nil 别直接 panic，这是正常业务状态
Redis 没有“空值”概念，GET 查不到键就返回 nil —— Go-Redis 客户端把这映射成一个特定错误 redis.Nil。它不是异常，是预期中的控制流分支。
典型场景：查用户缓存，键不存在意味着要查 DB 回填；若误当成异常处理，服务就容易雪崩。
立即学习“go语言免费学习笔记（深入）”；
- 判断方式固定：
errors.Is(err, redis.Nil)（别用==直接比对） - 不能只写
if err != nil就 return，否则redis.Nil也会进错误分支 - 如果业务允许空字符串作为有效值，那必须靠
redis.Nil来区分“键不存在”和“值为 ''”
client.Get 的 context 控制的是整个操作生命周期，不是仅限网络超时
传给 Get 的 ctx 不只影响 TCP 连接等待，还覆盖命令排队、响应解析、甚至客户端内部重试（如果启用了）。一旦 ctx 超时或取消，.Val() 和 .Err() 都可能返回对应错误。
性能影响明显：短 timeout（如 10ms）在高延迟或 Redis 负载高时，会导致大量 context deadline exceeded，掩盖真实问题。
- 线上建议设为 100–300ms，低于 50ms 要谨慎，尤其跨机房部署
- 别复用 HTTP request context 直接传给 Redis —— HTTP 超时通常更短，且 cancel 可能早于业务决策
- 如果只是防止单次卡死，用
context.WithTimeout包一层更安全，别动原始 ctx
字符串值里含二进制或 UTF-8 边界数据？.Val() 仍返回 string，但语义由你负责
redis.StringCmd.Val() 总是返回 string 类型，底层把字节数组按 UTF-8 解释。Redis 本身不校验编码，所以如果你存的是 []byte{0xff, 0xfe}，.Val() 会变成包含非法码点的字符串 —— Go 不报错，但后续 JSON 编码、HTTP 输出可能失败。
使用场景：存 token、序列化后的 JSON、纯 ASCII 标识符基本没问题；存图片 base64、加密密文、Protobuf 序列化结果，就得小心。
- 如果确定是二进制内容，改用
client.Get(ctx, key).Bytes()，返回[]byte，避免 UTF-8 解码副作用 - 存之前用
base64.StdEncoding.EncodeToString编码，读出来再解码，比硬扛乱码更可控 - 日志里打
.Val()前先检查是否utf8.ValidString()，能早发现脏数据
redis.Nil 的处理方式和 context timeout 的实际覆盖范围——这两处不细想，线上出问题时很难一眼定位。 
