Go HTTP 路由如何把 /v1/users 自动转给 /v2/users？
直接用 http.Redirect 会暴露重定向，客户端看到 301/302，破坏 API 的“平滑”前提；真正要的是服务端内部转发，让 v1 请求静默走到 v2 处理逻辑，路径、参数、Body 全保留。
推荐做法是用中间件 + 路由前缀重写，而不是改 handler 函数体。比如用 gorilla/mux 或 chi 时，在注册 v1 路由前插入一层映射：
router.HandleFunc("/v1/{path:.*}", func(w http.ResponseWriter, r *http.Request) {
// 把 /v1/users?id=1 → /v2/users?id=1
newPath := "/v2" + r.URL.Path[3:] // 硬切掉 "/v1"
r.URL.Path = newPath
r.RequestURI = newPath + r.URL.RawQuery // 否则 net/http 会忽略 Query
r.Header.Set("X-API-Version", "v1") // 可选：透传原始版本标识
// 再交给 v2 handler 处理（需确保 v2 路由已注册）
v2Router.ServeHTTP(w, r)
})
- 别用
r.URL.Path = strings.Replace(r.URL.Path, "/v1", "/v2", 1)—— 没处理嵌套路径如/v1/v1/users，硬切更稳 -
r.RequestURI必须同步更新，否则net/http内部解析会出错，导致r.URL.Query()为空或参数丢失 - 这个中间件必须在所有
v1路由注册前挂载，否则会被具体路由提前匹配并终止
用 chi 实现 v1 到 v2 的路径映射时，Mount 和 With 哪个更合适？
chi 的 Mount 是路径前缀绑定，本质是子路由；With 是中间件链。平滑迁移场景下，Mount 更直接，但容易踩坑。
正确姿势是用 Mount("/v1", v2Router)，把整个 v2 路由树挂到 /v1 下——前提是 v2Router 的 handler 不依赖原始路径前缀（即它自己定义的是 /users，不是 /v2/users）：
立即学习“go语言免费学习笔记（深入）”；
func buildV2Router() http.Handler {
r := chi.NewRouter()
r.Get("/users", usersHandler) // 注意：这里没写 /v2
return r
}
mainRouter.Mount("/v1", buildV2Router()) // ✅ 请求 /v1/users → 进入 usersHandler
- 如果
v2Router里写的路径是/v2/users，那Mount("/v1", v2Router)就变成匹配/v1/v2/users，明显不对 -
With适合加日志、鉴权等通用中间件，不适合做路径重映射——它不改变r.URL.Path，只是串函数调用 - 用
Mount后，v2handler 里r.URL.Path仍是/v1/users，若业务代码里硬编码了路径判断（比如strings.HasPrefix(r.URL.Path, "/v2")），就会失效
net/http 原生路由能否支持多版本映射？
能，但非常受限。原生 http.ServeMux 不支持通配、正则或中间件，只能靠手动匹配前缀 + http.StripPrefix，且仅适用于静态路径前缀场景。
例如只映射 /v1/users 到 /v2/users，可以用：
func v1ToV2Handler(h http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if strings.HasPrefix(r.URL.Path, "/v1/") {
// 替换前缀，注意保留 query
newPath := "/v2" + r.URL.Path[3:]
r2 := new(http.Request)
*r2 = *r
r2.URL = &url.URL{
Path: newPath,
RawQuery: r.URL.RawQuery,
Fragment: r.URL.Fragment,
}
h.ServeHTTP(w, r2)
return
}
http.NotFound(w, r)
})
}
mux := http.NewServeMux()
mux.Handle("/v2/", v1ToV2Handler(v2Handler)) // 注意：这里注册的是 /v2/，但实际接收 /v1/ 请求
-
http.StripPrefix不能用在跨版本映射上——它只改r.URL.Path，不改r.RequestURI，query 会丢 - 原生 mux 无法区分
/v1/users/123和/v1/users，必须手写字符串判断，维护成本高 - 一旦有 POST/PUT 请求带 body，上面示例没复制
Body和Header，会导致数据丢失——得手动ioutil.ReadAll再重设，性能差
为什么有些团队在迁移中突然发现 Content-Type 变成 text/plain？
因为重定向或转发时没透传 header，尤其是 Content-Type 和 Accept。Go 的 http.RoundTrip 或自定义转发常忽略这一点，而 v2 handler 可能依赖 Content-Type 做 JSON 解析判断。
- 转发请求前，必须显式复制关键 header：
r2.Header.Set("Content-Type", r.Header.Get("Content-Type")) -
Accept同理，否则v2返回的格式可能和客户端预期不符（比如客户端要application/json，但返回了text/html） - 某些中间件（如 gzip 压缩）会修改
Content-Encoding，转发时若没清除，v2handler 可能尝试解压已解压过的 body - 最稳妥的做法是：转发前清空
r2.Header，再逐个 set 必需字段，避免意外继承
路径映射本身不难，难的是 header、body、query、context 之间的隐式耦合。一个没 copy 的 Header，就可能让下游服务返回 415 或乱码响应。
