Golang实现简单的RESTful接口示例

用net/http可实现轻量restful路由：通过预定义路径-方法映射表分发请求，手动解析URL路径参数并校验，显式设置jsON响应头，避免隐式状态。

用 net/http 实现最简 RESTful 路由

go 标准库 net/http 本身不带路由功能，但完全够用——不需要引入第三方框架也能写出清晰、可维护的 RESTful 接口。关键在于手动匹配 req.URL.Path 和 req.Method，而不是依赖复杂中间件。

常见错误是直接写一堆 if req.URL.Path == "/users" && req.Method == "GET"，结果分支嵌套深、难测试、无法复用。更稳妥的做法是提前注册路由表，再统一分发：

package main  import ( 	"fmt" 	"log" 	"net/http" )  type handlerFunc func(http.ResponseWriter, *http.Request)  var routes = map[string]map[string]handlerFunc{ 	"/users": { 		"GET":    getUsers, 		"POST":   createUser, 		"DELETE": deleteUser, 	}, }  func main() { 	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { 		if h, ok := routes[r.URL.Path][r.Method]; ok { 			h(w, r) 			return 		} 		http.Error(w, "404 not found", http.StatusNotFound) 	}) 	log.Fatal(http.ListenAndServe(":8080", nil)) }  func getUsers(w http.ResponseWriter, r *http.Request) { 	fmt.Fprint(w, `[{"id":1,"name":"alice"}]`) }  func createUser(w http.ResponseWriter, r *http.Request) { 	w.WriteHeader(http.StatusCreated) 	fmt.Fprint(w, `{"id":2,"name":"bob"}`) }  func deleteUser(w http.ResponseWriter, r *http.Request) { 	w.WriteHeader(http.StatusNoContent) }

解析 URL 路径参数（如 /users/123）

net/http 不自动提取路径参数，得自己切分 r.URL.Path。别用正则硬匹配，容易漏掉边界情况；推荐用 strings.Split + 长度判断，简单可靠。

• 路径如 /users/123，应先检查 len(parts) == 3 && parts[0] == "" && parts[1] == "users"
• 避免直接取 parts[2] 而不校验长度，否则 panic
• 数字 ID 建议用 strconv.Atoi 转换，并检查 error

示例片段（接上文）：

立即学习“go语言免费学习笔记（深入）”；

func getUserByID(w http.ResponseWriter, r *http.Request) { 	parts := strings.Split(r.URL.Path, "/") 	if len(parts) != 3 || parts[1] != "users" { 		http.Error(w, "bad path", http.StatusbadRequest) 		return 	} 	id, err := strconv.Atoi(parts[2]) 	if err != nil { 		http.Error(w, "invalid id", http.StatusBadRequest) 		return 	} 	fmt.Fprintf(w, `{"id":%d,"name":"user-%d"}`, id, id) }

正确处理 json 请求体和响应头

很多初学者只写 json.Marshal，却忘了设 Content-Type: application/json，导致前端收到字符串而非 JSON 对象。同样，接收 POST/PUT 数据时，常忽略 req.Body 可能为空或已关闭的问题。

• 响应前必须调用 w.Header().Set("Content-Type", "application/json; charset=utf-8")
• 读取请求体前，确认 r.Method 是 POST 或 PUT，且 r.ContentLength > 0
• 用 io.ReadAll(r.Body) 替代 json.NewDecoder(r.Body).Decode(...) 更安全——后者在 body 关闭后会静默失败

典型错误：没设 header 导致前端 response.json() 报错 “Unexpected Token”。

为什么不用 gorilla/mux 或 chi？

不是不能用，而是过早引入会掩盖对底层机制的理解。比如：gorilla/mux 的 Vars(r) 看似方便，但一旦路由嵌套变深、中间件增多，调试 context 传递和变量生命周期反而更费时间。标准库写法虽然多几行，但每一步都可见、可控、无隐藏行为。

真正该警惕的是“隐式状态”：比如全局变量存用户 session、未关闭的数据库连接、忘记 recover 的 panic。这些比选哪个路由库重要得多。