HTTP请求经Client构造Request后由Transport处理连接复用；服务端通过ServeMux前缀匹配路由，ResponseWriter需先写Header再写Body；全程依赖context控制超时与取消，须主动检查ctx.Err()。
HTTP请求从net/http.Client发出时发生了什么
Go 的 http.Client 并不直接发送字节流，而是先构造 *http.Request，再交由底层的 Transport 处理。关键点在于：默认的 http.DefaultClient 使用 http.DefaultTransport，它内部维护连接池（http.Transport 的 MaxIdleConns、MaxIdleConnsPerHost 等参数直接影响复用行为）。
常见误操作是每次请求都新建 http.Client 却没配 Transport，导致 TCP 连接无法复用，短时间内大量 CLOSE_WAIT 或 TIME_WAIT，甚至触发“too many open files”错误。
- 必须显式设置
Transport的超时和空闲连接策略，尤其在高并发场景 -
Request.Body必须被读完或关闭（io.Copy(ioutil.Discard, resp.Body); resp.Body.Close()），否则连接不会归还给连接池 - 若使用自定义
RoundTripper（如加日志、重试），需确保不破坏连接复用逻辑
http.ServeMux 和 http.Handler 如何匹配并分发请求
当 HTTP 服务端收到请求后，net/http.Server 会调用其 Handler 字段（默认为 http.DefaultServeMux）的 ServeHTTP 方法。匹配路径时只做前缀匹配（/api/ 会匹配 /api/users 和 /api/），且不自动处理尾部斜杠重定向——除非注册的是带结尾斜杠的 pattern（如 /api/），此时访问 /api 会 301 跳转到 /api/。
容易忽略的是：如果 handler 中 panic，http.ServeMux 默认会 recover 并返回 500，但不会打印堆栈；若要调试，需包装 handler 或启用 http.Server.ErrorLog。
立即学习“go语言免费学习笔记（深入）”；
- 注册
/foo不会匹配/foo/，二者是不同路由 -
http.HandleFunc底层只是把函数转成http.HandlerFunc类型并注册进DefaultServeMux - 自定义
http.Handler实现必须保证线程安全，因为ServeHTTP可能被并发调用
响应体写入与 http.ResponseWriter 的真实约束
http.ResponseWriter 不是缓冲区，而是一个接口，其实现（如 responseWriter）在首次调用 WriteHeader 或 Write 时才真正向底层连接写入状态行和响应头。一旦响应头写出，就无法再修改状态码或 header（Header().Set 仍可调用，但无效）。
典型错误是：在 handler 中先 fmt.Fprintf(w, "...") 再试图 w.WriteHeader(400)，结果状态码仍是 200；或者在写入大文件时未设 Content-Length 且未用 chunked 编码，导致客户端等待超时。
- 调用
w.Write前未显式w.WriteHeader，Go 会自动写入 200 OK - 若需流式响应（如 SSE、大文件下载），应避免一次性加载全部内容到内存，改用
io.Copy或分块Write -
Flush只对支持的底层 writer（如http.Hijacker或启用了Transfer-Encoding: chunked）有效，普通 HTTP/1.1 响应中调用不一定立即送达客户端
连接关闭、超时与上下文取消如何联动
Go 的 HTTP 生命周期深度绑定 context.Context。客户端侧，http.Request.WithContext 设置的 context 控制整个请求生命周期；服务端侧，http.Request.Context() 会在连接断开、服务端超时或主动 CancelFunc 调用时被 cancel。
但要注意：context.WithTimeout 创建的子 context 在超时后仅触发 cancel，不会自动中断正在写的 TCP 连接——写操作可能仍在进行，直到系统层面的 socket 超时（如 net.Conn.SetWriteDeadline）生效。因此，handler 中需主动检查 ctx.Err() != nil 并提前退出。
- 服务端
http.Server.ReadTimeout/WriteTimeout已被弃用，推荐用ReadHeaderTimeout+IdleTimeout+ctx.Done()组合控制 - 客户端
http.Client.Timeout是整个请求耗时上限，包含 dial、TLS handshake、write request、read response 全过程 - 不要在 handler 中启动 goroutine 后完全脱离 context 控制，否则可能造成 goroutine 泄漏
最易被绕过的环节是：以为设置了 Client.Timeout 就万无一失，却忽略了 DNS 解析、TCP 连接建立这些前置阶段可能卡住更久；或者在服务端 handler 里用 time.Sleep 模拟耗时操作却不检查 context 是否已取消。
