Go高并发API需控资源防雪崩：设http.Server超时与连接限制；禁裸goroutine，用带限流的worker pool；高频JSON用代码生成序列化；慎读request body并复用；全程传context、打trace日志；压测必看pprof。
Go 语言原生支持高并发，但写个能扛住真实流量的 API 接口，光靠 goroutine 和 channel 远不够——关键在控制资源、避免雪崩、减少锁争用、合理复用对象。
用 http.Server 配置超时与连接限制
默认的 http.Server 没有读写超时，一个慢请求或恶意长连接就能耗尽连接池。必须显式设置：
server := &http.Server{
Addr: ":8080",
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 30 * time.Second,
MaxHeaderBytes: 1 << 20, // 1MB
Handler: router,
}-
ReadTimeout从 Accept 到读完 request body 为止，防客户端发一半就卡住 -
WriteTimeout从 response.WriteHeader 开始计时，防 handler 内部阻塞太久 -
IdleTimeout控制 keep-alive 空闲连接存活时间，避免 TIME_WAIT 积压 - 不设
MaxConns？用net/http/pprof观察http_server_open_connections指标，再结合ulimit -n反推上限
避免在 handler 中直接起 goroutine 处理业务
无节制启 goroutine 是最常见误用：它不自带上下文取消、不控并发数、不回收 panic，极易 OOM 或 goroutine 泄漏。
- 用带缓冲的 worker pool 替代裸
go fn()，例如semaphore.NewWeighted(100)（来自golang.org/x/sync/semaphore） - 所有异步任务必须接收
context.Context，并在 handler 返回前调用cancel() - 不要在
http.HandlerFunc里 defer recover() —— 它捕不到 goroutine 内 panic，要用recover包裹 worker 函数体 - 日志打点要带 trace ID，否则并发下日志完全无法关联请求生命周期
JSON 序列化性能陷阱：别总用 json.Marshal
json.Marshal 每次都反射遍历结构体字段，小数据不明显，QPS 上万时 CPU 火焰图里 reflect.Value.Interface 会扎眼地冒出来。
立即学习“go语言免费学习笔记（深入）”；
- 对高频返回结构体（如
User、Order），用easyjson或ffjson生成静态 marshal/unmarshal 方法 - 避免在 struct tag 里写
json:",omitempty"配合指针字段——判断是否为 nil 的开销比你想象中大 - 如果响应体固定且简单（如
{"code":0,"msg":"ok"}），直接拼[]byte或用sync.Pool复用bytes.Buffer - 别用
map[string]interface{}做通用响应体——类型擦除 + 反射双重惩罚
中间件里慎用 io.ReadAll 和 bytes.Buffer 读 request body
想记录请求日志或做签名验签？直接 io.ReadAll(r.Body) 会把原始 r.Body 读空，后续 handler 拿不到数据。
- 必须用
http.MaxBytesReader包一层防止攻击者发超大 body - 若需复用 body，先
bodyBytes, _ := io.ReadAll(r.Body)，再用io.NopCloser(bytes.NewReader(bodyBytes))重置r.Body - 更稳妥做法：在入口 middleware 把 body 复制进
context.WithValue，后续 handler 从 ctx 取，而非反复读原始 Body - 注意：复用 body 会增加内存分配，压测时观察
runtime.MemStats.AllocBytes是否随 QPS 线性上涨
高并发接口真正的难点不在“怎么并发”，而在“怎么不让并发失控”——连接数、goroutine 数、内存分配、锁粒度、上下文传播，每个环节松一扣，压测时就会在某个阈值突然崩掉。上线前务必用 go tool pprof 看 CPU 和 heap profile，而不是只盯着 QPS 数字。
