最直接方式是用 http.Handler 封装缓存逻辑：通过闭包或结构体实现 ServeHTTP，先查缓存，命中则直接返回；未命中则捕获响应并写入缓存。
用 http.Handler 包裹缓存逻辑最直接
Go 标准库没有内置 Web 缓存中间件，但你可以用一个闭包或结构体封装 http.Handler，在 ServeHTTP 中判断是否命中缓存。关键不是“加缓存”，而是“决定什么时候不走后端”。
func cacheHandler(next http.Handler, cache *ristretto.Cache) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
key := r.Method + ":" + r.URL.Path
if val, ok := cache.Get(key); ok {
if data, ok := val.([]byte); ok {
w.Header().Set("X-Cache", "HIT")
w.Write(data)
return
}
}
// 缓存未命中：捕获响应体再写入缓存
rw := &responseWriter{ResponseWriter: w, body: &bytes.Buffer{}}
next.ServeHTTP(rw, r)
if rw.statusCode >= 200 && rw.statusCode < 300 {
cache.Set(key, rw.body.Bytes(), 10*60) // TTL 10 分钟
}
})
}注意：必须用自定义 ResponseWriter 拦截响应体，否则无法缓存内容；ristretto 是目前 Go 生态中性能和并发安全兼顾得最好的内存缓存库，别用 sync.Map 手搓——它不支持 TTL 和容量淘汰。
Cache-Control 头必须由服务端显式设置
浏览器或 CDN 是否缓存，不取决于你内存里有没有数据，而取决于你返回的 HTTP 头。Go 默认不设 Cache-Control，所以即使你本地缓存了，客户端仍可能反复请求。
w.Header().Set("Cache-Control", "public, max-age=600")
w.Header().Set("ETag", fmt.Sprintf("%x", md5.Sum([]byte(content))))
w.Header().Set("Last-Modified", time.Now().UTC().Format(http.TimeFormat))要点：
-
max-age单位是秒，设为0或no-cache表示“每次验证” - 对静态资源（如
/static/js/app.js）建议用immutable+ 哈希文件名，避免手动控制 -
ETag和Last-Modified配合If-None-Match/If-Modified-Since实现协商缓存，但仅当内容不变时才省带宽，不省 CPU
高频小数据用 ristretto，大响应体慎缓存到内存
把整个 HTML 响应体塞进内存缓存，看似简单，实则危险：
- 10KB 响应 × 1000 并发 = 至少 10MB 内存，没做驱逐会 OOM
-
ristretto的MaxCost是按字节算成本，不是条数；设MaxCost: 100 （100MB）比NumCounters: 1e7更靠谱 - 超过 50KB 的响应（比如带图表的报表页），更适合用 Redis 或 diskv 做外部缓存，内存只存元数据或短时效 key
- 不要缓存含用户身份信息的响应（如
/profile），除非你做了 per-user key 分离，且确认 session 未过期
cache.Set(key, r.Body, ...) 当成万能解法——r.Body 是流，已读就不可重放，必须先 io.ReadAll。
测试缓存行为不能只看日志，要检查真实响应头
本地跑 curl -v http://localhost:8080/api/data，重点看三行：
> curl -v http://localhost:8080/api/data < HTTP/1.1 200 OK < Cache-Control: public, max-age=600 < X-Cache: HIT如果
X-Cache 没出现，说明你的 handler 没生效；如果 Cache-Control 缺失，浏览器根本不会缓存；如果第二次请求没带 If-None-Match，说明前端没走协商流程。别依赖 fmt.Println("cached!")——它掩盖了响应头没写、中间件顺序错、指针被覆盖等真正问题。 
