Golang中net/http标准库ServeHTTP函数的并发模型解析-Golang-PHP中文网

go 的 http 服务器为每个新 tcp 连接自动启动一个独立 goroutine 处理请求，而非每个 http 请求；http/1.1 复用连接时多个请求串行处理，http/2 下单连接内请求可并行 dispatch 到不同 goroutine。

golang中net/http标准库servehttp函数的并发模型解析

每个 HTTP 请求都自动运行在独立 goroutine 中

Go 的 net/http 服务器默认就并发，不需要你手动 go handler(w, r)。只要调用 http.ListenAndServe 启动服务，底层监听循环一旦 Accept 到新连接，就会立刻启动一个 goroutine 去处理该连接上的请求（包括复用连接里的多个请求）。这意味着：即使你只写了一个 http.HandleFunc，它也会被并发调用。

常见错误现象是误以为“没加 go 就不并发”，结果在 handler 里做耗时操作（比如 time.Sleep(5 * time.Second)），发现多个请求仍能同时响应——这正是 goroutine 自动调度的结果。

浏览器复用 TCP 连接（HTTP/1.1 默认开启 Keep-Alive）时，同一连接上的多个请求仍由同一个 goroutine 按序处理；但不同连接一定走不同 goroutine
HTTP/2 下支持真正的多路复用，单连接内多个请求可并行 dispatch 到不同 goroutine（取决于 Go 版本和 TLS 配置）
goroutine 启动开销极小（初始栈仅 2KB），所以千级并发连接不会导致内存爆炸

http.ServeHTTP 方法签名与实际调用时机

ServeHTTP 是 http.Handler 接口定义的方法，签名是 ServeHTTP(http.ResponseWriter, *http.Request)。它不是你主动调用的函数，而是由 net/http 内部在 goroutine 中反射调用的入口点。

例如你注册了 http.HandleFunc("/api", myHandler)，本质是把 myHandler 包装成一个实现了 Handler 接口的匿名结构体，其 ServeHTTP 方法内部就是调用你的函数。真正触发执行的，永远是 server.go 里的 srv.Serve 循环中那一行：go c.serve(connCtx)。

Python3.6标准库参考手册（PDF版）

下载

不要在 ServeHTTP 实现里再起 goroutine 去调用自身——这属于重复调度，可能破坏上下文取消或 panic 捕获逻辑
若需异步执行（如发消息到队列、记录审计日志），可以另起 goroutine，但要确保不依赖 ResponseWriter 或已结束的请求上下文
自定义 Handler 时，ServeHTTP 方法内应尽量避免阻塞，否则会卡住整个连接 goroutine（尤其影响 HTTP/1.1 复用场景）

GOMAXPROCS 对 HTTP 并发吞吐的实际影响有限

GOMAXPROCS 控制的是 P（Processor）数量，即 Go 调度器可并行执行用户代码的操作系统线程数。但它**不控制 goroutine 数量**，也不决定“有多少请求能同时处理”。

HTTP 并发能力主要受三方面制约：操作系统文件描述符上限、内存容量、以及 handler 本身的 I/O 阻塞程度。设 GOMAXPROCS=1 时，Go 仍能跑数万 goroutine，只是它们在单个 OS 线程上协作式调度（遇到 I/O 自动让出）；而设为 CPU 核心数，只是让计算密集型 handler 更充分榨干 CPU。

典型 Web handler 多数时间在等数据库、RPC 或磁盘 I/O，此时 GOMAXPROCS 值对 QPS 几乎无影响
若 handler 里有大量纯 CPU 计算（如图像压缩、加密解密），适当提高 GOMAXPROCS 可提升吞吐，但要注意 NUMA 和线程切换开销
生产环境一般无需显式设置，Go 1.5+ 默认设为 runtime.NumCPU()，已经足够合理

连接复用与请求阻塞的真实边界在哪

关键分水岭不在 Go 代码，而在 HTTP 协议层和客户端行为。HTTP/1.1 默认启用连接复用，浏览器会把多个请求塞进同一个 TCP 连接；Go 的 net/http 对每个连接只启一个 goroutine，因此这些请求只能串行处理——这就是所谓“连接级阻塞”。

验证方式很简单：用 curl -H "Connection: close" 强制关闭连接，或用 ab -c 10（Apache Bench）发起 10 个并发连接，你会看到所有请求真正并行执行；但用浏览器访问同一页面加载 5 个资源，默认走 1~2 个连接，后几个资源就得排队。

解决办法不是改 Go 代码，而是升级到 HTTP/2（Go 1.6+ 原生支持 TLS 下的 HTTP/2），或在反向代理层（如 Nginx）配置 keepalive_requests 限制单连接请求数
不要试图在 handler 开头加 time.Sleep 来“模拟并发”，那只会放大串行效应，误导性能判断
真要压测并发能力，请用 hey -z 10s -c 100 http://localhost:8080/ 这类工具，它默认建多连接，才能反映 goroutine 调度真实表现

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！