用 net/http 可实现标准 REST 路由与 JSON 响应,需手动处理路由匹配(无路径参数支持)、状态码、Content-Type、body 关闭、错误分类(400/500)、超时配置及优雅关闭。

用 net/http 就能写出来,不需要框架也能跑通标准 REST 路由和 JSON 响应,但得自己处理请求解析、状态码、错误返回这些细节。
怎么用 net/http 实现 GET/POST 路由
Go 标准库的 http.HandleFunc 是最轻量的入口,按路径注册函数即可,不用引入第三方路由。注意它不支持路径参数(比如 /users/{id}),只能靠字符串前缀匹配或手动拆分 r.URL.Path。
常见写法:
http.HandleFunc("/api/users", func(w http.ResponseWriter, r *http.Request) {
switch r.Method {
case "GET":
// 返回用户列表
json.NewEncoder(w).Encode([]map[string]string{{"name": "alice"}})
case "POST":
// 解析 JSON 请求体
var u map[string]string
json.NewDecoder(r.Body).Decode(&u)
w.WriteHeader(http.StatusCreated)
json.NewEncoder(w).Encode(u)
default:
w.WriteHeader(http.StatusMethodNotAllowed)
}
})
- 必须显式调用
w.WriteHeader()设置状态码,否则默认是 200 -
r.Body是io.ReadCloser,用完不关不会报错,但可能泄漏资源(尤其高并发时) - 所有响应都得自己写
Content-Type: application/json,json.Encoder不自动设头
为什么建议封装一个通用响应函数
重复写 json.NewEncoder(w).Encode(...) 和 w.WriteHeader(...) 容易漏状态码或写错 MIME 类型,而且没法统一加日志或耗时统计。
立即学习“go语言免费学习笔记(深入)”;
推荐定义一个 writeJSON 工具函数:
func writeJSON(w http.ResponseWriter, status int, v interface{}) {
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(status)
json.NewEncoder(w).Encode(v)
}
- 调用时直接
writeJSON(w, http.StatusOK, data),语义清晰 - 后续想加全局日志、gzip 压缩、CORS 头,只改这一个函数就行
- 别在函数里 recover panic——HTTP handler 崩溃会导致整个服务挂掉,应该用中间件或 defer+recover 包一层
如何安全读取 POST 的 JSON 请求体
直接 json.Decode(r.Body) 有风险:body 可能为空、格式非法、超大 payload 导致 OOM。生产环境至少要加三道防护。
- 用
r.ParseForm()或io.LimitReader(r.Body, 1 限制最大读取 1MB - 解码前检查
r.Header.Get("Content-Type")是否为application/json - 用
defer r.Body.Close(),哪怕只是io.Copy(ioutil.Discard, r.Body)也得关掉 - 结构体字段加
json:"name,omitempty"避免零值污染响应
错误处理不能只打印日志就返回 500,要区分是客户端错误(400)还是服务端错误(500):json: cannot unmarshal string into Go value of type int 是 400,database is down 才是 500。
启动服务时容易忽略的配置项
http.ListenAndServe(":8080", nil) 看似简单,但线上部署时几个参数不设会出问题:
-
http.Server实例要显式设置ReadTimeout和WriteTimeout,防止慢连接拖垮服务 - 用
http.Server{Handler: mux}.ListenAndServe()替代全局http.HandleFunc,便于测试和替换 Handler - 监听地址写
":8080"没问题,但若要绑定到特定 IP(如只内网访问),得写成"127.0.0.1:8080" - 没加
Graceful Shutdown的话,kill 进程会中断正在处理的请求
路径匹配逻辑、错误码语义、body 读取边界、服务启停控制——这些地方不细究,API 表面能跑,压测或上线后就会暴露问题。










