不能用 sessiondb/redis 做业务缓存，因其专为 iris sessions 设计，仅暴露 set/get 接口、强制 session id 格式 key、不支持 hgetall/zrange/原子操作，且未实现 redis.cmdable 接口，无法满足订单、商品等复杂缓存需求。
直接用 redis.GoRedis() 初始化通用客户端，注入到 Controller 里手动调用，别碰 sessiondb/redis ——它只管 session，不负责业务缓存。
为什么不能用 sessiondb/redis 做业务缓存
sessiondb/redis 是专为 Iris 的 sessions 模块设计的封装，它自动加前缀、序列化、处理过期，但只暴露 Set/Get 接口，且 key 固定为 session ID 格式。你在 Controller 里想缓存用户订单列表、商品详情或排行榜？它不支持 HGETALL、ZRANGE、INCR，也没法传自定义 TTL 或条件写入。
- 常见错误：把
sessiondb/redis.New(...)当成万能 Redis 客户端塞进依赖容器，结果 Controller 调client.Get("key")报错 —— 因为它根本没实现redis.Cmdable接口 - 它内部用的是私有字段包装，不导出底层
*redis.Client，没法做 Lua 脚本、Pipeline 或原子操作 - Prefix 和 Database 配置是全局绑定 session 行为的，你改了会影响所有 session 写入，不是业务缓存该管的事
redis.GoRedis() 怎么初始化并注入到 Controller
Iris 支持两种 Redis 驱动：redis.GoRedis()（基于 github.com/go-redis/redis/v9）和 redis.Radix()。业务缓存必须选前者 —— 它支持 Lua、事务、Pub/Sub、连接池细粒度控制，Radix 连 SETNX 原子锁都得自己拼命令。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 初始化单例 client，**不要在每次请求里 new**：
var redisClient *redis.Client <p>func initRedis() { cfg := redis.Options{ Addr: "127.0.0.1:6379", Password: "your-pass", DB: 2, // 显式指定 DB，别依赖默认值 Timeout: 3 * time.Second, } redisClient = redis.NewClient(&cfg) // 必须 Ping，否则首次调用才报错，延迟暴露问题 if _, err := redisClient.Ping(context.Background()).Result(); err != nil { log.Fatal("Redis connect failed:", err) } }</p> - 注入到 Controller 字段（Iris 12.2.5+ 支持字段注入）：
type ProductController struct { DB *sql.DB Cache *redis.Client `iris:"inject"` } <p>func (c <em>ProductController) Get(ctx iris.Context) { key := "product:123" val, err := c.Cache.Get(ctx, key).Result() if errors.Is(err, redis.Nil) { // 查库 + 写缓存 data := loadFromDB(123) c.Cache.Set(ctx, key, data, 10</em>time.Minute) ctx.JSON(data) } else if err != nil { ctx.StatusCode(500) return } else { ctx.JSON(val) } }</p> - 注意：
redis.GoRedis()的方法全带context.Context参数，别漏传；ctx来自 Iris 的Context，可直接转成context.Context（Iris 封装了.Request().Context()）
Key 设计和过期策略怎么避坑
业务缓存最常崩在 Key 冲突和过期混乱上。Iris 自身不干预 key 命名，全靠你约定。
- Key 必须带业务前缀，比如
"user:profile:" + userID、"order:list:" + userID，避免和 session key（如"iris:sess:xxx"）或其它服务混用 - 别用
time.Now().Unix()当 key 后缀 —— 分布式环境下时钟不同步会导致缓存击穿；用稳定标识，如主键、哈希值、版本号 - TTL 别硬写
time.Hour * 24，用time.Duration变量统一管理，方便灰度调整：const ( UserProfileTTL = 30 * time.Minute OrderListTTL = 5 * time.Minute ) - 高并发读场景下，用
GETEX（v6.2+）或先GET再EXPIRE延长，别用SET覆盖 —— 否则缓存雪崩时大量请求穿透到 DB
分布式锁和幂等性怎么用同一个 client
既然你已初始化了 redis.GoRedis() 单例，它天然支持 Lua 脚本和原子命令，不用额外引包。
- 防重复提交（幂等）：
lockKey := "idempotent:" + reqID script := redis.NewScript(` if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("PEXPIRE", KEYS[1], ARGV[2]) else return 0 end `) ok, err := script.Run(ctx, redisClient, []string{lockKey}, reqID, "30000").Bool() if !ok { ctx.StatusCode(409) return } - 注意：Lua 脚本里用
PEXPIRE（毫秒级），对应 Go 里的time.Millisecond * 30；别用EXPIRE秒级，精度不够 - Redis 开 TLS 时，
Addr要写"rediss://host:6380"，Network仍填"tcp"—— Iris 的redis.GoRedis()底层用的是go-redis，它识别rediss://自动启用 TLS，填"tls"会连不上
真正难的不是连上 Redis，而是让每个 Controller 方法知道“这个 key 该不该缓存”“过期时间设多少才不拖垮 DB”“并发写时谁来删缓存”。这些逻辑没法靠框架自动推断，得在业务代码里显式决策 —— 所以 client 必须是可访问的、类型明确的、生命周期可控的实例，而不是藏在 session 包底下的黑盒。
