因为http.ServeMux仅支持字面量前缀匹配，不解析正则表达式；若写/user/\d+会被当作静态路径处理，无法动态提取参数，必须自定义Handler结合regexp.MustCompile预编译规则，在兜底路由中手动匹配并捕获子表达式。
为什么 http.ServeMux 不能直接用正则匹配
http.ServeMux 只支持前缀匹配（如 /api/），不接受正则表达式。你写 /user/[0-9]+ 它会当字面路径处理，根本不会解析数字部分。想做动态路由（比如 /user/123 提取 ID），必须绕过它，自己接管 http.Handler 接口。
用 regexp.Regexp 手动匹配并提取参数
核心思路：遍历一组预定义的正则规则，对每个 r.URL.Path 尝试 Regexp.FindStringSubmatch 或 Regexp.FindStringSubmatchIndex，成功就调用对应 handler，并把捕获组转成 map 传入。
常见错误是忽略路径开头的 / 或未做 strings.TrimPrefix(r.URL.Path, "/") —— 正则里写 ^user/(\d+)$ 时，如果原始路径是 /user/42，那必须确保正则能匹配完整路径（或统一 trim 后再匹配）。
示例关键片段：
var routes = []struct {
re *regexp.Regexp
handler func(http.ResponseWriter, *http.Request, map[string]string)
}{
{regexp.MustCompile(`^/user/(\d+)$`), userHandler},
{regexp.MustCompile(`^/post/([a-z0-9\-]+)/edit$`), postEditHandler},
}
func router(w http.ResponseWriter, r *http.Request) {
for _, route := range routes {
matches := route.re.FindStringSubmatchIndex([]byte(r.URL.Path))
if matches != nil {
// 提取第一个捕获组（ID 或 slug）
start, end := matches[1][0], matches[1][1]
param := r.URL.Path[start:end]
route.handler(w, r, map[string]string{"param": param})
return
}
}
http.NotFound(w, r)
}
注意 http.Request.URL.Path 的编码问题
浏览器发来的路径可能含 URL 编码（如空格变 %20），但 r.URL.Path 默认已解码。这意味着你写的正则应对解码后的字符串匹配，而不是原始字节流。但要注意：r.URL.RawPath 是未解码的，别误用它。
另一个坑：某些代理或网关会重写路径，导致 r.URL.Path 和实际请求路径不一致。上线前建议加日志打出来看一眼真实值。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
兼容性提示：Go 1.22+ 对 Unicode 路径支持更好，但正则引擎本身不自动处理 UTF-8 边界 —— 如果要匹配中文路径（如 /文章/(\d+)），确保正则用了 (?U) 标志或用 \p{Han} 类。
要不要用第三方库？gorilla/mux 和 chi 的差异
gorilla/mux 支持 {id:[0-9]+} 这类语法，底层仍是正则，但封装了变量提取和类型转换；chi 更轻量，用中间件链 + URLParam(r, "id")，正则能力弱些（主要靠通配符 * 和 {id} 占位）。两者都不支持任意复杂正则（比如负向先行断言），真需要就得自己写 handler。
性能上，纯正则匹配比 chi 的树形路由略慢，但 QPS 在万级以下几乎无感；可维护性上，手写正则容易散落、难调试，建议把路由表集中定义，加上注释说明每条正则的意图和典型匹配样例。
最易被忽略的一点：正则编译开销。别在 handler 里反复调用 regexp.Compile，所有 *regexp.Regexp 必须提前 var re = regexp.MustCompile(...) 全局初始化。
