17370845950

Go 的 net/http 包需显式初始化 Server、设超时、用 Shutdown 优雅退出；路由须用独立 ServeMux；请求体须显式解析或清空；中间件需正确包装 Handler 并调用 ServeHTTP；务必设 Content-Type 并 recover panic。

Go 的 net/http 包足够轻量且开箱即用，不需要框架也能快速启动一个生产可用的 HTTP Server——但前提是清楚哪些步骤不能跳、哪些默认行为会埋坑。

初始化 HTTP Server 要显式控制 http.Server 实例

直接调用 http.ListenAndServe 看似简单，但它隐藏了超时、连接管理、日志等关键控制点，线上服务极易因长连接堆积或无响应请求导致内存泄漏或拒绝服务。

• 必须用 &http.Server{Addr: ":8080", Handler: mux} 显式构造，而非依赖全局默认
• ReadTimeout 和 WriteTimeout 建议设为 30 秒起，避免慢客户端拖垮整个服务
• 使用 Shutdown 配合 context.WithTimeout 实现优雅退出，否则 os.Interrupt 信号可能杀掉正在处理的请求

路由注册别用 http.HandleFunc 全局注册

全局注册（如 http.HandleFunc("/api/user", handler)）会污染 http.DefaultServeMux，一旦引入第三方库（比如 Prometheus 的 /metrics）或中间件，容易发生路由覆盖或不可预期的匹配顺序。

• 始终创建独立的 http.ServeMux 或用更明确的路由器（如 chi.Router()）
• 路径末尾是否带 / 影响子路径匹配：Handle("/api/", handler) 可匹配 /api/users，而 Handle("/api", handler) 不会
• 注意 http.ServeMux 不支持通配符（如 /user/{id}），需手动解析 r.URL.Path 或换用第三方路由

处理请求体前必须调用 r.ParseForm 或 r.Body 显式读取

常见错误是直接访问 r.FormValue("key") 却没调用 r.ParseForm()，导致返回空字符串；更隐蔽的问题是忘记读取或关闭 r.Body，造成后续中间件或复用连接失败。

• POST 表单数据：先 r.ParseForm() 再用 r.FormValue
• JSON 请求体：用 json.NewDecoder(r.Body).Decode(&v)，且务必在函数结束前 io.ReadAll(r.Body) 或 io.Copy(io.Discard, r.Body) 清空未读部分
• 不关闭 r.Body 会导致底层 TCP 连接无法复用（HTTP/1.1 keep-alive 失效）

中间件必须用闭包包装 handler 并返回新 http.Handler

Go 的中间件不是“插件”，而是函数式链式调用。写错结构会导致 handler 被跳过、panic 不被捕获，或上下文丢失。

正确模式：

func loggingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        log.Printf("Started %s %s", r.Method, r.URL.Path)
        next.ServeHTTP(w, r)
        log.Printf("Completed %s %s", r.Method, r.URL.Path)
    })
}

• 必须返回 http.HandlerFunc{...} 或实现 ServeHTTP 方法的类型
• 不要在中间件里直接调用 next(w, r)（这是函数调用），要调用 next.ServeHTTP(w, r)（这是接口方法）
• 若需修改 ResponseWriter（如记录状态码），需包装成自定义 responseWriter 类型，否则无法拦截 WriteHeader

最常被忽略的是：没有设置 Content-Type 头就直接写 JSON，浏览器或客户端可能解析失败；还有就是 panic 后服务继续运行但请求卡死——必须用 recover() 包裹每个 handler 执行逻辑。