http.HandleFunc使用全局http.DefaultServeMux，路径匹配为前缀匹配且后注册覆盖先注册，易导致路由冲突或404；http.ListenAndServe阻塞运行且忽略错误将致静默失败；应显式创建*http.ServeMux并用自定义http.Server设超时以保障生产稳定性。
Go语言搭HTTP服务，net/http 包足够用，不装框架也能跑生产级服务——但前提是理解它怎么匹配路径、怎么设超时、怎么避免阻塞，否则上线后会卡在 http.ListenAndServe 不报错也不响应。
为什么 http.HandleFunc 注册的路由总被“吃掉”或 404
http.HandleFunc 使用的是全局默认多路复用器 http.DefaultServeMux，所有包里调用它的代码都往同一个地方注册。常见踩坑点：
- 路径匹配是前缀匹配：注册
"/api"会同时响应/api、/api/users、/api/xxx/yyy，没写return或http.Error就可能意外透传 - 根路径
"/"必须显式注册，不会 fallback；如果只注册了"/user"，访问/就是 404 - 多个
http.HandleFunc注册相同路径，后注册的会覆盖前一个，无警告 - 第三方库（比如某些日志中间件）可能偷偷调用
http.HandleFunc，和你冲突
建议：生产环境一律显式构造 *http.ServeMux，不依赖全局实例：
mux := http.NewServeMux()
mux.HandleFunc("/", homeHandler)
mux.HandleFunc("/health", healthHandler)
http.ListenAndServe(":8080", mux)
http.ListenAndServe 启动后程序卡住、无法捕获错误
http.ListenAndServe 是阻塞调用，返回值只在启动失败时才有意义；一旦监听成功，它就一直运行，直到进程退出或发生不可恢复错误（如端口被占、TLS配置错）。常见误操作：
立即学习“go语言免费学习笔记（深入）”；
- 忽略返回值，导致端口被占用时程序静默失败，连
fmt.Println都没输出 - 没设超时，请求卡住后 goroutine 泄漏，连接堆积
- 直接传
nil，用默认Server，没法控制ReadTimeout、WriteTimeout、IdleTimeout
正确做法是用自定义 http.Server 实例：
srv := &http.Server{
Addr: ":8080",
Handler: mux,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 30 * time.Second,
}
log.Println("server starting on :8080")
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatalf("server failed: %v", err)
}处理 JSON 请求时 ioutil.ReadAll(r.Body) 报错或读空
Go 1.16+ 已弃用 ioutil，应改用 io.ReadAll；但更关键的是，r.Body 只能读一次。如果前面有中间件、日志或 r.ParseForm() 调用，r.Body 已被消费，再读就是空。
- 不要在 handler 里多次调用
io.ReadAll(r.Body) - 如果要同时记录原始 body 和解析 JSON，需先读一次并用
io.NopCloser重置：r.Body = io.NopCloser(bytes.NewReader(bodyBytes)) - 注意
Content-Type是否为application/json，否则json.Unmarshal可能静默失败 - 大请求体未设限制，可能 OOM；建议用
http.MaxBytesReader包一层
示例安全读法：
body, err := io.ReadAll(http.MaxBytesReader(w, r.Body, 1<<20)) // 限制 1MB
if err != nil {
http.Error(w, "bad request", http.StatusBadRequest)
return
}
var data MyStruct
if err := json.Unmarshal(body, &data); err != nil {
http.Error(w, "invalid json", http.StatusBadRequest)
return
}提供静态文件或二进制资源时 Content-Type 错乱
浏览器靠 Content-Type 决定怎么渲染响应。Go 默认不自动推断类型，全靠你手动设。常见问题：
- 用
w.Header().Set("Content-Type", "image/gif")但忘了在w.Write前调用，header 就丢了 - 从磁盘读 GIF 文件后直接
w.Write(buf)，没设 type，浏览器当文本显示乱码 - 用
http.FileServer时路径没校验，可能泄露/etc/passwd（需配合http.StripPrefix） - Base64 解码 GIF 后写入响应，但解码失败没检查，返回空内容 + 错误 type
推荐组合用法：
fs := http.FileServer(http.Dir("./static"))
http.Handle("/static/", http.StripPrefix("/static/", fs))
<p>// 或手动服务单个 GIF
http.HandleFunc("/logo.gif", func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "image/gif")
http.ServeFile(w, r, "./logo.gif")
})最易被忽略的是：没有显式设置超时的 http.Server 在高并发下会累积大量 idle 连接，最终耗尽文件描述符；而路径匹配逻辑一旦写错，问题只在特定 URL 下暴露，压测也未必能打中。别迷信“几行代码就能跑”，每行背后都有默认行为要对齐。
