Go net/http 默认高并发源于goroutine-per-connection模型，关键在于handler中避免阻塞操作；需用context统一超时控制、无锁日志、外层panic恢复及trace排查goroutine泄漏。
Go 的 net/http 默认就是高并发的，关键在别阻塞
Go Web 服务天然支持高并发，并非靠“调优”得来，而是由 net/http 默认使用的 goroutine-per-connection 模型决定的。每个 HTTP 请求在独立 goroutine 中处理，调度开销极小。但前提是：你的 handler 里不能有同步阻塞操作——比如未加超时的 http.Do、无缓冲 channel 等待、或阻塞式文件读写。
常见误判是以为“QPS 上不去 = 并发模型不行”，实际多因业务逻辑阻塞了 goroutine，导致调度器堆积大量等待态 goroutine，最终耗尽内存或触发 GC 压力。
- 用
pprof查看/debug/pprof/goroutine?debug=2，确认是否 goroutine 数量异常增长 - 所有外部调用（DB、RPC、HTTP）必须带超时：
context.WithTimeout+http.Client的Timeout或Context字段 - 避免在 handler 中做密集计算；CPU 密集型任务建议丢给
runtime.Gosched()或拆分到 worker pool
什么时候该自己管理 goroutine 池？
绝大多数场景下，net/http 自带的 goroutine 分发已足够。只有两类明确需求才需引入自定义 worker pool：
- 需要严格限制并发数（如下游 API 限流为 10 QPS，而你每秒收 1000 请求）
- 任务生命周期远长于 HTTP 请求（如上传后异步转码），且需复用资源（DB 连接、GPU 句柄等）
此时推荐用 semaphore.Weighted（golang.org/x/sync/semaphore）而非手写 channel 控制池，它支持带 context 的 acquire、可取消、无竞态风险。不要用固定数量的 for range goroutine 监听 channel —— 容易漏 recover、难监控、无法动态伸缩。
立即学习“go语言免费学习笔记（深入）”；
http.Server 的 ReadTimeout 和 WriteTimeout 已过时
这两个字段在 Go 1.8+ 中已被标记为 deprecated，因为它们无法覆盖 TLS 握手、HTTP/2 流控、流式响应等场景，且容易造成半开连接堆积。
正确做法是用 http.Server.ReadHeaderTimeout + http.Server.IdleTimeout + http.Server.WriteTimeout（注意：仅控制 response 写入，不包含 handler 执行）——但更推荐彻底放弃超时字段，改用 context 在 handler 内部统一控制：
func handler(w http.ResponseWriter, r *http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)
defer cancel()
// 后续所有 DB/HTTP 调用都传入 ctx
}
这样能精确覆盖整个请求生命周期，包括中间件、重试逻辑和子 goroutine。
高并发下日志和 panic 恢复容易被忽略
并发量上来后，log.Printf 的锁竞争会成为瓶颈，而未 recover 的 panic 会导致整个 HTTP server 崩溃（默认行为）。这两点常被跳过，直到压测失败才暴露。
- 替换标准
log为无锁日志库（如zerolog或zap），并禁用 caller 捕获（WithCaller(false)） - 全局 panic 恢复必须放在最外层 middleware：
defer func() { if r := recover(); r != nil { log.Error("panic recovered", "err", r) } }() - 注意：recover 只对当前 goroutine 有效，若你在 handler 里另起 goroutine 做事，需在那个 goroutine 内单独 recover
goroutine 泄漏比 CPU 高更难排查，尤其在错误处理分支里忘了 close channel 或 cancel context —— 建议上线前必跑一次 go tool trace，重点看 goroutine 的 lifetime 分布。
