Go 1.22 的 http.ServeMux 新增方法前缀匹配和单段路径通配符能力，支持如 "GET /users/{id}" 注册，通过 r.PathValue("id") 获取值；但不支持正则、跨段通配或子路由，复杂需求仍需第三方框架。
Go 1.22 的 http.ServeMux 确实能替代轻量级路由框架，但前提是你的需求不超出它新增的两个能力边界：HTTP 方法前缀匹配 + 单段路径通配符（{name}）。超过这个范围，就得换方案。
怎么写带方法和通配符的路由注册
Go 1.22 后，http.ServeMux 支持在模式字符串里直接写 GET /users/{id} 这类形式。注意不是所有写法都合法：
-
GET /users/{id}✅ 合法：方法 + 空格 + 路径 + 通配符 -
GET/users/{id}❌ 非法：方法和路径之间必须有空格 -
/users/{id}/profile✅ 合法：通配符可出现在中间或末尾，但不能跨段（{id}/profile是单段，{id}/profile/{sub}也是合法的） -
/users/{id:.*}❌ 非法：不支持正则表达式，只接受裸名{id} -
/users/{id}/和/users/{id}是两个不同模式，后者不匹配末尾带斜杠的请求
注册后，用 r.PathValue("id") 拿值，不是 r.URL.Query().Get()，也不是从 r.URL.Path 手动切分。
为什么 PathValue 返回空
常见于三类情况：
立即学习“go语言免费学习笔记（深入）”；
- 请求路径没完全匹配注册的模式，比如注册了
GET /api/v1/users/{id}，却发了GET /api/v1/users/123/（多了一个尾部斜杠） - 通配符名大小写不一致：
r.PathValue("ID")拿不到{id}的值，必须严格对应 - 用了
http.HandleFunc包裹旧式全局 mux（如http.HandleFunc("/xxx", handler)），这种调用绕过了 1.22 新增的通配符解析逻辑，PathValue始终为空
务必使用显式创建的 http.ServeMux 实例，并调用其 HandleFunc 方法：
mux := http.NewServeMux()
mux.HandleFunc("GET /task/{id}", func(w http.ResponseWriter, r *http.Request) {
id := r.PathValue("id") // ✅ 此时 id 才有效
fmt.Fprintf(w, "id=%s", id)
})
http.ListenAndServe(":8080", mux)
多个模式冲突时谁生效
http.ServeMux 会选“最具体”的那个模式，规则是：
- 带方法前缀的比不带的更具体（
POST /login>/login） - 路径越长越具体（
/a/b/{c}>/a/{b}） - 通配符位置越靠前越不具体（
/{a}/b和/a/{b}相比，后者更具体） - 同长度下，字面量段比通配符段更具体（
/users/active/{id}>/users/{status}/{id}）
没有“优先级序号”或“注册顺序”概念。如果两个模式一样具体（比如 GET /x/{y} 和 POST /x/{y}），则按请求方法精确匹配，不会混淆。
什么时候该放弃原生 ServeMux
遇到以下任一情况，就别硬撑了：
- 需要路径中某一段匹配正则（如
/user/{id:[0-9]+}）→gorilla/mux或httprouter - 要给同一路径绑定多个方法但共用部分逻辑（比如 GET/PUT 共享验证中间件）→ Gin 或
chi - 需子路由嵌套（
/admin/users下统一加权限检查）→chi或gorilla/mux的Subrouter - 依赖 OpenAPI 文档自动生成、结构化错误响应等周边能力 → 框架生态更省心
原生增强只是让“零依赖微服务”这件事变得可行，不是为了取代所有框架。它的优势在二进制体积、审计清晰度和启动开销，劣势在灵活性——这点必须提前认清楚。
