为什么直接用 map[string]func() 做路由会失败
因为 HTTP 路由不是纯字符串等值匹配——/users/123 和 /users/456 都该命中同一个处理函数，但 map 的键是精确的，无法表达路径参数或通配逻辑。硬塞 map["/users/:id"] 没用，Go 的 map 不解析冒号语法，它只认完整字符串键。
所以别试图把 RESTful 路径当字面量塞进 map 键里。真要用 map，得配合手动解析，或者只做最简前缀/全量匹配。
用 map 实现静态路径精确匹配（适合 /health、/favicon.ico）
这是 map 最自然的用法：HTTP 方法 + 完整路径作为复合键，值为处理函数。安全、无依赖、启动快。
- 推荐用结构体作键，避免拼接字符串带来的歧义（比如
"GET/" + "/path"多斜杠难调试） -
map[struct{method, path string}]func(http.ResponseWriter, *http.Request)是清晰且可比较的 - 注意
http.ServeMux默认会清理重复斜杠和..，但你的map不会——务必在查键前 normalize 路径，例如用strings.TrimSuffix(r.URL.Path, "/")或path.Clean()
<pre class="brush:php;toolbar:false;">type routeKey struct {
method string
path string
}
routes := map[routeKey]func(http.ResponseWriter, *http.Request){
{"GET", "/health"}: func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(200)
w.Write([]byte("ok"))
},
}
// 使用时：
key := routeKey{r.Method, path.Clean(r.URL.Path)}
if h, ok := routes[key]; ok {
h(w, r)
return
}
http.NotFound(w, r)
如何让 map 支持 /users/{id} 这类动态路径
必须自己解析 URL 路径并提取参数，不能靠 map 自动匹配。核心思路是：预定义一组正则或分段规则，用 <code>map 存「模式 → 处理器」，运行时遍历匹配。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 不要用
map[string]存正则，而是用map[*regexp.Regexp]—— 但更推荐用切片+for循环，避免map无序导致优先级混乱 - 常见错误：把
/users/:id直接当 key 存，然后用strings.ReplaceAll替换再查，这会误匹配/users/123/profile - 正确做法是先按
/分割路径段，再逐段比对：固定段（如"users"）严格相等，参数段（如":id"）跳过并记录值 - 建议把路由规则存成
[]struct{ pattern []string; handler func(...) }，查的时候从头遍历，第一个完全匹配的胜出
性能与维护边界在哪
纯 map 查找是 O(1)，但带路径解析的“伪路由”实际是 O(n×m)，n 是路由条数，m 是路径段数。一百条以内没问题；超过三百条，建议换 httprouter 或 gin 的 trie 实现。
容易被忽略的是：没有中间件支持、不自动处理 OPTIONS、不合并重复注册、不校验方法冲突。如果你需要 OPTIONS /api/* 统一返回 CORS 头，或者想给所有 /admin/* 加权限检查——这些都得自己 wrap handler，而 map 本身不提供钩子。
真正简单的服务，比如内部监控端点、配置下发接口，用 map 完全够用；一旦路由变多、要加认证/日志/限流，就该让位给成熟路由库了。
