gorilla/mux正则匹配必须省略^和$，因内部自动添加全段匹配；路由按注册顺序线性扫描，精确字面量须前置；路径字面量不支持正则，RE2引擎不支持负向断言。
gorilla/mux 本身不是高吞吐“核心”，它只是路由匹配层；真正影响吞吐的是你如何用它——注册顺序、正则写法、变量提取方式，三者错一个，请求就卡在 404 或慢匹配上。
gorilla/mux 正则匹配必须省略 ^ 和 $
常见错误是把正则当完整字符串写：{id:^[0-9]+$} 看起来严谨，实际永远 404。mux 内部会自动包裹成 ^/path/(?P<id>[0-9]+)$</id>，你再加 ^ 和 $ 就变成 ^^[0-9]+$$，RE2 引擎直接拒绝编译或静默失效。
正确写法只保留模式主体：
- 正整数（非零）→
{id:[1-9][0-9]*} - 8~32 位十六进制 ID →
{hex:[0-9a-fA-F]{8,32}} - 带斜杠的路径段 →
{path:[a-z0-9\/\.]+}（注意\/和\.必须转义） - 不允许出现
.的 slug →{slug:[a-z0-9_-]+}（.不在字符集中，不用转义）
注册顺序决定匹配结果，不是正则越复杂越优先
gorilla/mux 按注册顺序线性扫描，先命中就停止。哪怕你写了 /api/{id:[0-9]+}，如果它注册在 /api/users 后面，/api/users 仍会被字面量匹配走——这是预期行为，不是 bug。
高频、精确、无变量的路径必须前置：
立即学习“go语言免费学习笔记（深入）”；
r.HandleFunc("/healthz", healthHandler).Methods("GET")r.HandleFunc("/admin/install", installHandler).Methods("POST")- 再注册带变量的泛路径：
r.HandleFunc("/api/{service}/{id:[0-9]+}", proxyHandler).Methods("GET", "PUT") - 最后放兜底通配：
r.PathPrefix("/").Handler(notFoundHandler)（但别放在最前）
把 r.PathPrefix("/") 放第一个，后面所有路由都失效——这是线上事故高频原因。
避免在路径字面量里嵌正则，mux 不识别
/admin/^((?!install).)*$/ 这种写法 mux 当作纯字符串处理，不会执行负向断言，也不会报错，只是永远不匹配真实请求。
RE2 引擎（gorilla/mux 底层依赖）根本不支持 (?!...) 这类语法。可行方案只有两个：
- 显式注册高优排除路由，如先
r.HandleFunc("/admin/install", denyHandler)，再r.HandleFunc("/admin/{subpath}", adminHandler) - 把逻辑后移到 handler：注册
/admin/{subpath}，然后在 handler 里判断if vars["subpath"] == "install" { http.Error(w, "Forbidden", http.StatusForbidden); return }
后者更可控，也更容易单元测试。
正则太宽泛会拖慢匹配，尤其在大量路由时
{path:.+} 看似方便，但它是贪婪匹配，且无法被前缀树优化；当路由数超过 50 条，这种通配会显著拉低整体匹配速度。生产环境应尽量收敛变量范围。
例如，不要用 {id:.+}，而用 {id:[0-9a-f]{24}}（MongoID）、{id:[a-z]{2,16}-[0-9]{6}}（业务生成 ID）等有明确边界的模式。
真正影响吞吐的从来不是 mux 本身，而是你让它的正则引擎反复试错——比如 {path:[^/]+} 比 {path:.+} 快 3 倍以上，因为前者明确告诉引擎“停在下一个 / 前”，后者得一路扫到 URL 结尾。
