Beego 的 cache/redis 模块易踩坑，推荐直接使用 go-redis 或 redigo；配置需严格符合 JSON 格式，字段名固定为 key、conn、dbNum、password，且 dbNum 和 password 需为字符串并 URL 编码；并发下 IsExist+Get 非原子，结构体序列化隐式且不一致，应自行控制序列化与缓存逻辑。
Beego 自带的 cache 模块支持 Redis，但直接用它容易踩坑：比如配置格式错一个字符就初始化失败、Get/Put 对非字符串值自动序列化不一致、并发下 IsExist 和 Get 不是原子操作。推荐绕过 cache 模块，用 go-redis 或 redigo 直接对接 Redis，更可控。
beego 配置 Redis 连接信息要严格匹配 redigo 的 JSON 格式
Beego 的 cache/redis 驱动底层用的是 redigo，它要求配置字符串必须是合法 JSON，且字段名固定为 key、conn、dbNum、password。常见错误是：
- 把
conn写成address或host—— 会静默失败，NewCache返回nil -
dbNum写成数字0而不是字符串"0"—— 解析失败，报错json: cannot unmarshal number into Go struct field Config.dbNum of type string - 密码含特殊字符（如
@、/）没做 URL 编码 —— 连接时被截断，报invalid password
正确写法示例（放在 conf/app.conf 中）：
redis::address = "127.0.0.1:6379" redis::database = "0" redis::password = "mypass%40123" # @ 编码为 %40 redis::key = "beego_cache"
然后在代码中加载：
import (
"github.com/astaxie/beego/cache"
_ "github.com/astaxie/beego/cache/redis"
)
bm, _ := cache.NewCache("redis", `{"key":"beego_cache","conn":"127.0.0.1:6379","dbNum":"0","password":"mypass%40123"}`)用 go-redis 替代 beego/cache 更适合复杂缓存逻辑
如果你需要 TTL 精确控制、Pipeline、Lua 脚本或连接池自定义，go-redis 是更现代的选择。Beego 不强制绑定 redigo，完全可以自己初始化客户端：
- 安装：
go get github.com/go-redis/redis/v9 - 初始化时用 Beego 配置读取参数，避免硬编码：
beego.AppConfig.String("redis::address") - 注意上下文（
context.Context）传入：所有Set/Get必须带ctx，超时需显式控制 - 不要在每个请求里新建 client —— 全局复用一个
*redis.Client实例即可
简单示例：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
import "github.com/go-redis/redis/v9"
var redisClient *redis.Client
func init() {
addr := beego.AppConfig.String("redis::address")
pwd := beego.AppConfig.String("redis::password")
db, _ := beego.AppConfig.Int("redis::database")
redisClient = redis.NewClient(&redis.Options{
Addr: addr,
Password: pwd,
DB: db,
})
}
// 使用
ctx := context.Background()
err := redisClient.Set(ctx, "user:123", "name:alice", 10*time.Minute).Err()cache.Put/Get 对结构体自动 JSON 序列化有隐式行为
Beego 的 cache 模块对 Put 的 val 参数会自动调用 json.Marshal，Get 则反向 json.Unmarshal。这意味着：
- 传入
map[string]interface{}或 struct，取出后类型是interface{}，需手动断言或指定目标类型 - 如果结构体字段没加
json:tag，可能丢失字段或变成空值 -
time.Time默认序列化为 float 秒数（非 RFC3339 字符串），反序列化会失败 - 并发下
IsExist(key)+Get(key)不是原子的，可能返回nil—— 应改用Get后判断是否为nil
所以，除非你只缓存字符串或简单数字，否则建议跳过 cache 模块，自己用 redisClient.Get(ctx, key).Result() 显式处理序列化。
权限控制中间件里 Redis 缓存 user_id:resource_path 要标准化路径
做 RBAC 权限校验时，缓存 key 建议用 user_id:resource_path，但 resource_path 必须标准化，否则 /api/users/ 和 /api/users 会被当成两个 key：
- 统一去除末尾斜杠：
strings.TrimRight(path, "/") - 转小写（如果路由不区分大小写）：
strings.ToLower(path) - 合并重复斜杠：
regexp.MustCompile(`/+`).ReplaceAllString(path, "/") - 避免带查询参数 —— 权限判断应基于路径和 method，而非完整 URL
另外，缓存变更必须主动清理，不能只靠 TTL。例如管理员修改某用户权限后，立刻执行 redisClient.Del(ctx, "123:/api/orders")，否则最多延迟 10 分钟才生效。
真正麻烦的不是连上 Redis，而是 key 设计、序列化一致性、缓存穿透防护和失效同步 —— 这些在 cache 模块里都被简化掉了，实际项目里得自己补全。
