聊 Go 网络编程，net/http是绕不开的那块基石。我最早学 Go 的时候，照着文档几行代码就把 HTTP 服务跑起来了，当时觉得特别简单。直到后来线上服务出过一次事故，排查到连接池、超时配置这些细节时，才意识到这个标准库看似简单的外表下，藏着不少必须要真正理解的东西。这篇文章我不想重复 API 文档，而是把net/http从请求进入到响应返回的完整链路拆开，结合源码行为、实际踩过的坑和压测调优的经验，做一次系统梳理。
这篇内容适合这些读者：刚学完 Go 语法想搞懂服务端框架背后逻辑的人、已经用 Gin 或 Echo 写过接口但没深入读过标准库的人，以及被线上连接泄漏、超时异常折磨过，想搞清楚根因的 Go 开发者。我会用一个最小服务端程序作为起点，顺着请求的路径，把 Handler 设计、ServeMux 路由、中间件、Server 配置、客户端连接池这些核心话题逐一展开。
1. 从最小服务端代码出发：net/http 在启动时到底做了什么
先放一个几乎所有 Go 开发者都写过的最小 HTTP 服务：
package main import ( "log" "net/http" ) func main() { http.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) { w.Write([]byte("pong")) }) log.Fatal(http.ListenAndServe(":8080", nil)) }就这么三行核心代码，却能回答很多面试里喜欢问的底层问题。http.ListenAndServe(":8080", nil)其实只是(&http.Server{Addr: ":8080", Handler: nil}).ListenAndServe()的语法糖。Handler 传 nil 时，net/http会默认使用一个全局的http.DefaultServeMux，而前面的http.HandleFunc("/ping", ...)就是往这个全局路由器上注册路由。
这行代码的执行链路大概是这样的：
Server.ListenAndServe()调用net.Listen("tcp", ":8080")，监听端口。- 在
Server.Serve()内部跑一个无限for循环，不断Accept新的 TCP 连接。 - 每 accept 一个连接，就
go启动一个 goroutine 处理这个连接上的所有请求。 - 每个连接内部有个
conn.serve()方法，它会循环读取 HTTP 请求，解析请求行、请求头、请求体。 - 解析完一个请求后，通过
serverHandler{server}.ServeHTTP(w, r)找到最终要执行的 Handler。 - Handler 处理完后写入响应，连接进入 keep-alive 状态，继续等待下一个请求，直到连接被关闭。
1.1 为什么"每个连接一个 goroutine"是合理的
HTTP/1.x 协议本身是串行协议，一个 TCP 连接在同一时间只能处理一个请求，必须等前一个请求的响应完整返回后，才能继续发送下一个请求。如果采用单线程事件循环的方案，任何一个请求处理得慢一点，其他所有请求都会被堵住。每连接一个 goroutine 的好处是代码写起来像同步代码一样简单，同时又能并发处理大量不同的连接。Go 的 goroutine 初始栈只有 2KB，内存成本很低，所以这种模型在大多数场景下是够用的。
不过它也带来了隐患：如果某个连接一直不关闭，这个 goroutine 就会一直占用资源。后面我会专门讲连接泄漏的问题。
1.2 Handler 接口为什么偏偏要这样设计
net/http最核心的接口是这个：
type Handler interface { ServeHTTP(ResponseWriter, *Request) }注意这个设计和其他很多语言的 Web 框架有本质区别——ServeHTTP没有返回值，所有响应都是通过传入的ResponseWriter写出去的。为什么？
因为 HTTP 响应天然是流式的。当你调用w.Write([]byte("hello"))时，数据会先被写入缓冲区，只有触发了w.WriteHeader(200)或者缓冲写满时，响应头和数据才会真正发送到客户端。这种设计允许你：
- 在写出 body 的过程中继续修改 header（只要还没调用
WriteHeader）。 - 边生成边发送，比如 Server-Sent Events（SSE）、大文件下载、流式响应。
- 中途发现错误时，还能在已写出一部分数据前改变响应头。
我第一次看这个接口时觉得奇怪：为什么不是ServeHTTP(*Request) Response这样的形式？后来做了几个需要流式推送的功能才明白，返回值模型会强制你把响应完整构造好再返回，根本没法支持流式场景。ResponseWriter之所以是接口而不是结构体，也是为了给中间件留出包装空间——后面讲中间件的时候会展开。
1.3 源码中一个容易被忽略的细节：serverHandler
在net/http/server.go里有一个内部类型：
type serverHandler struct { srv *Server } func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request) { handler := sh.srv.Handler if handler == nil { handler = DefaultServeMux } if req.RequestURI == "*" && req.Method == "OPTIONS" { handler = globalOptionsHandler{} } handler.ServeHTTP(rw, req) }它是Server和最终 Handler 之间的一个适配层，负责处理Handler为 nil 的情况，以及 OPTIONS * 这种协议级请求。这个地方在整个请求处理链路里处于最上游，理解它之后，你去看 Gin、Echo 这类框架的源码时会发现，它们本质上就是把一个自定义的 Handler 塞给了http.Server。
2. ServeMux 路由的分发逻辑：匹配规则、优先级与 Go 1.22 的新变化
很多框架把路由当作一个复杂的功能来做，但标准库的ServeMux其实非常精简。它负责解决一个问题：给定一个 HTTP 请求，找出该调用哪个 Handler。
2.1 旧版最长匹配：那些"一不留神就匹配错"的情况
在 Go 1.22 之前，ServeMux采用了一套相对简单的规则：
- 已注册的 pattern 如果末尾不带
/，则只在路径完全相等时匹配。 - 已注册的 pattern 如果末尾带
/，则匹配所有以它为前缀的路径。
例如注册了/api/user和/api/，那么：
- 请求
/api/user能精确匹配第一个 pattern，优先使用。 - 请求
/api/user/profile会匹配到/api/。 - 请求
/api（没有末尾斜杠）跟/api/不匹配，也跟/api/user不匹配，结果就是 404。
这个规则最大的痛点是没法区分 HTTP 方法。如果你想让GET /api/user和POST /api/user走不同逻辑，旧版只能在 Handler 内部自己判断：
http.HandleFunc("/api/user", func(w http.ResponseWriter, r *http.Request) { switch r.Method { case http.MethodGet: // ... case http.MethodPost: // ... default: w.WriteHeader(http.StatusMethodNotAllowed) } })这种方式不优雅，也容易让路由表变得混乱。如果你注册了两个HandleFunc("/api/user")，第二个会直接覆盖第一个，这也不算报错，但在多人协作时很容易误伤。
2.2 Go 1.22 的方法前缀与通配符路由
Go 1.22 对ServeMux做了一次比较大的升级，我现在写新项目基本只认这种方式。新式 pattern 支持下面几种形态：
mux := http.NewServeMux() // 方法 + 路径，区分 GET 和 POST mux.HandleFunc("GET /api/user/{id}", getUser) mux.HandleFunc("POST /api/user", createUser) // 单段通配符 {id} mux.HandleFunc("GET /user/{id}", func(w http.ResponseWriter, r *http.Request) { id := r.PathValue("id") w.Write([]byte("user " + id)) }) // 剩余路径通配符 {path...}，必须放在末尾 mux.HandleFunc("GET /files/{path...}", serveFile)通配符的值通过r.PathValue("id")获取。这个改动让标准库路由的实用性提升了一个档次，以前我在 Heroku 上部署内部工具时经常需要兼容这种路径参数，现在完全不需要引入第三方路由了。
有一个容易忽视的新规则：新 pattern 里方法前缀和路径之间必须有空格，写成GET/api/user是不合法的，注册时会直接 panic。我第一次写的时候就踩过这个空格坑，报错信息倒挺明确，一眼就能看出来。
2.3 路由绑定的优先级与冲突处理
当新式路由能匹配多个 pattern 时，ServeMux会选择"最具体"的那个。它判断的具体规则是：
- 带方法的优先于不带方法的。例如
GET /user/{id}比/user/{id}更具体。 - 精确路径段优先于通配符段。例如
/user/list比/user/{id}更具体。 - 通配符
{id}比{path...}更具体。 - 如果两个 pattern 都无法判断谁更具体，注册时会直接 panic，强迫你解决冲突。
比如你同时注册了GET /user/list和GET /user/{id}，请求GET /user/list会命中前者。请求GET /user/123会命中后者。这套规则比旧版"先注册哪个就用哪个"的模糊逻辑靠谱得多。
新路由还有一个好处：如果你注册了GET /user/{id}，但来了一个POST /user/123，ServeMux会自动返回 405 Method Not Allowed。这个 405 响应头里还会带上Allow字段，写明允许的方法，这对前端调试接口很有帮助。
3. 中间件与 Handler 的组合艺术：洋葱模型只是开始
理解了 Handler 接口之后，中间件就是一个很自然的推演。因为任何东西只要实现了ServeHTTP(ResponseWriter, *Request)就能被ServeMux使用，那我可以先在一个 Handler 外面包一层，处理完公共逻辑后再调用内部的 Handler。
3.1 HandlerFunc：把普通函数变成 Handler 的魔法
要把一个普通函数当作 Handler 使用，标准库提供了HandlerFunc适配器：
type HandlerFunc func(ResponseWriter, *Request) func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) { f(w, r) }这是一个纯粹的类型转换，没有任何性能损耗。http.HandleFunc内部实际上就是把你的函数转换成HandlerFunc再注册。理解了这一点，你就知道http.HandleFunc("/ping", fn)和http.Handle("/ping", http.HandlerFunc(fn))是完全等价的。
我以前见过有人为了这个写一个很长的包装函数，其实没必要，HandlerFunc就是为这个场景准备的。我自己写中间件时也大量依赖它。
3.2 包装 ResponseWriter 的陷阱与正确姿势
中间件最常见的需求是"记住响应的状态码"，比如打访问日志时要记录 200、404、500。实现方式通常需要包装ResponseWriter：
type statusRecorder struct { http.ResponseWriter status int } func (r *statusRecorder) WriteHeader(code int) { r.status = code r.ResponseWriter.WriteHeader(code) }但这里面藏着一个大坑。ResponseWriter接口只声明了 3 个方法，但实际的底层实现可能还实现了其他可选接口，比如http.Flusher（流式刷新）、http.Hijacker（WebSocket 升级）、http.ReaderFrom（优化大文件拷贝）、http.Pusher（HTTP/2 服务端推送）。当你把ResponseWriter包进自定义结构体后，你的包装类型默认只实现了那 3 个方法，如果某个功能依赖Flusher，它做类型断言时会失败，导致 SSE 流式推送无法工作。
正确的做法分两步。第一步，在你的包装类型上定义额外方法：
type statusRecorder struct { http.ResponseWriter status int } func (r *statusRecorder) Flush() { if f, ok := r.ResponseWriter.(http.Flusher); ok { f.Flush() } }第二步，确保在任何一步都不要丢掉原始类型信息。实际上这种方法并不完备，因为你每包装一层都要把可能用到的可选接口重新实现一遍，很繁琐。
Go 1.20 之后，标准库提供了http.ResponseController这个救星。你不再需要对包装类型做疯狂的类型断言，直接：
ctrl := http.NewResponseController(w) ctrl.Flush() ctrl.Hijack() ctrl.SetReadDeadline(time.Now().Add(30 * time.Second))它会在底层自动找到真正的实现了对应方法的那个ResponseWriter，即使中间被包装过好几层也能找到。我现在的中间件代码基本都会主动调用它，而不再使用裸的w.(http.Flusher)断言。
3.3 基于 Context 的请求级数据传递
在中间件链中传递数据，传统方式是往Request里塞值。Go 1.7 以后Request自带Context()，标准做法是用context.WithValue派生一个带值的 context，再通过r.WithContext(nextCtx)传给下游：
type ctxKey string const userIDKey ctxKey = "userID" func authMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { ctx := context.WithValue(r.Context(), userIDKey, r.Header.Get("X-User-ID")) next.ServeHTTP(w, r.WithContext(ctx)) }) }下游用r.Context().Value(userIDKey)取值。需要注意两点：context 的 key 不要直接用基础类型，否则容易和其他库冲突；r.Context()的生命周期是整个请求，请求处理完会自动 cancel，所以如果里面有启动的子 goroutine，要主动响应这个 cancel 信号，避免 goroutine 泄漏。
4. 服务端配置的底层逻辑：超时、连接状态与优雅退出
http.Server不是只有一个 Addr 和 Handler 那么简单。开发阶段用默认值没问题，但到了生产环境，超时和连接管理必须仔细配。
4.1 Server 的核心字段：哪些超时你真的必须设置
我在生产环境实际使用的 Server 配置大概是这样的：
srv := &http.Server{ Addr: ":8080", Handler: mux, ReadTimeout: 5 * time.Second, ReadHeaderTimeout: 2 * time.Second, WriteTimeout: 15 * time.Second, IdleTimeout: 120 * time.Second, MaxHeaderBytes: 1 << 20, }这几个字段的含义经常有人搞混，我用自己的话整理一下：
ReadHeaderTimeout：从连接建立到读取完请求头的超时。这是防慢速攻击（Slowloris）最关键的字段。一个恶意客户端可以故意慢慢发送请求头，如果你只设置了 ReadTimeout 而不设置 ReadHeaderTimeout，连接会一直挂着。所以我的习惯是无论如何都显式设置这个字段。ReadTimeout：从连接建立到读取完整请求体（包括 body）的超时。如果你的接口需要接收大文件上传，这个值要放宽，或者针对对应路由单独调。否则上传大文件超过阈值会被直接切断。WriteTimeout：从读请求结束到写完响应的超时。这个字段对 SSE、长轮询、WebSocket、大文件下载影响很大。我做过一个导出接口，单次响应要写 200MB 的数据，默认 WriteTimeout 很容易切断下载。IdleTimeout：keep-alive 连接空闲多久后关闭。通常比 ReadTimeout 大，让连接复用得更久一些。
提醒一下：WriteTimeout 的本质是从请求读完后开始计时，到整个响应写完结束。所以如果你接口里既有普通接口又有 SSE 流式接口，不要让所有接口共用同一个 Server，或者可以考虑用
http.ResponseController.SetWriteDeadline来动态调整。
4.2 连接生命周期：keep-alive 与 HTTP/2 的差异
net/http的服务端对 HTTP/1.x 和 HTTP/2 的处理模型不同。HTTP/1.x 是串行的，同一个 TCP 连接上同时只能有一个请求；HTTP/2 则是多路复用的，同一个连接上可以并发多个 stream。如果你的服务开了 TLS，且没有显式禁用 HTTP/2，net/http默认支持 HTTP/2。对于纯内网的服务，如果没走 TLS，用 HTTP/1.x 会有性能瓶颈——所有请求共用同一个连接时是排队处理的。
这里有个我印象很深的线上问题：有一次我在内网部署了一个 Python 脚本轮询 Go 服务，脚本开启了连接池，但因为某个接口处理很慢，3 个 worker 抢同一个连接时，请求全被堵在后面。后来排查发现是 HTTP/1.x 的串行模型导致的。解决方案有两个：要么在服务端开启 h2c（HTTP/2 明文），要么让客户端加大MaxConnsPerHost避免排队。
Server还支持通过ConnState回调监控连接状态变化，状态包括StateNew、StateActive、StateIdle、StateClosed。我会在生产环境用 Prometheus 对这几个状态做计数，能快速发现连接泄漏的苗头——比如StateIdle数量持续增长不下降，说明 keep-alive 连接没有被复用或者IdleTimeout过短。
4.3 优雅关闭：不是简单 Kill 进程
上线发布时如果把服务直接 kill，正在处理的请求会立即中断，用户会看到连接被重置。所以正确姿势是捕获退出信号，给老进程一点时间把存量请求处理完。
server := &http.Server{ Addr: ":8080", Handler: mux, } go func() { if err := server.ListenAndServe(); err != nil && err != http.ErrServerClosed { log.Fatalf("listen: %v", err) } }() quit := make(chan os.Signal, 1) signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM) <-quit ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) defer cancel() if err := server.Shutdown(ctx); err != nil { server.Close() }Shutdown的行为是：先关闭监听，不再接受新连接，然后等待所有活跃请求处理完。如果 ctx 超时，Shutdown会返回错误，此时再调用Close强制关闭。还有一个细节：Shutdown不会主动关闭空闲的 keep-alive 连接，所以如果要彻底下线，通常配合server.Close()或RegisterOnShutdown回调来收尾。
我习惯在RegisterOnShutdown里做两件事：关闭数据库连接池、通知上游负载均衡器摘除本节点。这样整个下线流程是一条顺畅的流水线。
5. Client 端连接池与那些隐蔽的坑
服务端的连接管理相对直观，客户端的坑其实更多。http.Client是一个门面，真正干活的是http.Transport。
5.1 Client、Transport、Request 三层架构
client := &http.Client{ Transport: &http.Transport{ Proxy: http.ProxyFromEnvironment, DialContext: (&net.Dialer{ Timeout: 5 * time.Second, KeepAlive: 30 * time.Second, }).DialContext, MaxIdleConns: 200, MaxIdleConnsPerHost: 20, IdleConnTimeout: 90 * time.Second, TLSHandshakeTimeout: 5 * time.Second, ExpectContinueTimeout: 1 * time.Second, MaxConnsPerHost: 0, }, Timeout: 10 * time.Second, }http.Client负责超时、重定向策略和 Cookie 管理；http.Transport负责连接管理；每次请求的细节放在http.Request里。搞清楚这一层分层后，很多问题就好定位了。
Transport是实现RoundTripper接口的类型。这个接口的签名很简洁：
type RoundTripper interface { RoundTrip(*Request) (*Response, error) }你也可以实现自己的RoundTripper，在请求发出去之前和拿到响应之后做统一处理。比如实现链路追踪的 header 注入，用自定义RoundTripper比在业务代码里一个个加 header 干净得多。
5.2 连接池的复用机制
http.Transport内部维护着一个连接池，按"目标地址 + 协议"维度管理空闲连接。当一个请求进来时，getConn会尝试从连接池里取一个空闲连接；如果没有，就发起Dial创建新连接；如果同一时刻大量请求都在创建新连接，Transport会协调让其中一个去 dial，其他请求等待，避免连接风暴。
这里有个很重要的细节：一个连接在响应体（resp.Body）读取完毕之前，是不会归还给连接池的。如果你只调用了resp.Body.Read读到一部分数据后就不再读了，或者忘记调用resp.Body.Close()，这个连接就永远不会被复用，最终结果就是大量连接被挂起。
MaxIdleConnsPerHost控制的是"单个目标主机最多保留多少个空闲连接"。默认值是 2。如果你的服务需要高频调用同一个上游 API，而每次新建连接的开销又很大，默认值会导致连接刚用完就被关闭，下一波请求又得重新建连。我之前用 wrk 压测一个反向代理服务，发现默认配置下有大量 TIME_WAIT 连接，把MaxIdleConnsPerHost调到 50 之后，TIME_WAIT 数量立刻降了一个量级，吞吐也跟着上去了。所以这个参数可以说是客户端调优里最见效的一个。
IdleConnTimeout控制空闲连接保留的最长时间。建议设成 90 秒左右，太短会导致连接频繁重建，太长又会占用文件描述符。另外还有个MaxConnsPerHost可以限制单主机的总连接数，默认 0 表示不限制，但有些上游服务有连接数上限，必要时需要按业务调整。
5.3 实战中最后悔的三种写法
我见过的客户端问题，翻来覆去就是这三种：
第一种：用http.Get这种全局函数且不设置超时。http.Get内部用的是http.DefaultClient，它的Timeout是 0，意味着永远不超时。如果对端服务一直不响应，你的 goroutine 就永远挂着。所以生产代码里千万不要裸用http.Get，要自己创建带Timeout的 Client。哪怕只设一个总超时，也能兜底。
第二种：读完响应体但没关闭resp.Body，或者没读完就 Close。我见过一个很隐蔽的问题，业务代码里用io.ReadAll(resp.Body)读完了 body，但没调resp.Body.Close()。看起来数据拿到了，但这连接永远不会归还给连接池。时间一长，系统报too many open files，进程直接崩掉。规范做法就是：
resp, err := client.Do(req) if err != nil { return err } defer resp.Body.Close() body, err := io.ReadAll(resp.Body)如果只是想探测状态码，不需要 body，也要把 body 读完再 Close，或者干脆直接 Close，否则连接也无法复用。
第三种：每次请求都创建一个新的http.Client。http.Client本身很轻，但每个 Client 默认会关联一个新的Transport，也就是一个新的连接池。如果每次请求都新建 Client，连接池完全没有意义，连接建了又关，资源开销肉眼可见。正确做法是程序里按"上游服务"维度复用同一个 Client。
另外还有一个容易被忽视的坑：客户端设置了Timeout，服务端也设置了WriteTimeout，如果服务端写响应太慢超过了客户端Timeout，客户端可能拿到一个不完整的响应。此时err里报的是context deadline exceeded，而服务端才刚开始处理。所以超时配置要从整个链路考量，不能各自乱设。
6. 一次贴近实战的压测调优：数据与参数建议
我在给一个内部网关服务做调优时，完整走过一遍"默认配置 → 发现问题 → 调整参数 → 复测"的流程。这部分我把关键步骤和观察到的现象写出来，虽然不同机器结论会有差异，但思路是可复用的。
6.1 默认配置为什么撑不住高并发
先看服务端代码，在几乎裸用http.ListenAndServe的情况下，我用wrk压测一个简单接口：
wrk -t8 -c200 -d30s http://localhost:8080/ping-c200意思是同时保持 200 个并发连接。在默认配置下，吞吐看起来还行，但有两个现象容易注意到：
- 压测过程中出现很多
TIME_WAIT连接，说明服务端每处理完一轮请求都在关闭部分连接。 - 延迟的 p99 波动很大，有时候几十毫秒，有时候几百毫秒。
当我把连接数从 200 提到 1000 时，问题更明显了：连接建立数量暴涨，但吞吐并没有成比例上升，甚至开始出现超时。原因就在于默认的IdleTimeout和MaxIdleConnsPerHost没调，连接复用效率不高，加上系统文件描述符有限，连接被大量 TIME_WAIT 占住后，新连接建立变慢。
6.2 调整哪些参数最立竿见影
我按下面的顺序做了调整，每一步都有明确动机：
- 服务端设置
ReadHeaderTimeout、ReadTimeout、WriteTimeout。这一步主要解决"慢客户端占住 goroutine"和"出问题后连接长期悬挂"的问题。 - 服务端设置
IdleTimeout为 120 秒，让 keep-alive 连接保留得久一点，减少三次握手次数。 - 客户端显式配置
Transport，把MaxIdleConnsPerHost从默认 2 提升到 50，MaxIdleConns按目标主机数乘 50 左右设置，IdleConnTimeout设置 90 秒。 - 如果调用上游的 QPS 特别高，考虑增加
MaxConnsPerHost保障连接上限，但要结合上游服务本身的容量，别盲目加大。
这里有个选择思路值得说一下：MaxIdleConnsPerHost设太大真的好吗？不是。如果只有少数几个上游，太大不会有问题；如果有几百个不同 host，每个 host 都保留几十个空闲连接，内存和 fd 都会成为瓶颈。所以这个值永远要和"你实际会访问多少台不同 host"挂钩。
6.3 实测数据与最终建议
我压测的结果大致是这样的趋势规律（不同机器数值会不一样，但相对变化是稳定的）：调整前，200 并发时 p99 延迟约 80ms，QPS 约 2 万；调整后，p99 降到 15ms 左右，QPS 提升接近 30%。最明显的变化是客户端到上游的连接复用率明显提升，TIME_WAIT 数量大幅减少。
所以我的最终建议总结起来就三句话：
- 服务端的超时一定要设，特别是
ReadHeaderTimeout，这是防慢速攻击的第一道防线。 - 客户端的
Transport一定要显式配置并用共享的 Client，MaxIdleConnsPerHost要按真实调用量来设。 - 每次改动后别只看平均延迟，重点观察
p99和 TIME_WAIT 数量，这两个指标对连接池的健康状况最敏感。
还有一个很多人忽略的点：压测时一定要用正确的压测工具和参数。wrk 适合测 HTTP/1.1，如果想测 HTTP/2 或需要更复杂的 header/body 组合，建议用ghz或k6。压测时间也不要太短，至少 30 秒以上，才能覆盖连接建立、复用、超时回收的完整周期。
最后分享一个我这几年总结出来的小经验。遇到 HTTP 相关的线上问题，第一反应不要去看业务逻辑，先去抓三个数据：服务端的连接状态分布、客户端的连接池指标、TIME_WAIT 和 CLOSE_WAIT 的数量。这三个数据能帮你快速判断问题到底出在"协议层""连接层"还是"业务层"。net/http本身的设计已经足够健壮，绝大多数问题出在我们对它的默认行为理解不够，照着默认值硬怼线上流量。把这个标准库的连接模型和超时体系吃透，很多奇奇怪怪的线上故障其实都能提前避免。
