Go net/http.Request.PathValue 的路由参数读取与空值边界

路由已经命中，处理器里的用户编号却是空字符串，最容易误判成“请求没有带参数”。在 Go 1.22 及更高版本的标准 net/http.ServeMux 中，命名通配符和 Request.PathValue 是一对使用：模式负责匹配，PathValue 负责按名称取出匹配值。稳妥的做法是先固定模式，再在处理器里读取同名参数，并把“没有这个通配符”和“通配符值本身为空”纳入边界处理。

先把“路由命中”和“参数读空”拆开

一次排查中，处理器打印出的 id= 让人先去查客户端。更快的定位方式是同时记录匹配模式和参数：让 ServeMux.Handler 或测试确认请求确实进入目标处理器，再检查 PathValue 的名称是否与模式中的通配符完全一致。下面的注册方式把参数边界写在路由表里：

mux := http.NewServeMux()
mux.HandleFunc("GET /users/{id}", func(w http.ResponseWriter, r *http.Request) {
    id := r.PathValue("id")
    if id == "" {
        http.Error(w, "missing user id", http.StatusBadRequest)
        return
    }
    fmt.Fprintf(w, "user=%s", id)
})

请求 GET /users/42 时，id 为 42。这里的关键不是把参数从 r.URL.Path 手工切出来，而是让 ServeMux 按路径段完成匹配，再通过同一个名字取值。

空字符串到底说明了什么

PathValue(name) 在请求没有匹配到带该通配符的 ServeMux 模式，或名称不存在时返回空字符串。因此，空值只能作为“当前读取没有得到可用文本”的信号，不能单独证明客户端漏传。实际项目可以按下面的检查顺序缩小范围：

单段参数和剩余路径不要混用

{id} 只匹配一个路径段；下载、对象存储这类场景如果参数可能包含斜杠，应使用末尾通配符：

mux.HandleFunc("GET /files/{path...}", func(w http.ResponseWriter, r *http.Request) {
    path := r.PathValue("path")
    if path == "" {
        http.Error(w, "empty file path", http.StatusBadRequest)
        return
    }
    fmt.Fprintln(w, path)
})

通配符值来自路由匹配，不能把它和查询参数混为一谈。路径中转义段、尾斜杠和清理规则也应由 ServeMux 的匹配语义统一处理；不要再用字符串替换重建一遍路径。

把故障固定在测试和版本边界里

测试至少覆盖正常值、错误参数名和多段路径。若测试代码需要模拟自定义路由器传入的路径参数，可以使用 r.SetPathValue("id", "42")，但要明确它是人为设置请求值，不能证明 ServeMux 实际匹配成功。另一个边界是 Go 版本：ServeMux 的方法匹配、通配符和路径分段语义在 Go 1.22 有明显变化，旧版本项目应先确认运行时和 GODEBUG=httpmuxgo121=1 兼容配置，再决定是否迁移。

常见问题

PathValue 为空时能否直接返回 404？

不一定。若路由已命中但业务参数为空，通常应按参数校验返回 400；只有资源不存在时才适合返回 404。

为什么把 id 改成 ID 后读不到？

通配符名称是字符串键，读取名称必须与模式完全一致。把 {id} 改为读取 "ID" 就会得到空字符串。

第三方路由器能直接使用 PathValue 吗？

不能默认假设可以。PathValue 的标准语义来自 ServeMux；第三方路由器应按自身 API 取值，或显式调用 SetPathValue 建立适配层。