golang如何阅读net/http源码_golang net/http源码阅读实践-Golang-PHP中文网

http.listenandserve 启动流程为：创建 http.server 实例并调用其 listenandserve 方法，内部通过 net.listen 获取 listener，再由 server.serve 循环 accept 连接并为每个连接启动 goroutine 执行 serverhandler.servehttp。

golang如何阅读net/http源码_golang net/http源码阅读实践

从 `http.ListenAndServe` 入口开始跟踪最简 HTTP 服务启动流程

Go 的 net/http 启动逻辑藏得不深，但容易被 http.Serve 和底层 net.Listener 的抽象绕晕。直接从最常用的 http.ListenAndServe 看起，它本质是两步：创建 http.Server 实例 + 调用其 ListenAndServe 方法。

关键点在于：http.ListenAndServe 默认使用全局变量 http.DefaultServeMux 作为路由复用器，而真正监听和接受连接的是 net.Listen("tcp", addr) 返回的 net.Listener。这个 Listener 会被传给 Server.Serve，后者进入一个死循环调用 Accept()。

Server.Serve 不解析 HTTP 报文，只负责接收连接、起 goroutine 调用 serverHandler.ServeHTTP
每个连接对应一个独立 goroutine，所以并发模型天然由 Go runtime 支撑，无需手动管理线程池
如果传入自定义 http.Server 实例，务必注意 ReadTimeout/WriteTimeout（已弃用）或更推荐的 ReadHeaderTimeout、IdleTimeout，否则连接可能长期 hang 住

理解 `ServeHTTP` 接口如何串联 Handler 链

所有能处理 HTTP 请求的类型，都必须实现 http.Handler 接口——也就是只有一个方法：ServeHTTP(http.ResponseWriter, *http.Request)。这是整个请求分发的核心契约。

http.ServeMux 是最典型的 Handler 实现，它内部维护一个 map[string]muxEntry，把路径前缀映射到具体 handler；而 http.HandlerFunc 是个类型别名，靠闭包转成函数值后，再通过强制转换满足接口要求。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

自定义中间件本质就是返回一个新的 http.Handler，比如 func(h http.Handler) http.Handler { return loggingHandler{h} }
http.StripPrefix 和 http.FileServer 组合时，要注意路径匹配顺序：StripPrefix 先截掉前缀，再交给 FileServer 解析剩余路径，否则静态文件 404
不要在 ServeHTTP 中 panic，除非你启用了 http.Server.ErrorLog 并做了 recover 包装，否则 panic 会直接 kill goroutine 导致连接无声断开

为什么 `http.Request.Body` 只能读一次？源码里怎么做的

Request.Body 是一个 io.ReadCloser，底层通常是 io.LimitedReader 包裹的网络连接缓冲区。它的“一次性”行为不是约定，而是由 readLimitBody（在 server.go 中）和 bodyEOFSignal 这两个结构体硬编码决定的。

一旦调用 req.Body.Read() 或 io.ReadAll(req.Body)，底层 reader 的 offset 就往前走了；再次 Read 就从新位置开始，而网络连接早已关闭或丢弃了旧数据。

想多次读 body，必须在第一次读完后用 req.Body = io.NopCloser(bytes.NewReader(data)) 重置
用 req.ParseForm() 或 req.FormValue() 也会隐式读 body（对 POST 表单），所以它们和显式读 body 不能混用，否则第二次读为空
生产环境建议统一用 io.Copy(ioutil.Discard, req.Body) 快速丢弃未处理 body，避免连接被卡在 read 状态

调试时怎么快速定位到 `http.Transport` 的超时控制点

客户端侧的超时最容易混淆，因为 http.Client 本身没有“总超时”，而是拆成三段：连接建立（DialContext）、TLS 握手（TLSHandshakeTimeout）、响应头读取（ResponseHeaderTimeout）。这些全在 http.Transport 字段里配置。

关键线索在 transport.go 的 RoundTrip 方法里：它先调用 getConn 获取连接（触发 Dial 和 TLS），再调用 writeHeaders，最后用 readResponse 读响应头——每一步都有自己的 context deadline。

Client.Timeout 只作用于整个 RoundTrip 调用，但它不会中断正在进行的底层 I/O，仅影响上层 context cancel
若服务端迟迟不发响应头，ResponseHeaderTimeout 才真正切断连接；没设它，哪怕 Client.Timeout 到了，连接也可能卡在 readLoop 里
调试时可在 transport.go 的 roundTrip 开头加日志，或用 godebug 在 getConn 和 readResponse 处打断点，比看文档更快定位阻塞点

实际阅读时别从 server.go 顶部开始逐行扫，先盯住几个核心函数： ListenAndServe、ServeHTTP、readRequest、writeChunk、RoundTrip。它们分散在不同文件，但构成了请求生命周期的骨架。细节如 header 解析、chunked 编码、keep-alive 管理，都是围绕这几条主线展开的。