ristretto不是即插即用缓存，必须正确配置numcounters、maxcost和bufferitems，否则命中率暴跌或oom；set默认异步，未wait()前get不到值；close释放goroutine，clear仅清数据；onevict需显式设置并手动释放资源。
直接说结论：Ristretto 不是 NewCache 之后就能用的“即插即用”缓存，必须配对设置 NumCounters、MaxCost 和 BufferItems，否则要么命中率暴跌，要么内存失控甚至 OOM。
为什么 Set 之后 Get 不到值？异步写入没等刷入就查
Ristretto 的 Set() 默认走异步路径：键值先入缓冲区 setBuf，再由后台 goroutine 批量提交。没触发刷新就调 Get()，必然查不到。
- 测试或单次写入场景，必须紧跟
cache.Wait()—— 否则Get()返回false是常态，不是 bug - HTTP handler 中绝不能每个请求都
Wait()，会阻塞吞吐；应依赖SetWithTTL()+ 合理MaxCost控制水位 - 高并发写入时，若
setBuf积压（可通过Metrics.Dropped观察），说明BufferItems太小或写入节奏远超消费能力
NumCounters 和 MaxCost 怎么设才不翻车？别按“感觉”填
NumCounters 控制频率采样精度，MaxCost 才真正约束内存上限。两者错配是生产环境最常见翻车点。
-
NumCounters建议设为预期活跃 key 数的 10 倍（如预估 50 万活跃 key，设5e6）；设太小会让 TinyLFU 准入策略失效，高频 key 被误踢 -
MaxCost必须按 value 实际字节估算：缓存 HTML？用len(body)；缓存结构体？用gob.EncodedLen()或unsafe.Sizeof()估下界 - 别写死
MaxCost: 1（1GB）——如果平均 value 是 1KB，最多存 100 万条；而 <code>NumCounters: 1e7却在为 1000 万 key 预备，浪费内存且干扰淘汰决策
HTTP handler 中怎么安全集成？Key 归一化 + 成本校验 + 状态过滤缺一不可
把 raw http.ResponseWriter body 直接塞进 Ristretto 是线上事故温床。
- key 必须归一化：
strings.ToLower(r.Method + ":" + r.URL.EscapedPath())，去掉无关 query 参数，或只保留?id=123这类语义参数 - 响应体超过 50KB 时跳过缓存（
if len(body) > 50*1024 { return }），改用 Redis 存元数据 - 严格过滤不可缓存响应：
if statusCode = 300 || strings.Contains(h.Get("Cache-Control"), "no-store")，直接跳过Set - 写入前必须传真实成本：
cache.Set(key, body, int64(len(body)))，让MaxCost发挥作用，否则缓存会无视内存限制疯长
Close 和 Clear 有什么区别？关服务前不 Close 就泄漏 goroutine
Clear() 是软重置：清空键值、重置计数器，但后台 goroutine 继续运行；Close() 是硬销毁：停 goroutine、关 channel、释放全部资源。
- 服务优雅退出时，必须调
cache.Close()，否则 goroutine 和 channel 持续泄漏，进程无法真正终止 -
Clear()适合运行时重置缓存状态（如配置热更新后清旧数据），但不会释放底层内存或停止协程 - 调用
Close()后再调Get()或Set()会 panic，务必确保无后续调用
最易被忽略的点：Ristretto 默认不启用 OnEvict 回调，也不自动清理过期项——你得显式传函数给 Config.OnEvict，且要自己处理 value 释放（比如关闭文件句柄、释放 []byte 底层 buffer）。否则缓存淘汰只是“逻辑删除”，内存实际没回收。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
