Beego中空值缓存必须设极短TTL（如30秒）并用独立前缀（如empty:shop:123）隔离，禁止将nil或空字符串与业务Key共用命名空间，否则会导致Redis内存被无效Key占满、触发LRU误驱逐热点数据。
Beego里空值缓存怎么设才不爆内存
直接把 nil 或空字符串写进缓存，再设个 24 小时 TTL，是 Beego 新手最常踩的坑。后果不是“没效果”，而是 Redis 内存被无效 Key 慢慢吃光，最后触发 LRU 驱逐，把真正该留的热点数据也干掉了。
正确做法是：空值必须带极短且明确的过期时间，且不能和业务 Key 共用同一命名空间。
-
cache.Put("shop:invalid:12345", "EMPTY", 30*time.Second)—— 30 秒足够拦截重复刷请求，又不会堆积 - 避免用
cache.Put("shop:12345", "", 30*time.Second)—— 这会让业务层难以区分“查到空结果”和“查到空缓存” - Beego 的
file缓存适配器不支持多实例，所以所有空值缓存必须和业务缓存走同一个实例，靠前缀隔离（比如empty:shop:12345）
布隆过滤器在 Beego 中怎么嵌入请求链路
Beego 没有内置布隆过滤器中间件，得自己在 Controller 的 Prepare() 方法里插一层。重点不是“加没加”，而是“校验失败后是否还往下走”。很多团队加了但没拦住，是因为只做了日志没 return。
典型错误写法：if !bloom.Contains(key) { beego.Debug("bloom reject:", key) } —— 这只是打日志，请求照进数据库。
- 合法 Key 必须预热进布隆过滤器：启动时从 DB 或配置加载全部有效
shop_id、user_id，调用bloom.Add([]byte(key)) - 请求进来先做
if !bloom.Test([]byte(key)) { this.Abort("404") }，必须 Abort，不能只 log - 注意 Beego 的
this.Ctx.Input.Param(":id")取出的是字符串，要转成一致格式（比如全转小写或统一补零）再喂给布隆过滤器，否则大小写、前导零差异会导致误判
Beego 文件缓存无法多目录？那就别分目录
试图用 cache.NewCache("file", config1) 和 cache.NewCache("file", config2) 创建两个文件缓存实例，只会让后者覆盖前者——这是 Beego cache 模块硬编码的单例行为，改不了，也不该改。
真正可行的隔离方式，是用 Key 前缀 + 统一缓存实例，配合不同过期策略：
- 业务数据用
shop:123，空值用empty:shop:123，统计类用stat:pv:20260821 - 所有 Key 都走同一个
file实例，但清理时可按前缀批量删：cache.DeleteMatch("empty:*") - 如果真需要物理隔离（比如开发/测试环境共用一套 Beego 进程），就换 Redis 驱动，它天然支持多 DB 或 namespace 切分
为什么 Beego 的 GetString 总返回乱码或空
这不是缓存穿透问题，但会放大穿透风险：当 GetString 因编码/序列化不匹配返回空，上层逻辑可能误判为“数据库无数据”，进而跳过缓存直查 DB，形成伪穿透。
根本原因是 Beego 的 file 缓存底层用 gob 序列化，而 GetString 却尝试按 UTF-8 字符串解码字节流。
- 存 JSON 数据时，不要用
Put(key, jsonString, ttl)，改用Put(key, []byte(jsonString), ttl) - 读的时候，用
Get(key)拿interface{}，断言为[]byte后再json.Unmarshal - 或者统一走
cache.NewCache("redis", ...)，Redis 原生存字符串，GetString才真正可靠
