Go net/http.Request.Pattern 如何记录命中的路由：ServeMux、方法匹配与日志字段

网关日志里只记了 URL，却没有记住请求最终命中了哪条路由。Go 的 net/http 在 ServeMux 完成匹配后，会把模式写入 Request.Pattern；把它和方法、路径一起记录，排查通配符抢占或方法不匹配会直观很多。

把 Request.Pattern 当作 ServeMux 的最终匹配结果记录，而不是自己再用字符串猜路由；没有经过模式匹配的请求，Pattern 会保持为空。

路由匹配和日志记录是两件事

ServeMux 负责把请求交给处理器，Request.Pattern 负责留下匹配证据。处理器里直接记录 req.Method、req.URL.Path 和 req.Pattern，比维护一套重复的路由字符串更不容易漂移。

三个方案怎么取舍

只记录 URL

实现最少，但无法看出同一路径为什么落到不同处理器。

自己维护路由名

适合跨多个路由器的统一业务名，但每次改模式都要同步维护。

记录 Request.Pattern

适合标准 ServeMux：模式由匹配器产生，日志直接使用最终结果。

最小示例：方法和通配符一起验收

mux := http.NewServeMux()
 mux.HandleFunc("GET /users/{id}", func(w http.ResponseWriter, req *http.Request) {
     log.Printf("method=%s path=%s pattern=%s id=%s", req.Method, req.URL.Path, req.Pattern, req.PathValue("id"))
     w.WriteHeader(http.StatusNoContent)
 })
 http.ListenAndServe(":8080", mux)

请求 GET /users/42 时，Pattern 是注册时的 GET /users/{id}，而 PathValue("id") 才是 42。前者用于路由证据，后者用于业务参数。

哪些匹配规则会改变 Pattern

没有方法的模式匹配所有方法，GET 模式也匹配 HEAD；带主机的模式只匹配该主机；带 ... 的通配符会吞掉剩余路径。多个模式同时匹配时，更具体者优先，互相冲突则在注册时暴露问题。

常见误区

• 把 Pattern 当成实际 URL：它可能包含 {id}，真实值要读 PathValue。
• 只按路径猜处理器：方法和主机也参与匹配。
• 把空 Pattern 当成 404：Pattern 只是匹配证据字段。

相关问题

Request.Pattern 什么时候为空？

请求没有经过 ServeMux 模式匹配时为空，例如由其他路由器处理时。

能否用 Pattern 生成链接？

不建议。Pattern 是匹配规则，不是带真实值的 URL。

为什么日志还要记录 URL.Path？

Pattern 说明命中了哪条规则，URL.Path 说明实际请求，两者合起来才能定位选择问题。

收尾检查

上线前用一个精确路径、一个方法不匹配请求和一个通配符请求做验收，确认日志中的 Pattern、PathValue 和状态码分别符合预期。