Go http.Request.Pattern 为什么没有匹配到 ServeMux 模式

如果你在 Go 的处理器里读取 r.Pattern，发现它一直是空字符串，先不要把问题归结为路由没有注册。http.Request.Pattern 记录的是 net/http.ServeMux 为当前请求匹配到的注册模式；只有请求确实经过这个分发器并进入匹配的处理器时，它才有机会被填充。直接调用处理器、使用其他路由器，或者只调用 ServeMux.Handler 获取返回值，都可能得到空的 Pattern。

官方资料：https://pkg.go.dev/net/http#Request

判断重点：把“拿到匹配模式”和“把匹配模式写回 Request”分开看。ServeMux.ServeHTTP 负责请求分发并让处理器看到匹配信息；ServeMux.Handler 只返回处理器与模式，不会修改传入的请求对象。

先确认 Pattern 的职责边界

Pattern 不是所有 Go 路由框架都必须维护的通用字段。它描述的是当前请求被 ServeMux 匹配到的模式，例如 GET /users/{id}。它的用途更接近访问日志、路由观测和处理器内的调试信息，而不是用来重新执行一次路由匹配。

因此，下面三种情况不能混为一谈：

最常见的误判：处理器根本没有经过 ServeMux

测试处理器时，很多代码会直接构造一个请求，然后调用处理器。这样可以验证业务逻辑，但它绕过了 ServeMux 的模式选择，自然不会获得由 ServeMux 分发阶段提供的匹配信息。自定义路由器也一样：它可能有自己的路由上下文，却不会自动写入标准库的 Request.Pattern。

package main

import (
    "fmt"
    "net/http"
)

func userHandler(w http.ResponseWriter, r *http.Request) {
    // 只有请求经过 ServeMux 分发后，这里才适合读取匹配模式。
    fmt.Fprintf(w, "pattern=%q id=%q", r.Pattern, r.PathValue("id"))
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("GET /users/{id}", userHandler)

    // 把 mux 作为服务器 Handler，才能让 ServeMux 参与请求分发。
    _ = http.ListenAndServe(":8080", mux)
}

这段代码里，ServeMux 才是服务器入口。它根据方法和路径选择注册的模式，再把请求交给 userHandler。如果把 userHandler 单独传给服务器，或者在测试中直接调用它，业务函数仍然能执行，但 Pattern 不能再被当成已完成路由匹配的证据。

为什么 ServeMux.Handler 返回了模式，Request.Pattern 还是空

ServeMux.Handler 的返回值和 ServeHTTP 的职责不同。前者适合在分发前询问“这个请求应该交给哪个处理器、对应哪个注册模式”；后者才是把请求交给选中的处理器执行。调用 Handler 并不会替你改写传入的 Request。

import "fmt"

func inspectRoute(mux *http.ServeMux, r *http.Request) {
    // Handler 返回分发决策，pattern 是这次查询得到的模式文本。
    handler, pattern := mux.Handler(r)
    _ = handler
    fmt.Printf("pattern=%q request.Pattern=%q\n", pattern, r.Pattern)

    // Handler 不负责填充命名通配符，PathValue 仍应在真正分发的请求中观察。
    fmt.Printf("id=%q\n", r.PathValue("id"))
}

如果你的目标是在中间件或分发前记录路由，直接保存返回的 pattern 更清楚；如果目标是在业务处理器里记录当前请求对应的模式，就让请求经过 ServeMux.ServeHTTP，再读取 r.Pattern。不要把这两个观测位置的变量互相替代。

空值还可能来自未命中和非标准入口

官方文档对 Pattern 的描述包含一个重要边界：如果请求没有和一个模式完成匹配，它可以保持为空。排查时不要只看注册代码，还要确认请求的入口和匹配条件：

• 服务器的 Handler 是否确实是目标 ServeMux，而不是另一个处理器或第三方路由器。
• 请求方法、主机和路径是否符合注册模式；Go 1.22 之后 ServeMux 的模式语义也发生过变化。
• 是否在重定向处理、测试辅助函数或自定义分发逻辑中直接调用了处理器。
• 是否把 mux.Handler(r) 的返回模式误认为会自动写回 r.Pattern。
• 如果请求没有被注册模式接收，先记录入口、方法、Host 和 URL.Path，再判断是否真的需要 Pattern。

把路由信息记录在正确的位置

如果日志只需要知道最终进入哪个标准库处理器，处理器内读取 r.Pattern 就够了；如果日志、鉴权或指标逻辑发生在分发前，则应该把 mux.Handler(r) 的返回结果作为显式数据向后传递。这样做能避免用一个可能为空的请求字段推断整个路由系统的行为。

更稳妥的代码通常会把“路由决策”与“业务执行”分成两个字段：路由决策来自 pattern 返回值，处理器内上下文来自 r.Pattern。两者都为空时，再回头确认请求是否经过目标 ServeMux，而不是立刻修改注册模式。

最后用五项清单定位问题

1. 确认服务器入口的 Handler 是哪个对象。
2. 确认请求是否经过 ServeMux.ServeHTTP，而不是直接调用业务处理器。
3. 确认模式的 method、host、path 与实际请求条件一致。
4. 若使用 mux.Handler，读取并保存它返回的 pattern，不要等待 r.Pattern 被副作用填充。
5. 把 Pattern 为空解释为“当前请求对象没有获得 ServeMux 匹配记录”，不要直接解释为“路由注册失败”。

一句话总结：http.Request.Pattern 是 ServeMux 分发上下文里的记录字段，不是自动完成路由查询的 API。请求经过正确的 ServeMux 入口时在处理器内读取它；需要提前判断路由时，直接使用 ServeMux.Handler 的返回模式。

相关问题

• 为什么 Request.PathValue 也是空字符串？ 先确认请求经过 ServeMux 的实际分发；只调用 ServeMux.Handler 不会替你填充命名路径变量。
• 自定义路由器能直接使用 Request.Pattern 吗？ 不能假定可以。自定义路由器应使用自身的上下文，或在业务约定中显式传递路由模式。
• ServeMux.Handler 适合放在哪里？ 它适合分发前的观测、日志或策略判断；处理器内部则读取当前请求已经获得的字段。