进阶是解决高并发、可观测、可维护的系统性问题：需自定义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 正确解析。
立即学习“go语言免费学习笔记（深入）”；
- 禁用
log包，用zerolog或zap；初始化时启用缓冲：zerolog.NewConsoleWriter(zerolog.ConsoleWriterConfig{Buffered: true}) - 每请求注入唯一
trace_id，通过中间件写入 context，并在所有日志中自动携带：logger.With().Str("trace_id", getTraceID(r)).Str("path", r.URL.Path).Int("status", statusCode).Send() - 非关键日志（如 debug 级别）必须加开关判断：
if cfg.Debug { logger.Debug().Str("body", string(body)).Send() }，否则 body 字节切片可能触发大内存分配
静态文件、模板、数据库连接——三类最容易被忽略的资源泄漏点
它们不报 panic，但会让服务缓慢退化：内存持续上涨、连接耗尽、响应延迟升高，直到某次发布后突然雪崩。
- 静态资源别用
os.ReadFile加载再w.Write，改用http.FileServer或http.ServeFile，它们内部用io.Copy流式传输，不全量加载进内存 - HTML 模板务必预编译：
template.Must(template.ParseGlob("templates/*.html"))放在init()或 main 开头，避免每次请求都 parse - 数据库连接池必须显式调
db.SetMaxOpenConns(20)和db.SetMaxIdleConns(10)；不设限时，database/sql默认无限增长，很快打满 MySQL max_connections
真正卡住进阶的，往往不是语法或框架，而是对「连接生命周期」「内存逃逸」「上下文传播」这些底层契约的理解偏差。写完能跑 ≠ 写完能扛住流量，上线前至少要问一句：这个 goroutine 什么时候结束？这块内存谁来回收？这次调用超时后，下游还在等吗？
