go 的 net/http 不支持正则路由，需自定义 handler 实现：预编译正则、用 findstringsubmatchindex 提取带编码的原始参数，并注意 gorilla/mux 的正则语法限制与性能风险。
Go 的 net/http 本身不支持正则路由，得自己写匹配逻辑
标准 http.ServeMux 只支持前缀匹配（/api/），不识别 /user/d+ 这类模式。想用正则做动态路由，必须绕过它，自己接管 http.Handler 的 ServeHTTP 方法，对每个请求的 r.URL.Path 做正则比对。
常见错误是直接在 http.HandleFunc 里塞正则判断——这会导致所有路径都进同一个 handler，后续无法按组提取参数，也丢失了路由分发语义。
- 正确做法：维护一个
[]struct{ pattern *regexp.Regexp, handler http.Handler }列表，遍历时用pattern.FindStringSubmatch或pattern.FindStringSubmatchIndex获取匹配位置和子组 - 注意
regexp.Compile开销大，必须提前编译好、缓存起来，不能每次请求都Compile - 路径开头的
/必须显式写进正则，比如^/user/(d+)$，否则/user/123和/user/123/profile都会命中
提取 URL 参数要用 FindStringSubmatchIndex 而不是 FindString
FindString 只返回匹配字符串，丢掉了位置信息；而路由参数（如 (d+)）需要知道它在原路径中的起止索引，才能从 r.URL.Path 中切出原始值——这对处理带特殊字符（如 %2F）的路径很关键。
示例：r.URL.Path 是 /post/123%2Fabc，正则 ^/post/([^/]+)$ 匹配后，用 FindStringSubmatchIndex 得到 [6 13]，再取 r.URL.Path[6:13] 就是完整编码段，避免提前 url.PathUnescape 引入歧义。
- 子组索引从 1 开始（0 是全匹配），
matches[1][0]是第一个捕获组起点，matches[1][1]是终点 - 务必检查
matches != nil且len(matches) > 1，否则访问matches[1]会 panic - 不要依赖
regexp.ReplaceAllString提取参数——它会自动 unescape，破坏原始编码
gorilla/mux 默认不启用正则，需手动配置 PathRegexp
如果不想重复造轮子，gorilla/mux 确实支持正则，但默认关闭。它的 Path 方法只做静态匹配；要启用正则，必须用 PathRegexp 或在 Path 中写 {id:[0-9]+} 这种内联语法。
容易踩的坑是误以为 r.Path("/user/{id:\d+}") 就能工作——实际 gorilla/mux 不解析 \d+，必须写成 {id:[0-9]+}（方括号内是正则片段，且不能有空格）。
-
PathRegexp("/user/([0-9]+)")是合法的，但捕获组不会自动注入request.Context()，得自己调mux.Vars(r)或解析URL.Path - 推荐用内联变量语法：
r.Path("/user/{id:[0-9]+}")，这样mux.Vars(r)才能返回map[string]string{"id": "123"} - 注意
gorilla/mux的正则引擎不支持^和$锚点，整个表达式默认被当作“以该模式开头”处理
性能敏感场景下，避免在路由层做复杂正则回溯
像 /a+/b+/c+ 这类正则在恶意构造路径（如 /a/a/a/.../b/b/b/.../c/c/c/...）时可能触发指数级回溯，导致 CPU 占满。Go 的 regexp 包虽有回溯限制，但默认阈值高（regexp.DefaultMaxMem），线上服务仍可能卡顿。
- 生产环境建议给每个正则设置
regexp.Compile(`pattern`, regexp.MustCompileOptions{MaxMem: 1024 * 1024}) - 优先用前缀树（trie）或静态路由兜底：把高频路径（如
/health、/metrics）单独放最前面，快速返回，减少正则扫描次数 - 避免在正则中使用
.*或嵌套量词，改用更精确的字符集，例如[^/]+替代.*匹配路径段
正则路由不是银弹，真正难的是平衡表达力和执行效率——路径越灵活，越要小心模式本身的可终止性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
