ristretto需手动调wait()确保set可见，异步写入导致get可能查不到；numcounters应为活跃key数10倍，maxcost须按实际字节估算并传入cost参数；onevict需显式配置且仅淘汰时触发。
Ristretto 不是开箱即用的“设了就跑”缓存，它默认不自动驱逐过期项、不触发淘汰回调、不保证 Get 立即可见——你得手动调 Wait()，否则写入可能被缓冲丢弃。
为什么 Set 之后 Get 不到值？
Ristretto 的 Set() 是异步写入，键值先进入缓冲区，再由后台 goroutine 批量提交。如果没等它刷入，Get() 就查不到。
- 必须在
Set()后显式调用cache.Wait()（适合测试或单次写入场景） - 高并发写入时，更推荐用
cache.SetWithTTL(key, value, cost, ttl)并确保Config.Metrics = true，方便观察缓冲积压 - 若用在 HTTP handler 中，别在每个请求末尾都
Wait()，会阻塞；应依赖 TTL 自动清理 + 合理的MaxCost控制内存水位
NumCounters 和 MaxCost 怎么设才不翻车？
NumCounters 决定频率统计精度，MaxCost 才真正控制内存上限。两者错配会导致命中率骤降或 OOM。
-
NumCounters建议设为预期活跃 key 数的 10 倍（比如预估最多 50 万 key，就设5e6），太小会让 LRU 近似失效 -
MaxCost必须按实际字节数估算：缓存 HTML 片段？按响应体长度算；缓存结构体？用unsafe.Sizeof()或gob.EncodedLen()估下界 - 别写死
MaxCost: 1（1GB）就完事——如果平均 value 是 1KB，那最多只能存 100 万条；而 <code>NumCounters: 1e7却在为 1000 万 key 准备，浪费内存且干扰淘汰
如何安全地在 HTTP handler 中集成 Ristretto？
直接把整个 http.Response body 塞进缓存最危险：没做大小限制、没过滤不可缓存响应、没归一化 key，5 分钟后可能吃光内存。
- 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
- 别在里面做阻塞操作（如发 HTTP 请求、写磁盘），会拖慢整个淘汰流程；需要异步处理就扔进带 buffer 的 channel
最容易被忽略的是：Ristretto 的 “成本” 是你传进去的 cost 参数，不是 value 大小自动计算的。漏传或传 0，MaxCost 就形同虚设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
