ServeMux仅支持严格前缀匹配且无参数解析，不区分HTTP方法、不支持路径参数和中间件，易导致路由冲突与404错误，现代REST API应选用gorilla/mux或chi等替代方案。
Go 标准库的 net/http.ServeMux 确实能做路由，但它只支持**严格前缀匹配 + 无参数解析**，不适合现代 Web 服务——别硬用它写 REST API。
为什么 ServeMux 的 Handle 和 HandleFunc 不适合动态路径
ServeMux 内部用的是最长前缀匹配，不支持路径参数（如 /user/123 中的 123）、不区分 GET/POST、也不支持通配符（/api/v1/* 是特例，且仅限末尾星号）。
-
http.HandleFunc("/user", handler)会同时匹配/user、/user/、/user/profile、/users（因为/users以/user开头）——这是常见误用根源 - 没有内置方法获取 URL 路径段，
r.URL.Path得手动strings.Split，易出错且无法处理嵌套层级 - 注册顺序无关紧要，
Handle总是按前缀长度优先，无法覆盖或优先级控制
绕过 ServeMux 实现简单参数路由的最小改动方案
如果必须用标准库、又想支持 /post/42 这类结构，可封装一层路径解析，避免引入第三方路由库。
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
parts := strings.Split(strings.Trim(r.URL.Path, "/"), "/")
if len(parts) >= 2 && parts[0] == "post" {
if id, err := strconv.Atoi(parts[1]); err == nil {
fmt.Fprintf(w, "Post ID: %d", id)
return
}
}
http.NotFound(w, r)
})
http.ListenAndServe(":8080", mux)
}
- 务必用
strings.Trim(r.URL.Path, "/")去掉首尾斜杠，否则"/post/42"分割后首项为空字符串 - 不要依赖
len(parts) > 1就取parts[1]，先检查len(parts) >= 2，防止 panic - 这种写法仍无法处理查询参数绑定、中间件、method 检查——只是权宜之计
什么时候该果断放弃 ServeMux
一旦出现以下任一需求，ServeMux 就不再是“够用”，而是“埋雷”：
立即学习“go语言免费学习笔记（深入）”；
- 需要
GET /api/users和POST /api/users同路径不同方法 →ServeMux无 method 路由能力 - 需要
/files/{name}.{ext}这类带命名参数的模式 → 它只认固定字符串或/* - 需要
OPTIONS预检、CORS 中间件、JWT 鉴权链式处理 →ServeMux不提供中间件机制 - 团队协作中其他人误加
Handle("/user", ...)导致路径冲突 → 没有注册冲突检测或警告
真要轻量，用 gorilla/mux 或 chi，它们兼容 http.Handler 接口，替换成本极低；硬撑 ServeMux 只会让后续维护者在日志里反复看到 404 on /user/123 却查不出哪段代码劫持了路径。
