gorilla/mux中正则需显式转义/和.，否则匹配失败；{path}仅控制路由匹配，不处理路径归一化或查询参数；子路由参数仅在其上下文中注入，须正确挂载；mux.Vars为空主因是请求未命中路由，常见于路径、Host、Scheme不匹配或漏设Methods。
gorilla/mux 中 {path} 正则必须显式转义 / 和 .
写 {path:[a-z0-9./_-]+} 会意外匹配失败，因为 . 在正则里是“任意字符”，/ 是字面量但未被转义，实际行为不可控。正确写法是 {path:[a-zA-Z0-9\/\._-]+}——斜杠加反斜杠、点也加反斜杠。
常见错误现象：GET /files/a/b/c.json 返回 404，但路径明明注册了 /files/{path}；查日志发现请求压根没进 handler，mux.Vars(r) 是空 map。
- 正则只控制“是否进入该路由”，不负责解码或归一化；
/files//a/b（双斜杠）不会自动变成/files/a/b，得靠path.Clean()预处理 - 想匹配带查询参数的完整路径？别在正则里搞，
r.URL.RawQuery是独立字段，{path}只管Path部分 - 如果要允许空段（比如
/api//v1），不能依赖正则兜底，得在 handler 开头用path.Clean(r.URL.Path)统一规整
Subrouter 注册后 vars 查不到？检查 handler 挂载位置
子路由定义的参数，只在子路由上下文里注入。写 v1 := r.PathPrefix("/api/v1").Subrouter() 后，v1.HandleFunc("/users/{id}", h) 才有效；若误写成 r.HandleFunc("/users/{id}", h)，mux.Vars(r) 就永远拿不到 id。
使用场景：API 版本隔离、权限分组、静态资源前缀剥离。例如挂载 /static/ 子路由时，http.FileServer 收到的 r.URL.Path 仍是 /static/js/app.js，必须用 http.StripPrefix("/static/", fs) 清理前缀，否则打开文件路径错位。
立即学习“go语言免费学习笔记（深入）”；
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 子路由不继承父路由的
.Methods()，每个HandleFunc必须单独链式调用.Methods("GET") -
v1.Use(authMiddleware)只影响子路由下的 handler，父路由注册的 handler 不受其约束 - 调试技巧：打印
r.URL.Path和r.Host，确认请求是否真进了子路由——很多 404 其实是 Host 或 Scheme 不匹配导致的
为什么 mux.Vars(r) 总是空？先看请求有没有真正命中路由
mux.Vars(r) 返回空 map，基本不是解析出错，而是请求根本没走到那条 route。比如注册了 /api/v1/users/{id}，却发了 GET /users/123，少了个 v1，就直接跳过。
容易踩的坑：
- 漏写
.Methods("GET")：没限定方法的路由匹配优先级极低，容易被后面带.Methods()的更宽泛路由（如/*）提前捕获 -
http.ListenAndServe(":8080", r)传的是nil或http.DefaultServeMux，不是你那个mux.NewRouter()实例 - Host 头不一致：浏览器访问
http://myapp.dev:8080，实际发送的 Host 头是myapp.dev:8080，不是myapp.dev；得写r.Host("myapp.dev:8080")或用正则r.Host(`{host:.+}:8080`) - Scheme 不匹配：
r.Schemes("https")要求协议是 HTTPS，本地开发用http://就直接 404
路径重写不能只靠路由注册，http.StripPrefix 和自定义 Handler 得配合用
gorilla/mux 本身不提供“重写 URL 路径后转发”的能力。它只做匹配和变量提取。真要实现类似 Nginx 的 rewrite ^/api/(.*) /v1/$1 break，得组合三层：
- 用
r.PathPrefix("/api/").Handler(...)拦截所有/api/开头的请求 - 在 handler 内部用
path.Join("/v1", strings.TrimPrefix(r.URL.Path, "/api/"))构造新路径 - 手动修改
r.URL.Path（注意：修改后r.RequestURI不变，不影响响应头；但中间件读取r.URL.Path时会看到新值）
性能影响：每次请求都做字符串操作，高频路径下可缓存 strings.TrimPrefix 结果；若需正则重写（如把 /old/:id → /new/:id），建议用 regexp.ReplaceAllStringFunc 预编译，避免 runtime 编译开销。
最常被忽略的一点：修改 r.URL.Path 后，后续中间件或 handler 若依赖原始路径做鉴权或日志，就可能出错——重写逻辑必须放在整个中间件链最前端，且文档写明“此 handler 已重写 Path”。
