kratos未内置redis缓存支持，因其遵循“按需组装”设计哲学，所有中间件需开发者显式引入和封装，官方未提供kratos/cache/redis子模块或cacheprovider默认实现。
Kratos 本身不内置 Redis 缓存组件，必须手动集成 redis-go 客户端并自行封装缓存逻辑——直接用 @Cached 或 @EnableCaching 会失败。
为什么 Kratos 没有开箱即用的 Redis 缓存支持
Kratos 的设计哲学是“按需组装”，所有中间件（包括缓存）都由开发者显式引入和注册。它不像 Spring Boot 那样提供 @Cacheable + RedisCacheManager 的自动装配链路。官方未提供 kratos/cache/redis 子模块，也没有 CacheProvider 接口的默认 Redis 实现。
这意味着你不能依赖框架帮你管理连接、序列化、过期策略或空值穿透处理——这些全得自己写。
- 常见错误现象：
undefined: cache.NewRedisCache或注入cache.Cache时 panic，本质是误以为 Kratos 内置了 Redis 缓存能力 - 正确路径：用
github.com/go-redis/redis/v9（推荐 v9，v8 已停止维护）作为底层客户端，再基于kratos/pkg/cache中的cache.Cache接口做适配封装 - 不要用
github.com/gomodule/redigo：它不支持 context 取消，与 Kratos 的超时控制机制冲突，容易导致 goroutine 泄漏
手动封装 RedisCache 实现 cache.Cache 接口
你需要实现 Get、Set、Del、MultiGet 等方法，并确保返回值符合 Kratos 的 cache.Item 结构（含 Value、Expire 字段）。
关键点不是“能不能存”，而是“怎么让缓存行为对 Kratos 的 metrics、trace、error handling 可观测”：
- 所有 Redis 调用必须传入
ctx，且该ctx应来自 Kratos 的transport.Server.Context()或app.WithContext()，否则超时/取消不生效 -
Set方法中，expire参数应转为time.Duration后传给client.Set(ctx, key, value, expire)，不能硬编码time.Minute * 5 - 空值穿透防护需在
Get里显式判断：若redis.Nil返回，且业务层确认 DB 无数据，应主动Set一个空结构体 + 较短过期（如 2min），避免反复击穿 - 键名建议加统一前缀，如
fmt.Sprintf("kratos:%s:%s", env, key)，防止多环境混用 Redis DB 时键冲突
在 service 层安全调用缓存（避免 context 超时丢失）
Kratos 的 transport（HTTP/gRPC）层已自带 context 生命周期管理，但开发者常在 service 方法里另起 goroutine 或漏传 ctx，导致缓存操作不受接口超时控制。
正确做法是把缓存实例注入到 service 结构体，并在每个方法中使用传入的 ctx：
type UserService struct {
cache cache.Cache
db *gorm.DB
}
<p>func (s <em>UserService) GetUser(ctx context.Context, id int64) (</em>User, error) {
key := fmt.Sprintf("user:%d", id)
var u User
if err := s.cache.Get(ctx, key, &u); err == nil {
return &u, nil
}
// 缓存未命中，查 DB
if err := s.db.WithContext(ctx).Where("id = ?", id).First(&u).Error; err != nil {
if errors.Is(err, gorm.ErrRecordNotFound) {
// 写空值防穿透
s.cache.Set(ctx, key, struct{}{}, time.Minute<em>2)
return nil, ErrUserNotFound
}
return nil, err
}
s.cache.Set(ctx, key, u, time.Hour</em>24)
return &u, nil
}</p>
- 切勿在
GetUser内部新建context.Background()：这会让缓存请求脱离接口超时约束，可能造成 Redis 连接堆积 - 注意
s.cache.Get第三个参数是地址（&u），不是值；反序列化失败时它不会报错，而是静默忽略，需检查返回的err是否为nil - 如果缓存 value 是 struct，务必确保字段可导出（首字母大写），否则
json.Unmarshal或gob.Decode会失败且无提示
连接池与故障降级必须显式配置
Kratos 不会帮你管 Redis 连接池参数，也不提供 fallback 机制。线上出问题时，Redis 挂了会导致整个接口不可用——除非你主动兜底。
- 用
redis.Options{PoolSize: 100, MinIdleConns: 10, MaxConnAge: time.Minute * 30}显式设连接池，避免默认值（PoolSize=10）在高并发下成为瓶颈 - 在
Get方法里 catchredis.Nil和redis.TimeoutErr，但对redis.ConnectionClosedError或网络错误，应直接 fallback 到 DB 查询，而不是抛错 - 建议加一层简单熔断：比如 1 分钟内 Redis 错误率 > 30%，自动关闭缓存开关 5 分钟（用
atomic.Bool控制），避免雪崩 - Docker 部署时，
redis://URL 中不要写localhost：容器内 localhost 指向自身，应改用 Docker Compose 中定义的服务名，如redis://redis:6379/0
最易被忽略的是：Kratos 的 cache.Cache 接口不强制要求实现 Increment 或 Exists，但业务中若需要计数或存在性判断，必须在你的 RedisCache 封装里补全，且注意原子性——别用 GET+SET 模拟 INCR，要用 client.Incr 原生命令。
