Ristretto不是“设了就用”的傻瓜缓存，必须配置NumCounters、MaxCost、BufferItems并显式启用Metrics和OnEvict才能保障高命中率；其Set()异步写入，未Wait()前Get()返回false属正常行为。
直接说结论：Ristretto 不是 set 了就能用的“傻瓜缓存”，它默认不保证 Set 后立刻 Get 到，也不自动淘汰过期项——必须配对设置 NumCounters、MaxCost、BufferItems，并显式启用 Metrics 和 OnEvict 才能发挥高命中率优势。
为什么 Set 之后 Get 不到值？
Ristretto 的 Set() 是异步写入：先写进无锁缓冲区，再由后台 goroutine 批量刷到分片 map。没等刷完就 Get()，自然查不到。
- 单元测试或短生命周期服务中，必须紧跟
cache.Wait()——否则Get()返回false是正常行为，不是 bug - HTTP handler 中别每个请求都
Wait()，会阻塞；应依赖SetWithTTL()+ 合理MaxCost控制内存水位 - 高并发写入时，更推荐用
cache.SetWithTTL(key, value, cost, ttl)，避免手动Wait()带来的延迟抖动
NumCounters 和 MaxCost 怎么设才不翻车？
NumCounters 决定 TinyLFU 准入精度，MaxCost 才真正控制内存上限。两者错配会导致命中率暴跌或 OOM。
-
NumCounters应设为预估活跃 key 数的 10 倍（比如预计 100 万活跃 key，设1e7），太小会因哈希冲突误拒高频 key -
MaxCost必须按实际字节估算：缓存 HTML？用len(body)；缓存结构体？用gob.EncodedLen()或unsafe.Sizeof()估下界 - 别写死
MaxCost: 1（1GB）——如果平均 value 是 1KB，最多存 100 万条；而 <code>NumCounters: 1e7却在为 1000 万 key 准备，浪费内存且干扰淘汰
如何在 HTTP handler 中安全集成 Ristretto？
直接把 http.Response.Body 塞进去最危险：没限大小、没过滤不可缓存响应、key 没归一化，5 分钟可能吃光内存。
立即学习“go语言免费学习笔记（深入）”；
- key 必须归一化：
strings.ToLower(r.Method + ":" + r.URL.EscapedPath())，去掉查询参数，或只保留必要参数（如?id=123） - 响应体超过 50KB 时跳过缓存：
if len(body) > 50*1024 { return }，改用 Redis 存元数据 - 严格检查状态码和 header：
if statusCode >= 300 || strings.Contains(h.Get("Cache-Control"), "no-store")，直接跳过 - 写入前加成本校验：
cache.Set(key, body, int64(len(body)))，让MaxCost真正起作用
OnEvict 回调为什么没触发？
OnEvict 默认是 nil，Ristretto 不会主动调用它——哪怕 key 被淘汰了，你也收不到通知。
- 必须在
ristretto.Config中显式传入函数：OnEvict: func(key string, value any, cost int64) { log.Printf("evicted %s", key) } - 它只在**被淘汰时**触发，不是“过期时”；TTL 到期只是标记为可淘汰，真正触发要等到空间不足、后台扫描到该 entry
- 别依赖
OnEvict做业务清理逻辑（如删 DB 关联记录），因为触发时机不确定；它更适合做监控或 debug
最容易被忽略的是：TinyLFU 准入策略在 Set 时就可能拒绝写入，而你完全感知不到——Set() 不报错，但 Metrics().Sets 会远小于 Metrics().Gets。这时候得看 Metrics().Admissions 是否偏低，再调大 NumCounters。
