http.ServeMux不支持动态路由因其仅支持静态前缀匹配，不支持路径参数、正则、运行时注册，且注册表启动后冻结；gorilla/mux等库的“动态”指配置期灵活，非运行时修改。
为什么直接用 http.ServeMux 不行
http.ServeMux 只支持静态路径匹配和简单跳转，没法在路由分发前插入逻辑（比如鉴权、日志、请求体解析）。它没有中间件机制，HandleFunc 注册的函数是最终 handler，无法被“包装”或“拦截”。想加过滤逻辑，就得自己造一层分发器。
用 http.Handler 接口组合实现链式中间件
核心思路是让每个中间件返回一个新的 http.Handler，把原始 handler 包进去。这样就能层层套娃，形成执行链。关键不是“注册中间件”，而是“构造 handler 链”。
实操建议：
- 定义中间件类型：
type Middleware func(http.Handler) http.Handler - 路由分发器本身实现
http.Handler接口，ServeHTTP方法里先做匹配，再把匹配到的 handler 依次套上所有中间件 - 注意中间件顺序：越靠前的 middleware 越早执行（比如日志应在鉴权之后？不，日志通常放最外层，方便统计所有请求）
- 避免在中间件里重复调用
next.ServeHTTP—— 这会导致 panic 或死循环
示例片段：
func AuthMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if r.Header.Get("X-Api-Key") == "" {
http.Error(w, "Unauthorized", http.StatusUnauthorized)
return
}
next.ServeHTTP(w, r) // 只调用一次
})
}
路由匹配要支持路径参数和通配符
单纯用 strings.HasPrefix 或 == 匹配太弱，没法处理 /users/:id 或 /static/*filepath 这类需求。得自己写轻量级匹配器，或借用 net/http 的 Pattern 规则（但它的 * 只支持后缀匹配）。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
常见错误现象：
- 用
strings.Contains匹配/api，结果/api/v1和/myapi/xxx全被误中 - 把
:id当字面量处理，没提取实际值，导致后续 handler 拿不到参数 - 没处理 trailing slash 差异（
/usersvs/users/），造成 404
建议：为每个路由规则存一个 pattern 字符串 + 一个 matcher func(string) (map[string]string, bool)，运行时动态提取参数。
中间件与路由绑定粒度怎么控制
全局中间件（如日志）好办，但有些只该跑在 /admin/* 下，有些只对 POST 生效。硬编码进分发器会很快失控。
实操建议：
- 不要只提供 “全局中间件列表”，额外支持 per-route middleware：注册路由时传入
[]Middleware - 区分
Use()（全局）和UseFor(pathPrefix string, m ...Middleware)（前缀级） - 注意中间件作用域叠加：如果全局注册了
Logging，又在/api上注册了Auth，那/api/users会先 log 再 auth；但如果/api的中间件里也调用了log，就重复了 - 别在中间件里修改
r.URL.Path后不重置r.URL.RawPath—— 某些 handler（比如http.FileServer）依赖后者，可能出错
复杂点在于：中间件执行时机和 error 处理边界必须清晰。比如鉴权失败时，中间件应直接 write response 并 return，不能继续调用 next；而日志中间件必须保证 next.ServeHTTP 执行完再记录耗时 —— 这种差异容易被忽略。
