进阶是解决高并发、可观测、可维护的系统性问题：需自定义http.client并设连接池与超时，用rwmutex/poll优化并发，结构化日志，避免资源泄漏，深入理解连接、内存、上下文生命周期。
进阶不是换框架，而是解决真实高并发、可观测、可维护场景下的系统性问题。
如何避免 http.DefaultClient 在生产环境拖垮服务
很多团队用 http.Get 或未配置的 http.DefaultClient 调第三方 API，结果在压测时连接数暴涨、DNS 解析卡住、超时堆积——根本原因是默认 Transport 几乎不设限：MaxIdleConns=0（即不限制空闲连接）、IdleConnTimeout=0（永不复用），导致每请求新建 TCP 连接。
- 必须自定义
http.Client，至少设置：MaxIdleConns=100、MaxConnsPerHost=50、IdleConnTimeout=30*time.Second - 所有 HTTP 调用必须带
context.Context，防止 goroutine 泄漏（例如上游响应慢，handler 已超时返回，但底层 http.Client 仍在等） - 不要全局复用一个没设超时的 client；建议按下游服务粒度创建不同 client，各自配独立 timeout 和 retry 策略
为什么 sync.Mutex 不够用，而你该用 sync.RWMutex 或 sync.Pool
共享状态（如计数器、缓存 map、配置快照）是 Web 服务最常踩坑的地方。只用 sync.Mutex 锁整个读写路径，会把高频读操作（比如每请求查一次访问次数）强行串行化，吞吐骤降。
- 读多写少场景（如配置热更新、访问统计），优先用
sync.RWMutex：读操作用RUnlock/RLock，允许多个 goroutine 并发读 - 频繁分配小对象（如 JSON 解析后的
map[string]interface{}、HTTP header 缓冲区），用sync.Pool复用，避免 GC 压力；别自己写“对象池管理器”，Go 原生sync.Pool已针对逃逸分析和本地 P 缓存做了深度优化 - 切忌在 handler 中直接修改全局变量（如
visits[r.RemoteAddr]++），即使加了锁，也容易因 panic 导致锁未释放——应封装成带 recover 的原子操作函数
日志不是“打出来就行”，结构化 + 上下文 + 条件输出才是关键
线上服务每秒几百请求，若每个 handler 都调 log.Printf("req: %s, status: %d", r.URL.Path, statusCode)，字符串拼接、系统调用、磁盘 I/O 会吃掉大量 CPU，且日志无法被 ELK 或 Loki 正确解析。
