Go http.Request.Pattern 在处理器里怎么用：路由模式读取与兼容判断

用 Go 的新路由模式写接口时，日志里常常还要回答一个问题：这次请求到底命中了哪条规则？在服务端处理器中读取 r.Pattern 就能拿到 ServeMux 的匹配模式，而 r.PathValue("id") 负责取出通配符的具体值。两者一个描述“规则”，一个描述“数据”，不要混在一起。

如果你只想记录命中的路由模板，用 Request.Pattern；如果要拿订单号、用户号这类动态片段，用 PathValue。它们都依赖请求确实经过支持方法和通配符的 ServeMux。

先把实验环境固定在 Go 1.22 以上

Request.Pattern 与方法模式、路径 wildcard 一起使用时，需要 Go 1.22 引入的增强 ServeMux。先检查本机工具链：

go version
go env GOMOD

示例不依赖第三方路由包。新建目录并初始化模块：

mkdir request-pattern-lab
cd request-pattern-lab
go mod init example.com/request-pattern-lab

如果项目必须兼容更早版本，先不要直接复制下面的路由写法；应保留旧的静态路径或使用项目已有路由器，并把兼容判断放在升级计划里。

先让 ServeMux 写入 Pattern

下面的处理器只做一件事：把模式和值写进响应。真正的匹配动作由 ServeMux 完成，所以日志中可以把 Request.Pattern 当作稳定的路由模板。

package main

import (
    "fmt"
    "net/http"
)

func orderHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "pattern=%s id=%s", r.Pattern, r.PathValue("id"))
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("GET /orders/{id}", orderHandler)
    http.ListenAndServe(":8080", mux)
}

这段代码的调用链是 ServeMux 匹配 GET /orders/{id}，再进入 Handler。访问 /orders/42 时，响应应包含 pattern=GET /orders/{id} 和 id=42，而不是把真实数字拼进 Pattern。

Pattern 和 PathValue 解决的是两件事

给日志、指标或权限规则使用时，优先记录模板；给业务查询使用时，再取动态值：

func orderHandler(w http.ResponseWriter, r *http.Request) {
    pattern := r.Pattern
    orderID := r.PathValue("id")
    if pattern == "" || orderID == "" {
        http.Error(w, "route data missing", http.StatusBadRequest)
        return
    }
    fmt.Fprintf(w, "route=%s order=%s", pattern, orderID)
}

这里的数据路径很短：Request.Pattern 提供规则文本，PathValue("id") 提供 wildcard 值，最后形成 订单 42 这样的业务输出。把 PathValue("id") 写到指标名里会造成高基数，通常应把它作为日志字段或追踪属性。

用 httptest 核对成功和失败边界

测试时不要只手动构造 http.Request 就断言路由模式，那样请求没有经过 ServeMux。让测试服务器真正接收请求：

func TestOrderRoute(t *testing.T) {
    mux := http.NewServeMux()
    mux.HandleFunc("GET /orders/{id}", orderHandler)

    server := httptest.NewServer(mux)
    defer server.Close()

    resp, err := http.Get(server.URL + "/orders/42")
    if err != nil { t.Fatal(err) }
    defer resp.Body.Close()

    body, _ := io.ReadAll(resp.Body)
    got := string(body)
    if !strings.Contains(got, "GET /orders/{id}") {
        t.Fatalf("pattern missing: %s", got)
    }
    if !strings.Contains(got, "42") {
        t.Fatalf("path value missing: %s", got)
    }
}

成功状态是响应码为 200，响应体同时出现路由模板和 42。再访问一个没有注册的路径，应该得到 404；这时不要期待处理器里出现一个“未命中的 Pattern”，因为处理器根本没有执行。

常见误区与兼容判断

还要留意请求来源：Pattern 是服务端路由匹配结果，不是客户端可以随意提交的字段。不要从请求头读取同名自定义值来替代它，否则日志会混入不可信数据。

延伸问答

Request.Pattern 会包含动态参数的真实值吗？

不会。它应保持为注册时的路由模式，例如 GET /orders/{id}；真实值通过 PathValue("id") 读取。

直接调用 HandlerFunc 时为什么没有 Pattern？

因为没有发生 ServeMux 匹配。测试调用链时要把处理器注册到 mux，再通过测试服务器发请求。

能不能用 Pattern 代替状态码判断？

不能。Pattern 只说明进入了哪条路由，业务成功仍应通过响应码、响应体和具体校验结果判断。

清理实验并保留最小结论

实验完成后可以删除临时的 request-pattern-lab 目录。实际项目里建议把 r.Pattern 用作低基数日志字段，把 PathValue 交给业务校验，并在 CI 中保留一条经过 ServeMux 的 httptest 回归用例。这样升级路由规则时，既能知道命中了什么模板，也不会把动态 ID 当成模板本身。