Go net/http 路径参数提取的路由适配方法

用 Go 标准库写资源路由时，最容易失控的是把方法判断、路径切分、参数转换和状态码都塞进一个字符串处理函数。Go 1.22 以后可以直接写 GET /users/{id}，再用 r.PathValue("id") 取出路径参数。这样路由负责匹配，handler 负责校验和业务结果，边界更清楚。

先把路径参数写进 ServeMux 模式

下面的示例只使用 net/http 和 strconv。{id} 匹配一个路径段，GET 还会按 HTTP 语义匹配 HEAD；如果把路径写成 {path...}，它才会接收后面的多个段。

package main

import (
    "fmt"
    "net/http"
    "strconv"
)

func userHandler(w http.ResponseWriter, r *http.Request) {
    // PathValue 只取路由匹配出的文本，业务边界仍需主动校验。
    idText := r.PathValue("id")
    id, err := strconv.Atoi(idText)
    if err != nil || id 

访问 /users/42 时，handler 读取到的 idText 是 42；访问 /users/abc 会在参数边界返回 400；访问不存在的数字会返回 404。示例中的 ListenAndServe 仅用于展示入口，生产服务还应配置显式的 http.Server 超时。

PathValue 之后要立即做参数边界校验

PathValue 返回字符串，不会替你判断它是不是数字，也不会替你查询资源。把转换放在 handler 开头，后面的代码就可以使用已经收敛过的 int。如果参数还要满足上限，例如用户编号不能超过 1000000，可以在同一处做范围判断，避免把坏输入带进数据库或下游服务。

路径参数为空、编码异常和路由未匹配不是一回事。对于已匹配的 {id}，格式错误通常是 400；合法但不存在的资源是 404；请求方法没有对应 handler 时，ServeMux 会返回 405，并带上可用方法的 Allow 响应头。

用具体路由处理固定路径与动态路径冲突

如果同时注册 GET /users/{id} 和 GET /users/me，固定文本 me 比通配符更具体，应优先匹配固定路由。不要在 handler 里再写一层“如果 id 等于 me”的特殊分支；把特殊资源单独注册，后续扩展 /users/settings 时也更容易读懂。

更换路由入口时保持同一个 handler 契约

如果项目有自定义路由器，可以让它在调用业务 handler 前执行 r.SetPathValue("id", value)，这样业务代码仍然只读取 r.PathValue("id")。这个做法的价值不是把所有路由器变成 ServeMux，而是把“参数名称”固定为 handler 契约，减少迁移时对业务代码的改动。

迁移前应确认三件事：外部路由是否真的只传入一个路径段，参数是否已经完成 URL 解码，缺失参数时是否能明确返回 400。不要为了兼容旧路由继续用 strings.Split 直接取最后一段，否则尾部斜杠、空段和编码字符很容易产生不同结果。

常见问题

Go 1.21 还能直接使用 PathValue 吗？

不能。PathValue、SetPathValue 以及带方法和通配符的 ServeMux 模式属于 Go 1.22 引入的路由能力。旧版本需要保留前缀路由并自行解析路径，或先升级运行时。

为什么参数正确却得到 404？

先检查模式是否写成了完整的 /users/{id}，再检查请求是否多了额外路径段。单段通配符不会匹配 /users/42/profile；需要多段时应使用末尾的 {path...}。

405 和 404 应该怎样区分？

路径能匹配但方法不被允许时是 405；连路径模式都匹配不上时是 404。客户端看到 405 时应检查请求方法，并读取 Allow 头，而不是盲目修改参数。