sync.map 不适合直接做 http 缓存层，因其无过期机制、无容量控制、无缓存击穿保护；应选用 bigcache 或 groupcache 等专业缓存库，或自研时严格封装 ttl 判断与响应体复用逻辑。
为什么 sync.Map 不适合直接做 HTTP 缓存层
直接拿 sync.Map 存响应体或结构体，看似线程安全，实则埋下三类隐患：缓存击穿时无锁保护、过期策略缺失导致内存持续增长、无法统一控制最大容量。它只是并发安全的键值容器，不是缓存组件。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
groupcache或bigcache替代裸sync.Map，二者内置 LRU 驱逐 + TTL + 原子加载（避免重复回源） - 若必须自研，至少封装一层：在
LoadOrStore前检查时间戳，且用time.Now().After(expiry)判断过期，而非依赖 map 本身 - 禁止把
*http.Response或含io.ReadCloser的结构体塞进缓存——它们不可复用，会引发 body 已关闭错误
如何让 http.HandlerFunc 自动支持缓存中间件
核心是拦截请求前查缓存、命中则短路返回，未命中则执行原 handler 并写入缓存。关键在响应体捕获和状态码判断。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
httptest.ResponseRecorder包裹原http.ResponseWriter，避免直接操作真实 response - 只缓存
200 OK且Content-Type为application/json的响应，跳过302、4xx、5xx - 缓存 key 应包含 method + path + query string（用
req.URL.EscapedPath() + "?" + req.URL.RawQuery），忽略 header 差异除非业务强依赖 - 示例片段：
func cacheMiddleware(next http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { key := r.Method + ":" + r.URL.EscapedPath() + "?" + r.URL.RawQuery if cached, ok := cache.Get(key); ok { w.Header().Set("X-Cache", "HIT") w.WriteHeader(cached.StatusCode) w.Write(cached.Body) return } // ... 执行 next 并写入 cache } }
bigcache 初始化时最常踩的三个参数坑
bigcache 的高性能依赖正确配置，但文档没明说某些组合会导致缓存失效或 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
Shards必须是 2 的幂（如 256），否则启动报错"shards number must be power of two" -
LifeWindow设为 0 表示永不过期，但若后续调用Get时 key 已被 LRU 淘汰，不会触发自动回源——需配合外部逻辑重载 -
MaxEntrySize要大于预期 JSON 响应体长度（建议预留 20%），超长写入会静默失败并返回ErrEntryTooLarge，但不抛 panic - 别设
HardMaxCacheSize过小（如
并发场景下缓存更新与删除的原子性怎么保？
当多个 goroutine 同时更新同一 key（如库存扣减后刷新商品详情），仅靠缓存层无法保证最终一致性。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对写密集型 key，用
singleflight.Group包裹回源逻辑，确保同一 key 的多次并发请求只触发一次下游调用 - 删除缓存不能只删本地实例——分布式部署时要用 Redis Pub/Sub 或消息队列广播
invalidate:product:123 - 更新缓存时优先用
Set而非Replace，后者在 key 不存在时不生效，容易掩盖数据未加载问题 - 敏感接口（如用户余额）建议禁用缓存，或改用「读时加锁 + 检查版本号」方式，避免脏读
