HTTP缓存不生效主因是未介入WriteHeader/Write阶段且未包装ResponseWriter；groupcache不适合作为Web响应缓存；ETag协商需前置校验；http.Transport是客户端连接复用机制，与服务端响应缓存无关。
为什么 http.Handler 套一层 cache.Handler 通常不生效
因为 Go 标准库的 http.ServeMux 不会自动识别或透传缓存相关头（如 Cache-Control），更不会拦截响应体做缓存写入。直接包装 handler 只是“看起来有缓存逻辑”，实际没触发存储或复用。
真正起效的前提是：你得自己控制响应写出时机，并在 WriteHeader 和 Write 阶段介入。常见错误是只实现了 http.Handler 接口，却没重写 ResponseWriter。
- 必须用自定义
responseWriter包裹原始http.ResponseWriter，捕获状态码和响应体 - 缓存键应包含
method + uri + accept-encoding + query string，忽略无关 header（如User-Agent） - 对
POST/PUT/DELETE默认不缓存，除非业务明确允许（比如幂等查询接口用了 POST） - 注意
Content-Length头可能被缓存层覆盖，需在写入后重新计算或删掉
用 groupcache 替代本地 map 做分布式缓存是否合理
不合理——groupcache 是为 RPC 场景设计的 LRU+一致性哈希库，它没有内置过期机制，也不支持 TTL 或主动失效，且要求所有节点共享相同 key 空间。Web 缓存需要的是带过期、可清理、支持 vary 的响应级缓存。
如果你只是单机部署，用 sync.Map + 定时清理更轻量；如果要跨进程，优先考虑 redis 或 memcached，它们原生支持 EXPIRE、VARY 头解析、以及 stale-while-revalidate 这类高级语义。
立即学习“go语言免费学习笔记（深入）”；
-
groupcache的Get是阻塞调用，不适合高并发 Web 响应路径 - 它不区分
200 OK和304 Not Modified，无法配合 ETag 处理协商缓存 - 若真要用，必须自己封装一层带 TTL 的 wrapper，并定期扫描淘汰，反而增加复杂度
如何正确处理 ETag 和 If-None-Match 协商缓存
关键不是生成 ETag，而是判断「何时跳过业务逻辑直接返回 304」。很多实现把 ETag 计算放在 handler 内部，导致每次请求仍要执行 DB 查询或模板渲染，失去意义。
理想流程是：在进入业务逻辑前，先查缓存 → 解析 ETag → 对比 If-None-Match → 若匹配，立即写 304 并 return。
- ETag 值建议用
md5(content)或fnv.New64a().Write(body).Sum(nil)，避免用时间戳或随机数 - 对动态内容，可基于数据版本号（如
"v1:" + strconv.FormatInt(user.LastModified.Unix(), 10)）构造弱 ETag（加W/前缀） - 务必检查
r.Header.Get("If-None-Match")是否非空，且等于当前 ETag；多个值用逗号分隔，需逐个比对 - 返回
304时不能带响应体，但可以保留Content-Type、Cache-Control等头
为什么 net/http 的 Client.Transport 不适合做服务端响应缓存
因为 http.Transport 是为客户端设计的，它的 RoundTrip 缓存只作用于出站请求（比如你的服务调用第三方 API），和你自己的 HTTP handler 完全无关。把它塞进服务端代码里，既不拦截 incoming 请求，也无法访问 response body。
有人误以为设置 Transport.IdleConnTimeout 或启用 KeepAlive 就是“做了缓存”，其实只是连接复用，和内容缓存毫无关系。
- 服务端缓存必须在
http.Handler层或中间件中实现，而不是 client 配置 - 若想复用连接池提升上游调用性能，那是另一回事，和响应缓存正交
- 混淆这两者会导致调试困难：你以为缓存生效了，结果日志里全是重复 DB 查询
sync.RWMutex 锁粒度、缓存穿透防护、以及 stale-if-error 这类兜底策略，往往比缓存本身更难写对。 
