本文详解 Go net/http 服务器的并发模型本质，澄清“每连接一协程”的常见误解，并通过限流、连接复用、工作池（Worker Pool）等工程化手段，实现百万级 QPS 的稳定服务。
本文详解 go `net/http` 服务器的并发模型本质，澄清“每连接一协程”的常见误解，并通过限流、连接复用、工作池（worker pool）等工程化手段，实现百万级 qps 的稳定服务。
Go 的 net/http 服务器默认采用“每个 HTTP 连接（更准确地说，是每个 HTTP 请求）启动一个 goroutine”的模型——但这并不意味着它会无节制地创建协程。实际上，Go 的 http.Server 内部使用 runtime.Goexit() 驱动的轻量级协程，且其调度由 Go 运行时高效管理。单机轻松支撑数万并发连接，但面对百万级 QPS 场景（如 1M RPS），单纯依赖默认模型仍存在风险：内存开销增长、GC 压力上升、上下文切换成本增加，甚至因未受控的业务逻辑阻塞导致 goroutine 泄漏。
因此，关键不在于禁止 goroutine 创建，而在于对资源进行显式编排与节流。以下是推荐的三层应对策略：
✅ 1. 基础层：配置 Server 参数控制连接生命周期
server := &http.Server{
Addr: ":8080",
Handler: mux,
ReadTimeout: 5 * time.Second, // 防止慢请求长期占用
WriteTimeout: 10 * time.Second, // 防止响应写入卡顿
IdleTimeout: 30 * time.Second, // 自动关闭空闲长连接
MaxConns: 10000, // Go 1.19+ 支持，硬性限制最大连接数
}
⚠️ 注意：MaxConns 是 Go 1.19 引入的关键特性，可有效防止连接洪泛；旧版本需结合 net.Listener 包装器（如 limitlistener）手动限流。
✅ 2. 中间层：引入 Worker Pool 控制 CPU/IO 密集型任务
当请求需执行耗时操作（如数据库查询、RPC 调用、文件处理），应避免在 HTTP handler 中直接阻塞。此时，将任务投递至预分配的 goroutine 池，实现资源可控的异步调度：
type WorkerPool struct {
tasks chan func()
wg sync.WaitGroup
}
func NewWorkerPool(workers int) *WorkerPool {
p := &WorkerPool{
tasks: make(chan func(), 1024), // 有缓冲通道防阻塞
}
for i := 0; i <p>该模式天然支持同步/异步混合场景：同步响应可通过 sync.WaitGroup 或 chan struct{} 等待完成；异步响应则直接返回 202 Accepted 并后台执行。</p><h3>✅ 3. 架构层：横向扩展 + 连接复用 + CDN 缓存</h3>
- 单机瓶颈始终存在，建议搭配反向代理（如 Nginx）做连接复用与 TLS 卸载；
- 使用负载均衡器（如 HAProxy、Kubernetes Service）分发流量至多个 Go 实例；
- 对静态资源、API 结果启用 Redis 缓存或 CDN，降低后端压力；
- 关键接口实施速率限制（如 golang.org/x/time/rate）和熔断（如 sony/gobreaker）。
最后提醒：Go 的高并发优势源于其调度器与语言原生支持，而非“无限创建 goroutine”。真正的高性能 Web 服务，是合理配置、主动限流、分层解耦与可观测性（metrics/log/tracing）共同作用的结果。切忌盲目追求“百万 goroutine”，而应聚焦于单位资源下的吞吐效率与稳定性。
