Go标准库http.ServeMux不支持动态路由参数，需用gorilla/mux或chi等第三方路由器；前者用mux.Vars(r)取:param，后者用chi.URLParam(r,"param")；均需手动类型转换并注意404语义区分。

Go 的 http.ServeMux 不支持动态路由参数

直接用标准库的 http.ServeMux 无法解析像 /user/:id 或 /post/{slug} 这类带命名参数的路径。它只认固定前缀匹配（如 /user/），遇到 /user/123 和 /user/456 会被当作同一前缀，后续参数得自己从 r.URL.Path 里切分、校验、转换——容易出错且重复造轮子。

所以真实项目中，几乎都会换用支持路径模式匹配的路由器，比如 gorilla/mux、chi 或 gin。它们不是“可选”，而是事实标准。

用 gorilla/mux 提取 URL 路径参数

gorilla/mux 是最贴近标准库风格的第三方路由器，学习成本低，且明确区分路径参数（:name）和通配符（{name}）。它把参数存进 request.Context，需用 mux.Vars(r) 拿。

• :id 表示单段路径参数（不包含 /），例如 /user/:id 匹配 /user/7，但不匹配 /user/7/edit
• {path:.*} 才能捕获含斜杠的剩余路径，比如 /files/{path:.*}
• 参数值默认是字符串，需手动转类型（如 strconv.Atoi），mux 不做隐式转换
• 路由顺序重要：更具体的路由要写在前面，否则 /user/:id 可能提前匹配掉 /user/profile

package main

import (
    "fmt"
    "net/http"
    "strconv"

    "github.com/gorilla/mux"
)

func userHandler(w http.ResponseWriter, r *http.Request) {
    vars := mux.Vars(r)
    idStr := vars["id"]
    id, err := strconv.Atoi(idStr)
    if err != nil {
        http.Error(w, "invalid id", http.StatusBadRequest)
        return
    }
    fmt.Fprintf(w, "User ID: %d", id)
}

func main() {
    r := mux.NewRouter()
    r.HandleFunc("/user/{id:[0-9]+}", userHandler).Methods("GET")
    http.ListenAndServe(":8080", r)
}

chi 中的参数获取更轻量，但路径语法略有不同

chi 用 {id}（无冒号）表示参数，且内置了中间件链和更简洁的嵌套路由。参数通过 chi.URLParam(r, "id") 获取，不依赖 Context 变量映射，对新手更直观。

• 不支持正则内联（如 {id:[0-9]+}），需靠中间件或 handler 内校验
• 嵌套路由自然支持：比如 r.Route("/api", func(r chi.Router) { r.Get("/users/{id}", h) })
• 如果没注册任何中间件，chi 性能略优于 gorilla/mux，因底层用的是 trie 树匹配

package main

import (
    "fmt"
    "net/http"
    "strconv"

    "github.com/go-chi/chi/v5"
)

func userHandler(w http.ResponseWriter, r *http.Request) {
    idStr := chi.URLParam(r, "id")
    id, err := strconv.Atoi(idStr)
    if err != nil {
        http.Error(w, "bad id", http.StatusBadRequest)
        return
    }
    fmt.Fprintf(w, "User %d", id)
}

func main() {
    r := chi.NewRouter()
    r.Get("/user/{id}", userHandler)
    http.ListenAndServe(":8080", r)
}

别忽略 404 和参数校验的组合陷阱

很多人只关注“怎么取参数”，却忘了两个关键点：一是路由器匹配成功但参数格式非法（如 /user/abc），二是路径根本没被任何路由注册（/unknown）。这两者都返回 404，但原因完全不同，前端或监控很难区分。

• 用正则约束路径（如 {id:[0-9]+}）能让非法参数直接 404，避免进 handler 再判断
• 确保有兜底 404 处理：在 gorilla/mux 中调 r.NotFoundHandler = my404；chi 则用 r.NotFound(my404)
• 若业务要求“ID 必须存在”，那 404 应由 handler 返回（http.StatusNotFound），而不是靠路由层——因为数据库查无此 ID 和路径压根不匹配，语义不同

动态路由本身不难，难的是让错误可定位、参数可预期、边界情况不漏掉。越早用上带参数验证能力的路由器，后面越少写 strings.Split 和 len(pathParts) 这类脆弱逻辑。