gorilla/mux是golang中支撑restful规范落地的核心路由库，提供路径参数、方法约束、子路由分组和中间件注入能力；标准库net/http仅支持静态路径匹配，无法提取{id}或按http方法区分逻辑，易导致api偏离restful原则。
gorilla/mux 是 Golang 中最常用、最贴近 RESTful 规范的路由库之一，它本身不强制你写“规范”，但提供了所有支撑规范落地的底层能力——路径参数、方法约束、子路由分组、中间件注入。用错或漏用关键特性，API 很快就会偏离 RESTful 原则。
为什么不用 net/http 原生路由做 RESTful？
标准库 http.HandleFunc 只支持静态路径匹配，无法提取 /users/{id} 中的 id；也不支持按 HTTP 方法区分同一路径的不同逻辑（比如 /users 同时响应 GET 和 POST）。硬编码字符串解析路径、手动检查 r.Method，不仅易出错，还会让 handler 里塞满胶水代码。而 gorilla/mux 的 Vars(r) 和 .Methods("GET") 直接把语义交给路由层，handler 只管业务。
路径参数必须用 {name}，别用查询参数模拟资源定位
RESTful 的核心是“资源即 URI”，/users/123 表示 ID 为 123 的用户资源；/users?id=123 是 RPC 风格，破坏了缓存语义和幂等性判断。用 gorilla/mux 时：
- 注册路由必须写成
r.HandleFunc("/users/{id}", getUser).Methods("GET")，不是/users?id={id} - 在 handler 中用
params := mux.Vars(r)取值，params["id"]是字符串，需自行转类型（如strconv.Atoi） - 若要限制
{id}只匹配数字，加正则：r.HandleFunc("/users/{id:[0-9]+}", getUser).Methods("GET") - 千万别在 handler 里用
r.URL.Query().Get("id")替代路径参数——这会让 OpenAPI 文档生成失效，也违背资源寻址原则
版本控制别拼接字符串，用 Subrouter + 中间件注入
把版本写死在每个路径里（如 /v1/users、/v2/users）会导致 handler 复制粘贴、测试难覆盖、升级成本高。正确做法是：
- 用
r.PathPrefix("/v1").Subrouter()创建子路由，所有 v1 接口挂在这个 subrouter 下 - 立刻调用
sub.Use(versionMiddleware("v1"))，把版本写进r.Context()，后续 handler 用r.Context().Value(versionKey)安全读取 - 避免用 Accept 头做版本分发——CDN、浏览器预检、反向代理常丢或改这个头，调试时 curl 也得手动加，不可靠
- v2 子路由可复用同一组 handler 函数，只替换序列化逻辑或字段过滤规则，无需重写路由注册
Handler 返回前必须显式设置状态码和 Content-Type
gorilla/mux 不会帮你设 HTTP 状态码或响应头。常见疏漏：
- 成功返回 200 是默认行为，但创建资源应返回 201，删除应返回 204，错误必须返回 4xx/5xx —— 忘设就全是 200，前端无法区分成败
- JSON 响应必须写
w.Header().Set("Content-Type", "application/json; charset=utf-8")，否则某些客户端（尤其是老版 IE 或部分 HTTP 客户端库）会当成 text/plain 解析 - 用
json.NewEncoder(w).Encode(data)比json.Marshal+w.Write更安全，能自动处理流式写入和错误 - 错误响应建议统一结构，比如
{"error": "user not found", "code": "NOT_FOUND"}，并配对应状态码，别直接 panic 或 log 后返回空
http.Error(w, "xxx", 500) 就可能让前端反复 fallback。RESTful 不是语法糖，是约束力。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
