sessiondb/redis不能当业务缓存用，因其仅为Iris session模块专用封装，不兼容通用Redis命令、不支持原子操作与自定义TTL；应改用go-redis/v9单例客户端并正确注入使用。
别用 sessiondb/redis 做业务缓存——它根本不是给你干这个的。 你塞个 Get("order:123") 进去，大概率 panic，因为它的接口不兼容通用 Redis 操作，也不支持 HGETALL、ZRANGE、Lua 脚本这些抽奖、排行榜、库存扣减必需的功能。
为什么 sessiondb/redis 不能当业务缓存用
它只是 Iris sessions 模块的专用封装，内部硬编码了 session ID 格式、自动加前缀、强制序列化/反序列化逻辑。你没法传自定义 TTL，不能指定 DB，更没法调 INCR 或 SETNX。它没实现 redis.Cmdable 接口，所以所有 go-redis/v9 的原子命令都用不了。常见错误是：在 Controller 里注入一个 sessiondb/redis.Client，然后调 client.Get("key")，结果直接报 undefined method Get。
用 redis.GoRedis() 初始化单例客户端
必须走 github.com/go-redis/redis/v9，这是 Iris 官方推荐且唯一支持完整命令集的驱动。关键点是：
- 全局只初始化一次，不要在每次请求或每个 Controller 里 new
- 显式设置
DB字段（比如DB: 2），别依赖默认值，避免和 session 冲突 - 必须调
Ping()主动探测连接，否则首次调用才暴露网络问题，延迟失败 - 超时设短些（如
Timeout: 3 * time.Second），防止慢查询拖垮整个 HTTP 请求
var redisClient *redis.Client
<p>func initRedis() {
cfg := redis.Options{
Addr: "127.0.0.1:6379",
Password: "your-pass",
DB: 2,
Timeout: 3 * time.Second,
}
redisClient = redis.NewClient(&cfg)
if _, err := redisClient.Ping(context.Background()).Result(); err != nil {
log.Fatal("Redis connect failed:", err)
}
}把 *redis.Client 注入到 Controller 字段
Iris 12.2.5+ 支持结构体字段自动注入，比手动传参干净得多。Controller 定义里直接声明字段：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
type LotteryController struct {
iris.Controller
Redis *redis.Client `inject:""`
}
<p>func (c *LotteryController) Draw() {
// 直接用 c.Redis.Do() 或 c.Redis.Get() 等任意命令
result, _ := c.Redis.Get(context.Background(), "prize:stock:101").Result()
}注意：inject:"" 是 Iris 的字段注入标记，不是字符串内容；确保你在 app.Register 或 app.ConfigureContainer 中注册了该 Controller 类型。
缓存策略要匹配真实场景，不是所有数据都适合放 Redis
高频读、低频写、有明确过期逻辑的数据才值得缓存。比如：
- 用户抽奖次数限制 → 用
INCR+EXPIRE原子组合，防并发超限 - 奖品库存 → 必须 Lua 脚本一次性完成「查库存→扣减→返回结果」，避免竞态
- 商品详情页 → 可用
GET/SETEX，但注意大字段（如 HTML 片段）会吃内存，优先压缩或改用 CDN
真正容易被忽略的是缓存穿透和雪崩：没做空值缓存，恶意请求查不存在的 user:9999999 会直击 DB；大量 key 同一时间过期，会导致瞬间回源压垮 MySQL。这两个点不加防护，再快的 Redis 也救不了接口。
