关键是要显式调用.methods("get")限定http方法，否则路由可能不匹配；路径参数需正则约束、唯一命名且与vars键一致；vars为空主因是请求未匹配路由，而非解析失败。
gorilla/mux 怎么写带参数的路由才不会 404
关键不是“怎么写”，而是 router.HandleFunc 注册后必须用 .Methods("GET") 显式限定方法，否则默认接受所有方法，但实际匹配时若没声明方法，它可能跳过该路由或被后续更宽松规则覆盖。
- 错误写法：
r.HandleFunc("/users/{id}", handler)—— 没加.Methods()，看似注册了，但请求GET /users/123可能不命中（尤其有其他通配路由时） - 正确写法：
r.HandleFunc("/users/{id:[0-9]+}", handler).Methods("GET")—— 正则约束 + 方法限定，双重保险 - 路径变量名必须唯一且与
mux.Vars(r)["id"]中键一致；写成{userID}却取vars["id"]会返回空字符串 - 正则中特殊字符如
/、=必须在方括号内显式列出，例如{path:[a-zA-Z0-9\/\=]+}，漏掉转义会导致匹配失败
mux.Vars(r) 返回空 map 是什么原因
mux.Vars(r) 为空，90% 是因为请求根本没匹配到你定义的那条路由——不是解析失败，是压根没进这条 route。
- 检查请求路径是否严格匹配：比如路由是
/api/v1/users/{id}，但你发的是/api/users/123，差一个v1就不匹配 - 确认
http.ListenAndServe(":8080", r)传入的是mux.Router实例，不是nil或标准库http.DefaultServeMux - 如果用了子路由（
Subrouter()），确保 handler 是注册在子路由上，而不是父 router 上，否则Vars查不到该子路由定义的参数 -
mux.Vars(r)不处理查询参数（?page=2），那是r.URL.Query().Get("page")的事；混淆这两者会导致“取不到值”的错觉
如何安全地把路由参数转成 int 或 struct
从 mux.Vars(r) 拿到的全是 string，直接 strconv.Atoi 或 JSON 解析前，必须先校验非空和格式，否则 panic 或静默失败。
- 别省略判空：
idStr := mux.Vars(r)["id"]; if idStr == "" { http.Error(w, "missing id", http.StatusBadRequest); return } - 数字转换用
strconv.ParseInt(idStr, 10, 64)而非Atoi，后者底层调ParseInt但丢弃err细节，出错难定位 - 若需批量解析（如
/posts/{category}/{year}/{month}），建议封装一个parseRouteParams(r *http.Request, target interface{}) error，用反射或结构体 tag 统一绑定，避免重复写 5 行vars["xxx"] - 正则约束（如
{id:[0-9]+}）只是匹配阶段过滤，不代表参数一定合法；攻击者仍可构造超长数字触发整数溢出，所以业务层仍需范围检查
为什么加了中间件，路由参数却取不到了
中间件包装顺序错了。gorilla/mux 的 r.Use(middleware) 是全局前置，但如果你在中间件里提前调用了 next.ServeHTTP，又没透传 request context，mux.Vars(r) 就会丢失。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：中间件里写了
r.Context()相关操作但没调用context.WithValue保存 vars，或误用了req = req.WithContext(...)却没赋值回原变量 - 正确姿势：中间件函数签名保持
func(http.Handler) http.Handler，内部只做逻辑，不干预mux.Vars的上下文绑定机制 - 调试技巧：在中间件末尾加一行
log.Printf("vars: %+v", mux.Vars(req))，如果已为空，说明路由根本没匹配成功，问题不在中间件本身 - 子路由上单独加中间件（
subrouter.Use(auth)）比全局更安全，避免无关路由被干扰
{id:[0-9]{6}}）会比宽泛的（{id}）优先匹配。这点不看源码很容易误以为“后注册的覆盖前面的”，实际它靠的是 matcher 集合的布尔交集判断，不是简单字符串替换。 
