Ristretto能缓解GC压力而sync.Map不行，因其采用分片map+无锁缓冲+TinyLFU驱逐，主动丢弃冷数据，避免堆内存持续增长；sync.Map无淘汰机制，长期驻留堆上导致GC频繁扫描不可达对象。
为什么Ristretto能缓解GC压力，而sync.Map不行
sync.Map底层是原子指针+延迟删除，但所有写入的键值对都长期驻留堆上，没有淘汰机制；当缓存条目持续增长（比如未设TTL或MaxCost失控），GC会频繁扫描大量不可达但尚未清理的旧条目，触发STW时间上升。Ristretto则不同：它用分片map + 无锁缓冲 + TinyLFU采样驱逐，冷数据在内存水位逼近MaxCost时被主动丢弃，不依赖GC回收——这意味着对象生命周期可控，堆内存曲线更平滑。
必须显式设置MaxCost并按字节估算成本
很多人误把NumCounters当内存上限，结果缓存几百个大JSON响应就OOM。真实内存控制靠MaxCost，它不是“条目数”，而是你愿意为缓存付出的总字节数。
- HTTP响应体缓存：用
len(body)作为cost传给Set() - 结构体缓存：用
gob.EncodedLen(v)或unsafe.Sizeof(v) + 预估序列化开销 - 绝对不要写
MaxCost: 1——这等于只允许1字节，Set直接静默失败 - 推荐起步值：
MaxCost: 100 * 1024 * 1024（100MB），再根据监控调整
避免把大响应体塞进Ristretto
本地缓存不是垃圾桶。一个500KB的HTML页面塞进去，1000次请求就吃掉500MB，GC立刻报警。Ristretto适合高频、小体积、结构化数据（如用户配置、地区列表、API元数据）。
- 响应体超过
50 * 1024字节（50KB）时，跳过本地缓存，改用Redis存摘要或元数据 - 缓存前检查
statusCode和Cache-Control头，no-store或5xx响应一律不进缓存 - key必须归一化：
strings.ToLower(r.Method + ":" + r.URL.EscapedPath())，去掉动态查询参数
异步写入与Wait()的取舍
Set()默认异步，值先进缓冲区，后台goroutine刷入。这提升了吞吐，但也带来可见性问题：短生命周期服务（如CLI工具、单元测试）中，不调cache.Wait()会导致Get不到刚Set的值，进而反复回源加重DB压力——而这又间接拉高GC频率（更多临时对象生成）。
- HTTP handler长周期服务：通常不用
Wait()，请求耗时天然覆盖刷入延迟 - 测试/命令行场景：Set后必须紧跟
cache.Wait()，否则逻辑错乱 - 高并发写入时慎用
Wait()：它会阻塞，反而拖慢整体吞吐
Ristretto本身不制造GC压力，但用错方式（比如缓存大响应体、不设成本、忽略状态码过滤）会让它变成GC放大器。真正关键的不是“用了Ristretto”，而是你是否让每一条缓存都带着明确的成本、寿命和用途进入内存。
