最直接的方式是调用 mux.vars(r)["name"] 提取 gorilla/mux 通配符路径段，该方法自动解码 url 编码字符并返回命名段的字符串值，无需手动解析或正则匹配。
用 gorilla/mux 提取通配符路径段最直接的方式
Go 标准库 http.ServeMux 不支持路径通配符，必须换用第三方路由库。目前最稳定、被广泛采用的是 gorilla/mux，它通过 {name} 语法定义变量段，并用 req.URL.Path 原始路径做兜底。
常见错误是试图从 http.Request.URL.Path 直接切分——这会漏掉 URL 编码字符（如空格变成 %20），且无法区分同名但不同位置的变量。
- 注册路由时写
r.HandleFunc("/api/v1/users/{id}", handler).Methods("GET") - 在 handler 中调用
chi.URLParam(r, "id")（如果用 chi）或mux.Vars(r)["id"]（如果用 gorilla/mux） -
mux.Vars(r)返回map[string]string，所有 key 都是字符串，value 已自动解码（%20→ 空格）
处理多级嵌套通配符路径（比如 /a/{x}/b/{y}/c）
多个通配符可以共存，但要注意命名唯一性：不能有两个 {id}，否则后一个会覆盖前一个。实际提取时，每个名字对应一个独立字段。
典型场景是 RESTful 资源嵌套：/orgs/{org_id}/repos/{repo_name}/issues/{issue_id}。这种路径下，mux.Vars(r) 返回的 map 里会有三个 key："org_id"、"repo_name"、"issue_id"，值都是原始路径中对应段的已解码字符串。
- 不要用正则手动匹配——
gorilla/mux内部已处理转义和边界，手动解析易出错 - 若某段可能为空（如
/path/{optional}/end），需在路由注册时加约束：{optional:.*}，否则该路由不会被匹配 - 路径中出现
.或-不影响提取，mux默认不校验内容格式
用 chi 替代 gorilla/mux 的关键差异
chi 更轻量、API 更简洁，但提取方式略有不同：不用 mux.Vars()，而是调用 chi.URLParam(r, "key") 单独取值。它不提供全局 vars map，适合只读少数几个变量的场景。
错误现象：用 chi 却调 mux.Vars(r)，返回空 map；或者忘记 import github.com/go-chi/chi/v5 导致编译失败。
-
chi的通配符写法一样：/users/{id}，但必须用chi.Router实例注册，不能混用http.ServeMux -
chi.URLParam(r, "id")返回string，若 key 不存在则返回空字符串（不是 panic），需自行判空 -
chi支持通配符后缀：/files/{name:*}可捕获剩余全部路径，此时chi.URLParam(r, "name")返回带斜杠的子路径（如"a/b/c.txt"）
容易被忽略的编码与边界问题
路径段中含中文、空格、斜杠等字符时，浏览器会自动编码，而 mux 和 chi 都做了自动解码。但如果你手动拼接重定向 URL 或生成链接，得再用 url.PathEscape() 编码，否则可能 404。
另一个坑是 trailing slash：路由定义为 /api/{id}/（末尾有斜杠）和 /api/{id} 是两条不同路由，即使请求带斜杠，也不会自动重定向。调试时看到 404 但路径看起来对，先检查末尾斜杠是否一致。
- 用
url.PathUnescape()手动解码仅在极少数绕过框架时需要，正常情况不必调用 - 如果通配符段里要包含
/，必须用{name:*}（chi）或{name:.+}（mux），普通{name}不匹配斜杠 - 测试时用
curl -v "http://localhost:8080/api/v1/user/%E4%BD%A0%E5%A5%BD"比直接输中文更可靠，避免 shell 编码干扰
mux.Vars(r) 或 chi.URLParam() 一行搞定，真正要花时间的是设计好通配符命名和处理空值、非法字符的边界逻辑。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
