go http服务器本质是net.listener+goroutine+handler协作：listenandserve启动tcp监听循环，accept后启goroutine处理请求，nil参数默认使用http.defaultservemux（带锁map），所有handler必须实现servehttp方法；超时需显式构造http.server设置readheadertimeout、writetimeout等字段，作用于连接粒度。
Go 的 HTTP 服务器不是黑盒，它本质是 net.Listener + goroutine + Handler 三者协作的结果。只要你理解这三点怎么串起来，就不会被「自动路由」「默认多路复用器」这类词绕晕。
ListenAndServe 本质就是启动一个 TCP 监听循环
http.ListenAndServe(":8080", nil) 看似简单，背后干了三件事：
- 调用
net.Listen("tcp", ":8080")创建一个阻塞式监听 socket - 进入无限循环：每次
accept()到新连接，就起一个goroutine处理（避免阻塞后续连接） - 每个 goroutine 内部读取完整的 HTTP 请求（含 header 和 body），解析成
*http.Request，再交给传入的Handler处理
注意：nil 作为第二个参数时，实际使用的是 http.DefaultServeMux —— 它只是个带锁的 map[string]muxEntry，没有魔法，只是把路径字符串映射到函数。
Handler 接口才是真正的请求处理入口
所有能接 HTTP 请求的对象，都必须实现这个签名：
func (w http.ResponseWriter, r *http.Request)
但 Go 不直接让你传函数，而是要求你提供实现了 http.Handler 接口的类型，即包含 ServeHTTP(http.ResponseWriter, *http.Request) 方法的任意类型。常见用法有：
-
http.HandlerFunc：把普通函数转成满足接口的类型，http.HandleFunc("/", fn)就是这么工作的 - 自定义结构体：比如
type LoggerHandler struct{ next http.Handler }，在ServeHTTP里先记录日志再调next.ServeHTTP -
*http.ServeMux：它自己也实现了ServeHTTP，所以能当Handler传给ListenAndServe
别被「Handler 是接口」吓住——你写的每个路由函数，最终都会被包装成 http.HandlerFunc 实例，它内部就干一件事：fn(w, r)。
DefaultServeMux 和自定义 ServeMux 的区别只在注册方式
用 http.HandleFunc("/api", handler)，等价于：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
http.DefaultServeMux.Handle("/api", http.HandlerFunc(handler))
而用 http.NewServeMux() 后手动注册，好处是：
- 避免全局状态污染（
DefaultServeMux是包级变量，多个模块可能误覆盖） - 可独立配置、测试、复用（比如为 admin 路由单独建一个 mux）
- 明确控制生命周期（
NewServeMux是局部变量，不会被意外修改）
但要注意：ServeMux 只做前缀匹配（如注册 /user 会匹配 /user/profile），且不支持正则或通配符；真要复杂路由，得换 gorilla/mux 或 chi 这类库。
Server 结构体里的超时字段不是摆设
直接用 http.ListenAndServe 无法设置超时，容易出问题：
- 恶意客户端不发完整请求头 → 卡死 goroutine（需
ReadHeaderTimeout） - POST 大文件上传中途断开 → 连接长期占用（需
ReadTimeout） - Handler 内部慢查询或死循环 → 响应迟迟不返回（需
WriteTimeout） - Keep-Alive 连接空闲太久 → 文件描述符耗尽（需
IdleTimeout）
正确做法是显式构造 http.Server：
srv := &http.Server{
Addr: ":8080",
Handler: mux,
ReadHeaderTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 30 * time.Second,
}
log.Fatal(srv.ListenAndServe())
这些字段必须在服务启动前设置，运行中改不了；而且它们作用于连接粒度，不是请求粒度 —— 比如 WriteTimeout 从响应开始写入那一刻计时，不是从请求到达开始。
真正难的不是写 Handler，而是让 Handler 在高并发、异常网络、长连接场景下不泄露 goroutine、不卡死、不拖垮整个服务。超时控制、Context 传递、Body 关闭、连接复用，这些细节才决定一个 HTTP 服务能不能上生产。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
