应使用 c.request().context() 获取标准 context，再套 withtimeout；启动前需用带超时的 ctx 调 ping 验证连通性；key 需清理特殊字符并统一序列化；穿透击穿需业务层显式处理。
echo.Context 里怎么传 redis.Context？
不能直接把 echo.Context 当作 context.Context 用——它只是个包装，底层没实现 Done() 和 Err()，传给 rdb.Get() 会 panic 或静默失效。
正确做法是用 c.Request().Context() 拿到底层标准 context，再套一层超时：
ctx, cancel := context.WithTimeout(c.Request().Context(), 300*time.Millisecond)- 务必在 handler 返回前调
cancel()，否则可能泄漏 goroutine - 别在中间件里提前 cancel，echo 的生命周期和 redis 调用不等长
为什么 echo 启动后第一次 Get 就 timeout？
冷启动时连接池空，首个请求触发建连；若 Redis 地址错、密码错或 SLB 静默断开空闲连接，rdb.Get() 会卡满你设的 timeout，而不是快速失败。
必须在 echo.New() 之后、e.Start() 之前做连通性验证：
- 用带超时的 ctx 调
rdb.Ping(ctx).Err()，不是Ping().Err() - 失败要 log.Fatal，别吞掉错误继续启服务
- 环境变量读取（
REDIS_ADDR、REDIS_PASSWORD）必须在这之前完成
cache key 命名和结构体序列化踩坑点
echo handler 里拼 key 时裸接 c.Param("id") 或 c.QueryParam("q")，Redis 里存进去的 key 可能含冒号、空格、控制字符，后续用 KEYS user:* 都扫不出来。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
结构体缓存更危险：同一 User 结构体，在 A handler 用 json.Marshal 存，B handler 用 gob.Encode 读，解包直接 panic。
- key 拼接前先清理：
strings.ReplaceAll(id, ":", "_")、url.PathEscape(username) - 全局只用一种序列化方式，推荐
json.Marshal+ 导出字段 +json:"field"tag - 加统一前缀，比如
echo:users:profile:，避免和其他服务冲突
穿透/击穿问题不能靠 Redis 自己扛
echo 里写个 rdb.Get(key) 然后判断 nil 就去查 DB，这是最常见也最危险的写法。DB 查不到就空跑一次，下个请求还来，QPS 上千时 DB 直接被打挂。
必须在 Go 层补轻量兜底逻辑：
- 穿透：DB 返回空时，
rdb.Set(ctx, key, "null", 60*time.Second)，读到"null"就当没命中 - 击穿：热点 key 加随机过期偏差，比如
time.Now().Add(30*time.Minute + time.Duration(rand.Intn(60))*time.Second) - 别依赖
SETNX手写锁，用现成的rdb.Set(ctx, lockKey, "1", redis.SetOptions{EX: 10, NX: true})
这些逻辑没法塞进 echo 中间件自动处理，得在每个业务 handler 里显式写清楚——因为缓存策略和业务语义强绑定，抽象过头反而掩盖风险。
