http server 默认并发足够，但i/o阻塞（如api调用、db查询）会导致goroutine挂起、调度压力上升；应通过pprof定位瓶颈，用context超时、信号量限流、结构化日志等优化。
为什么 http.Server 默认并发已足够，但你仍会卡在 I/O 上
Go 的 http.Server 本身是并发安全的，每个请求默认由独立 goroutine 处理——但这不等于“快”。真正拖慢 Web 请求的，往往是下游依赖：调用外部 API、查数据库、读文件。这些操作是阻塞 I/O，goroutine 会在等待时挂起，但不会释放 OS 线程，大量并发请求堆积后，调度器压力上升，延迟反而升高。
实操建议：
- 先用
pprof定位瓶颈：运行go tool pprof http://localhost:6060/debug/pprof/block，看是否大量 goroutine 停留在net/http.(*persistConn).readLoop或database/sql.(*DB).query - 确认是否真需要“更多并发”：如果 QPS 上不去但 CPU 不高，大概率是 I/O 等待，不是 goroutine 不够
- 避免盲目增加
http.Server.ReadTimeout或WriteTimeout，超时设太长会让坏请求长期占着连接
context.WithTimeout 是并发控制的第一道防线
没有上下文控制的并发请求，就像放养的 goroutine：发起后无法取消、超时后还在等响应、错误堆叠导致内存泄漏。所有对外 HTTP 调用必须套一层 context.WithTimeout。
示例（调用第三方用户服务）：
立即学习“go语言免费学习笔记（深入）”；
ctx, cancel := context.WithTimeout(r.Context(), 800*time.Millisecond)
defer cancel()
resp, err := http.DefaultClient.Do(req.WithContext(ctx))
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
// 记录超时，返回降级响应
http.Error(w, "service unavailable", http.StatusServiceUnavailable)
return
}
http.Error(w, "bad gateway", http.StatusBadGateway)
return
}
注意点：
-
context.WithTimeout的时间应明显短于http.Server.WriteTimeout（比如后者设 5s，这里设 800ms），否则超时由服务器强制断开，客户端得不到明确错误 - 不要复用同一个
context.Background()启动多个 HTTP 请求——它们无法被统一取消 - 若需并发发多个请求（如聚合数据），用
context.WithCancel+sync.WaitGroup更可控
用 semaphore 限流比无脑 go fn() 更稳
直接对每个请求启动 goroutine 处理子任务（比如查 3 个微服务），看似并发，实则可能瞬间拉起数千 goroutine，压垮下游或触发 GC 频繁停顿。你需要的是“可控并发”，不是“最大并发”。
推荐用轻量信号量（如 golang.org/x/sync/semaphore）限制同时进行的外部调用数：
var sem = semaphore.NewWeighted(10) // 最多 10 个并发 HTTP 调用
func fetchUser(ctx context.Context, id string) ([]byte, error) {
if err := sem.Acquire(ctx, 1); err != nil {
return nil, err
}
defer sem.Release(1)
req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com/user/"+id, nil)
resp, err := http.DefaultClient.Do(req)
// ... 处理响应
}
关键差异：
- 不用
runtime.GOMAXPROCS调整——它只影响 OS 线程数，不影响 goroutine 调度公平性 - 信号量粒度按“下游资源”设：数据库连接池大小、第三方 API QPS 配额、文件句柄数
- 别把信号量放在 handler 入口（会阻塞整个请求），而应放在真正发 HTTP 或 DB 查询前
JSON 解析和模板渲染是隐性并发杀手
很多人以为并发瓶颈只在 I/O，但 json.Unmarshal 和 html/template.Execute 在大数据量下也吃 CPU。当 100 个请求同时解析 2MB JSON，GC 会频繁标记-清除，goroutine 调度延迟飙升。
优化方向：
- 对高频结构体用
encoding/json的Unmarshal+struct标签预定义字段，避免map[string]interface{}反射开销 - 模板提前
ParseFiles并复用*template.Template实例，不要每次请求都template.New().Parse(...) - 考虑用
github.com/bytedance/sonic替代标准库 JSON（性能高 2–5 倍，但需注意不支持所有json.RawMessage场景）
最易被忽略的一点：日志。用 log.Printf 打印完整请求体或响应体，在高并发下会锁住 stdout、触发大量字符串拼接和 GC。换成结构化日志（如 zerolog）并关闭非必要字段输出。
