用 http.Handler 包裹业务逻辑可实现响应缓存，需同时重写 Write 和 WriteHeader 以捕获状态码与 body，非 GET/HEAD 不缓存，key 含 method、path、query、accept，建议设 max-age 并禁用 no-cache。
用 http.Handler 包裹业务逻辑实现响应缓存
Go 标准库没有内置的 HTTP 响应缓存中间件，但可以用组合 http.Handler 的方式低成本实现。核心思路是拦截写入 http.ResponseWriter 的过程，捕获状态码和 body，再按规则决定是否写入缓存（如内存 map 或 Redis）并设置 Cache-Control 头。
常见错误是直接包装 http.HandlerFunc 却忽略 WriteHeader 调用时机——若 handler 先调 WriteHeader(200) 再写 body，而缓存逻辑只在 Write 时触发，就可能漏掉状态码，导致缓存了 500 响应却当成 200 返回。
- 必须同时重写
Write和WriteHeader方法，缓存逻辑统一收口 - 对非 GET/HEAD 请求默认不缓存（避免意外缓存 POST 结果）
- 缓存 key 应包含 method + path + query string + accept header（如需支持 content-negotiation）
- 建议加
max-age且禁用no-cache，避免代理层二次校验
用 sync.Map 实现简单内存缓存时的并发陷阱
sync.Map 看似适合高频读、低频写的缓存场景，但它不支持带过期的原子操作，也缺乏批量清理能力。直接用它存响应 body + header 容易引发内存泄漏或 stale data 问题。
典型表现是：服务运行数小时后 RSS 持续上涨，pprof 显示大量 sync.mapRead 占用 heap；或某个接口更新后，旧响应仍被返回长达数分钟。
立即学习“go语言免费学习笔记（深入）”；
- 不要把原始
[]byte直接塞进sync.Map，需封装结构体并记录写入时间 - 过期检查必须在
Load时做（不能只靠定时 goroutine 清理），否则并发读可能拿到已过期项 - 若缓存项超过几百个，优先考虑
lru-cache类库（如github.com/hashicorp/golang-lru），它自带 TTL 和容量控制 - 注意
sync.Map的Range非快照语义，遍历时可能漏掉新写入项
与 Redis 集成时如何避免缓存穿透和雪崩
用 redis-go（如 github.com/go-redis/redis/v9）做后端缓存时，单纯查不到就回源再写入，会放大 DB 压力。缓存穿透（查不存在的 key）和雪崩（大量 key 同时过期）在 Go Web 中尤为明显，因为 goroutine 调度快，瞬间并发打穿 DB 很容易。
错误做法是每个请求都独立执行 GET → MISS → SELECT → SET 流程，没加锁也没降级。
- 对空结果也缓存（如设为
"null"字符串），并配较短 TTL（如 60s），防止恶意刷不存在 ID - key 过期时间加入随机偏移（如
baseTTL + rand.Intn(300)），避免整点雪崩 - 高并发查同一 key 时，用
redis.SetNX抢锁，抢到的回源，其余等待并轮询 redis（或用本地singleflight.Group拦截） - 务必设置 redis client 的
Timeout和MaxRetries，超时直接走 DB，别卡住整个 handler
用 singleflight.Group 消除重复回源请求
当缓存失效、多个并发请求同时击穿到 DB 时，singleflight 是 Go 生态最轻量的防击穿方案。它本质是用 map + channel 对相同 key 的 call 做合并，只让第一个 goroutine 执行函数，其余等待其返回。
容易忽略的是：它不处理缓存写入，也不管过期逻辑，只是“求值去重”。若忘记在 Do 回调里写回缓存，下次请求还会再击穿。
- key 必须能稳定复现（推荐用
fmt.Sprintf("%s:%s", r.Method, r.URL.String())） - 回调函数内必须包含完整的回源 + 缓存写入流程，否则无意义
- 慎用于耗时极长的操作（如导出大文件），可能阻塞整个 group
- 注意
singleflight不跨进程，集群部署需配合分布式锁或外部缓存协调
