因为http.ServeMux仅支持静态前缀匹配，不识别路径参数（如/users/:id）、不支持正则、无法提取变量、无中间件机制，且注册的handler是终点，不能在分发前插入鉴权或日志等逻辑。
标准库 http.ServeMux 无法满足动态路由 + 中间件过滤需求，必须自己实现 http.Handler 并组合中间件链。
为什么 http.ServeMux 不行
http.ServeMux 只做静态前缀匹配，比如注册 /api 就会匹配 /api/users 和 /api/v1/health，但无法识别路径参数（如 /users/:id）、不支持正则、不能在匹配后提取变量、也不允许在分发前插入逻辑。它注册的 HandleFunc 是终点 handler，没有“包装”入口——你想加鉴权或日志，就得手动改每个函数，违背 DRY 原则。
常见错误现象：
- 用
strings.Contains(r.URL.Path, "/api")判断，结果/myapi/token也被误判为 API 请求 - 把
:id当字面量写死在比较里，没做实际段提取，后续 handler 拿不到值 - 忽略 trailing slash 差异，
/users和/users/被当成两个不同路由，一个 404
Middleware 类型定义与链式调用顺序
中间件本质是函数式包装器：接收一个 http.Handler，返回一个新的 http.Handler。执行顺序由嵌套位置决定——最外层最先执行，最内层最后执行。
立即学习“go语言免费学习笔记（深入）”；
定义方式必须统一：
-
type Middleware func(http.Handler) http.Handler—— 所有中间件都按这个签名写 - 链式构造推荐用左结合：比如
Logging(Auth(Recovery(router)))，意味着请求进来先走Logging，再Auth，最后到router；响应返回时顺序相反 - 切忌在中间件里多次调用
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) // 只调用一次
})
}
路由匹配需支持参数提取和上下文注入
简单 map 查找或前缀判断不够用。真实场景要能处理 /users/:id、/files/*filepath 这类模式，并把捕获的值传给 handler。
关键实操点：
- 不要直接修改
*http.Request字段，而是用req = req.WithContext(context.WithValue(req.Context(), key, value))注入参数 map - 匹配逻辑建议拆成两步：先比对路径结构（如按
/分割后逐段对比，遇到:name就捕获），再生成map[string]string参数表 - 避免用
net/http的Pattern（比如"*"只支持后缀匹配），它不解决路径参数问题 - 如果路由规则多，别硬写 if-else，用轻量 trie 或预编译正则提升性能，但小项目用 slice 遍历也够用
中间件作用域控制：全局 / 分组 / 局部
不是所有中间件都要套在最外层。合理分层才能避免无谓开销：
- 全局中间件（如日志、recover）放在顶层，统一路由器入口处
- 分组中间件（如
/admin/*下全部需要 RBAC）可封装为子路由器，内部维护自己的中间件栈 - 局部中间件（如某个 POST 接口强制要求 JSON body）应在注册 handler 时单独包装：
router.HandleFunc("/upload", Auth(MustJSON(uploadHandler))) - 注意中间件初始化时机：若依赖 DB 连接或配置，确保在
ListenAndServe前完成构造，否则运行时报 nil panic
最容易被忽略的是参数提取后的生命周期管理——context.Value 里的键必须是导出的、全局唯一的类型（比如 type ctxKey string），而不是字符串字面量，否则跨包取值会失败。
