go http服务器性能瓶颈常源于阻塞操作、资源误用和上下文管理不当；需避免同步阻塞调用、正确复用request/responsewriter、合理使用sync.pool、启用http/2并优化客户端连接复用。
Go 的 HTTP 服务器默认性能已经很好，但实际业务中常因阻塞操作、错误复用或资源失控导致吞吐骤降——问题通常不出在 http.ServeMux 或 net/http 本身，而在于你如何组织 handler、管理上下文和释放资源。
避免在 handler 中做同步阻塞调用
数据库查询、外部 HTTP 调用、文件读写若未设超时或未并发控制，会直接拖垮整个 goroutine 池。Go 的 HTTP server 默认为每个请求启动一个 goroutine，但数量无上限，阻塞积累后系统负载飙升、延迟毛刺明显。
- 对外部服务调用必须使用带超时的
context.WithTimeout，例如：ctx, cancel := context.WithTimeout(r.Context(), 800*time.Millisecond) - 不要在 handler 里直接调用
db.QueryRow()等阻塞方法而不检查 error；应统一包装为返回error的函数，并在出错时显式return - 批量 IO（如一次查 10 个用户）优先用
sync.WaitGroup+ goroutine 并发，但需限制并发数（如用semaphore.NewWeighted(5)），避免打爆下游
正确复用 http.Request 和 http.ResponseWriter
http.Request 是一次性的，其 Body 只能读取一次；ResponseWriter 一旦调用 WriteHeader 或 Write，就不能再修改 header。常见错误是试图多次解析 body 或在中间件中重复写入。
- 需要多次读 body（如鉴权 + 业务逻辑）时，先用
io.ReadAll(r.Body)读出字节，再用bytes.NewReader()构造新Body，并替换r.Body - 自定义中间件中禁止调用
w.WriteHeader()后继续调用w.Write()；更安全的做法是包装ResponseWriter实现WriteHeader计数或拦截 - 不要把
*http.Request存到全局 map 或长期缓存里——它包含临时内存（如ParseForm的内部 map），可能引发内存泄漏
用 sync.Pool 缓存高频小对象
在高 QPS 场景下，频繁分配结构体（如日志字段 map、JSON 解析中间 struct、自定义 error）会显著增加 GC 压力。Go 的 sync.Pool 适合缓存生命周期与请求对齐的对象。
立即学习“go语言免费学习笔记（深入）”；
- 定义池时注意类型一致性：例如缓存
*User就不要混入*Order；初始化New函数应返回零值对象，而非随机实例 - 只缓存“创建开销大、大小稳定、不跨 goroutine 长期持有”的对象；切片建议用
make([]byte, 0, 1024)预分配长度，再丢进 pool - 从 pool 获取后务必清空字段（尤其指针/切片），否则残留数据会导致脏读；例如：
u.Name = ""、u.Roles = u.Roles[:0]
启用 HTTP/2 和连接复用，但警惕客户端行为
Go 1.6+ 默认支持 HTTP/2，但需 TLS；明文 HTTP/1.1 下，客户端若不复用连接（如每次新建 http.Client），会触发大量 TIME_WAIT 和握手开销。
- 服务端启用 HTTPS 后，HTTP/2 自动生效；无需额外配置，但证书必须有效（自签名证书需客户端显式信任）
- 客户端务必复用
http.Client实例，并设置Transport.MaxIdleConns（如 100）、MaxIdleConnsPerHost（如 100）、IdleConnTimeout（如 30s） - 警惕某些旧版 iOS 或嵌入式设备客户端强制 HTTP/1.1 且禁用 keep-alive；可通过日志统计
r.Header.Get("Connection")和r.Proto分析真实协议分布
真正卡住性能的，往往不是并发模型本身，而是那些看似无害的 time.Sleep、没关的 rows.Close()、没设 timeout 的 http.Post，以及把 context.Background() 直接传进 handler 的惯性操作。
