Go标准库http.ServeMux不支持正则路由，仅支持前缀和固定路径匹配；需用gorilla/mux（段级正则约束）、chi（配合手动校验）或自实现正则匹配器，并注意URL解码、锚定及编译优化。
Go HTTP ServeMux 不支持正则路由，必须换实现
标准库 http.ServeMux 只支持前缀匹配和固定路径，不解析正则。想用 /user/(\d+) 或 /post/(.*)/edit 这类规则，得自己写匹配逻辑或选支持正则的第三方路由（比如 gorilla/mux、chi，或手撸一个轻量匹配器）。
常见错误是直接往 http.HandleFunc 里传带括号的字符串，结果 404 —— 它根本不识别正则语法，只是按字面字符串做前缀比对。
用 gorilla/mux 实现命名捕获组 + 正则约束
gorilla/mux 是最常用的可扩展路由库，原生支持正则约束和变量捕获，且语义清晰。它不是“把整个路径当正则”，而是在路径段级别加 {name:pattern} 约束，更安全、易维护。
-
r.HandleFunc("/user/{id:[0-9]+}", userHandler)——id必须为纯数字，匹配成功后可通过mux.Vars(r)["id"]取值 -
r.HandleFunc("/file/{path:.+}", fileHandler)—— 允许斜杠，等价于通配子路径 - 多个段可混合：
/api/v{version:[12]}/{resource:[a-z]+}/{id:[0-9]+} - 注意：
gorilla/mux的正则只作用于单个路径段（即两个/之间的部分），不跨段；如需跨段匹配，得用中间件预处理或改用chi的Mount+ 自定义匹配
手动实现正则路由时必须处理 URL 解码和边界
如果不用框架、自己用 regexp.MustCompile 匹配 r.URL.Path，有三个关键点绕不开：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 路径在到达 handler 前已被 Go 标准库自动解码（如
%2F→/），所以你的正则应面向解码后的字符串写，别对着原始RequestURI写 - 必须锚定开始和结束：
^/user/([0-9]+)$，否则/user/123/extra也会被^/user/([0-9]+)错误匹配 - 捕获组顺序和数量要和
FindStringSubmatch返回切片严格对应；建议用FindStringSubmatchIndex配合path[i:j]提取，避免越界 - 性能敏感场景下，正则编译应提前完成（
var userRE = regexp.MustCompile(`^/user/([0-9]+)$`)），禁止在 handler 内反复Compile
chi 路由的正则支持有限，靠 URLParam + 中间件补足
chi 默认不提供段级正则语法，它的 {id} 是无约束通配。但可通过组合方式逼近需求：
- 先用
r.Get("/user/{id}", userHandler)接收所有/user/*，再在 handler 内部用chi.URLParam(r, "id")取值，并手动校验是否符合^[0-9]+$ - 或写一个中间件：
func validateID(next http.Handler) http.Handler { ... }，校验失败直接http.Error(w, "Bad ID", 400) - 不推荐用
chi的Route+regexp.MatchString做全路径匹配 —— 它会破坏chi的树状路由优化，退化成线性遍历，路径多时延迟明显上升
真正需要复杂正则（比如 host + path 联合匹配、查询参数参与路由）时，往往已超出 HTTP 路由层职责，更适合放在业务入口或反向代理（如 Nginx）中处理。
