Go HTTP服务器需显式创建ServeMux、校验Method/Content-Type、配置超时、包装ResponseWriter以实现可观察性与可靠性。
Go 的 http 包足够轻量、可靠，直接用它写生产级 Web 服务器完全可行，但必须绕开默认的全局 http.DefaultServeMux 和隐式注册逻辑，否则会埋下竞态、测试难、路由不可控的隐患。
避免直接用 http.HandleFunc 注册路由
这个函数看似方便，实则把 handler 绑定到全局 http.DefaultServeMux，导致：
- 多个包 import 后可能无意中覆盖彼此的路由（比如两个第三方库都调
http.HandleFunc("/health", ...)） - 无法为不同 server 实例配置独立路由（例如一个服务要同时暴露 API 和管理端口）
- 单元测试时难以隔离——
http.ServeHTTP会走全局 mux，mock 成本高
正确做法是显式创建 http.ServeMux 或直接实现 http.Handler 接口：
mux := http.NewServeMux()
mux.HandleFunc("/api/users", usersHandler)
mux.HandleFunc("/health", healthHandler)
server := &http.Server{
Addr: ":8080",
Handler: mux,
}
server.ListenAndServe()手动解析 query 和 body 前先检查 Content-Type 和 Method
Go 不自动校验请求合法性，r.ParseForm() 或 json.Decode(r.Body) 在错误类型或方法下会静默失败或 panic。常见坑：
立即学习“go语言免费学习笔记（深入）”；
-
POST请求发了application/json却调r.FormValue→ 返回空字符串 -
GET请求误用r.Body→ 读不到内容（body 为空），且不报错 - 未检查
r.Method就处理 body →PUT或DELETE携带 payload 时逻辑错乱
建议在 handler 开头加基础校验：
if r.Method != "POST" {
http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
return
}
if ct := r.Header.Get("Content-Type"); ct != "application/json" {
http.Error(w, "Content-Type must be application/json", http.StatusBadRequest)
return
}别让 http.Server 没有超时控制就上线
默认的 http.Server 没有设置任何超时，一旦后端卡住、客户端断连不发 FIN、或慢速攻击发生，连接会无限期挂起，最终耗尽文件描述符。必须显式配置：
-
ReadTimeout：从连接建立到读完 request header 的时间（含 TLS 握手） -
ReadHeaderTimeout：仅限制读 header 的时间（更精确，推荐） -
WriteTimeout：从收到完整 request 到 response 写完的时间 -
IdleTimeout：keep-alive 连接空闲多久后关闭（防 slowloris）
典型配置示例：
server := &http.Server{
Addr: ":8080",
Handler: mux,
ReadHeaderTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 30 * time.Second,
}自定义 http.ResponseWriter 是调试和中间件的关键路径
标准 http.ResponseWriter 不暴露状态码、写入字节数等信息，日志和监控无法获取。所有中间件（如日志、指标、CORS）都依赖包装它。最简包装示例：
type responseWriter struct {
http.ResponseWriter
statusCode int
written bool
}
<p>func (rw *responseWriter) WriteHeader(code int) {
rw.statusCode = code
rw.written = true
rw.ResponseWriter.WriteHeader(code)
}</p><p>func (rw *responseWriter) Write(b []byte) (int, error) {
if !rw.written {
rw.statusCode = http.StatusOK
rw.written = true
}
return rw.ResponseWriter.Write(b)
}这样就能在 defer 中准确记录状态码和响应体大小——而不用靠 http.Hijacker 或反射黑科技。
真正麻烦的不是写 handler，而是让每个请求都经过可观察、可中断、可复位的生命周期控制。这些细节不提前设计，后期加链路追踪或熔断就会被迫重写整套请求分发逻辑。
