应为特定业务构造独立http.Client并注入自定义RoundTripper，避免修改http.DefaultTransport；需设置Timeout、复用连接，调用originalTransport.RoundTrip(req)，透传头时用req.Header.Clone()，注意URL.Scheme。
Go 里用 http.RoundTripper 实现代理模式，别直接改 http.DefaultTransport
直接修改 http.DefaultTransport 会影响所有 HTTP 客户端，包括你没意识到的依赖库（比如 Prometheus client、gRPC 的 health check）。应该为特定业务逻辑单独构造 http.Client，并注入自定义 RoundTripper。
常见错误是写完一个带代理逻辑的 RoundTripper 后，忘记设置 Timeout 或复用连接，导致请求卡死或连接耗尽。
- 代理逻辑应封装在独立结构体中，实现
RoundTrip(*http.Request) (*http.Response, error) - 务必调用
originalTransport.RoundTrip(req)而非http.DefaultClient.Do()，否则会绕过连接池 - 若需鉴权头透传，注意
req.Header.Clone()避免并发写 panic - 调试时加日志：检查
req.URL.Host是否被意外重写（比如漏了req.URL.Scheme = "http"）
缓存预读取用 sync.Map 还是 radix/v3？看命中率和 key 生命周期
sync.Map 适合低频写、高频读、key 数量可控（
错误做法是把数据库查询结果全塞进 sync.Map，等内存爆了才想到“是不是该加淘汰策略”。
立即学习“go语言免费学习笔记（深入）”；
- 预读取 key 若来自用户输入（如
user_id），优先选带 TTL 的本地缓存库，比如github.com/eko/gocache/cache或轻量级github.com/bluele/gcache - 若预读取数据固定且只读（如配置项、白名单），
sync.Map+atomic.Value初始化一次即可，省去锁开销 - 避免在预读取 goroutine 中直接调用 DB，要用带 context 的超时控制，否则预热失败会拖慢服务启动
context.WithTimeout 在预读取中不是摆设，但超时值不能拍脑袋定
预读取常被当成“后台任务”，于是用 context.Background() 或设成 30s，结果 DB 延迟抖动时批量预热阻塞主线程，或触发大量重试。实际应按下游 P99 延迟 ×2 设定，并预留 fallback 机制。
- 不要共用同一个
context.Context实例跨多个预读取请求，每个请求应有自己的子 context - 若预读取失败，记录 warn 日志但不 panic —— 缓存未命中仍可走回源逻辑
- 对 Redis 或 etcd 等外部存储做预读时，必须检查
ctx.Err() == context.DeadlineExceeded，而不是只看 error 是否为 nil
代理 + 预读取组合时，最容易漏掉的是请求幂等性校验
当代理层转发请求的同时又触发预读取，如果后端服务没做幂等（比如 POST /order 创建订单），一次用户请求可能因重试或并发预热，造成重复下单。这不是 Go 语言特性问题，而是架构耦合点。
- 代理层转发前，先检查请求 method 和 path 是否属于“可安全预读”的只读接口（如 GET /api/user/
id） - 预读取动作本身必须是幂等的：读 DB → 写缓存，不能包含 INSERT/UPDATE
- 若必须预热写操作结果（如预加载库存变更后的视图），应通过事件驱动（如监听 Kafka topic），而非在 HTTP 请求链路中同步触发
真正难处理的，是那些没打上“只读”标签、但业务语义上不该被预热的接口——它们往往藏在第三方 SDK 里，靠文档很难发现，得靠流量日志反向排查。
