可通过自定义http.roundtripper实现请求级缓存：get请求前查缓存（如freecache），命中则克隆响应（body需bytes.newreader重建，header/statuscode需复制）；未命中则发起真实请求并缓存响应体，键应包含url、accept等关键字段，持久化推荐bolt数据库并支持etag校验。
用 http.RoundTripper 拦截请求并缓存响应
Go 标准库不自带 HTTP 缓存，但可以通过自定义 http.RoundTripper 实现请求级缓存。核心思路是：在发起请求前先查缓存（如 map[string]*http.Response 或带 TTL 的内存缓存），命中则直接返回克隆的响应；未命中则走真实网络，再将响应写入缓存。
注意点：
-
http.Response的Body是单次读取流，缓存前必须用io.ReadAll读出原始字节，并在返回时用bytes.NewReader重建Body - 必须复制
Header和StatusCode，否则修改会污染原始响应 - GET 请求才适合缓存，需显式过滤非幂等方法（如
req.Method != "GET"） - 建议用
sync.RWMutex保护缓存 map，避免并发读写 panic
用 groupcache 或 freecache 替代原生 map 做内存缓存
纯 map + sync.RWMutex 在高并发或大数据量下易成瓶颈，且无自动过期能力。推荐用成熟库替代：
-
groupcache：Google 开源，支持 LRU + TTL + 分布式一致性哈希（单机场景下可只用本地 cache group） -
freecache：无 GC 压力，比map节省内存，支持毫秒级 TTL，适合高频小响应缓存（如 JSON API） - 避免用
bigcache存储含指针结构体（如完整*http.Response），它只存字节切片，反序列化需额外逻辑
示例（freecache 缓存响应体）：
立即学习“go语言免费学习笔记（深入）”；
cache := freecache.NewCache(100 * 1024 * 1024) // 100MB
key := req.URL.String()
if data, err := cache.Get(key); err == nil {
resp.Body = io.NopCloser(bytes.NewReader(data))
return resp, nil
}
// ... 发起真实请求后
bodyBytes, _ := io.ReadAll(realResp.Body)
cache.Set(key, bodyBytes, 300) // 5分钟 TTL
缓存键生成要考虑 URL、Header、Query 参数差异
同一个 URL 可能因 User-Agent、Accept、查询参数（如 ?lang=zh）返回不同内容，盲目用 req.URL.String() 当 key 会导致缓存污染。
建议做法：
- 默认只对无
Cookie、无Authorization、Accept为application/json的 GET 请求缓存 - 若需支持多 Accept 类型，把
req.Header.Get("Accept")加入 key 计算 - 用
url.Values规范化 query（排序 key，忽略空值），再拼入 URL - 避免把整个
Header序列化进 key——开销大且多数 header（如Connection）不影响响应内容
持久化缓存到磁盘时优先选 bolt 而非 sqlite
需要进程重启后仍保留缓存时，得落盘。Go 生态中 bolt（纯 Go 的嵌入式 kv）比 sqlite 更轻量、无 CGO 依赖、读写更快，适合缓存场景。
关键细节：
-
bolt的 bucket 名建议按域名分（如"https_example_com"），避免单 bucket 过大影响遍历性能 - value 存响应字节 + 元信息（status code、content-type、created timestamp），用
gob或json编码 - 定期用
bolt的ForEach扫描过期 key 并Delete，不要依赖事务自动清理 - 别用
os.WriteFile直接写文件模拟持久化——并发写会损坏数据，也难做原子更新
真正麻烦的是缓存一致性：服务端数据更新了，你本地缓存却不知道。HTTP 的 ETag 和 If-None-Match 头必须实现，否则持久化越久，脏数据风险越高。
