go 的 http.servemux 不能直接做 url 重写，因其仅支持字面路径前缀匹配，不支持正则、捕获组或路径改写；真正重写需在服务端内部修改 req.url.path 和 rawpath 后交由后续 handler 处理。
Go 的 http.ServeMux 为什么不能直接做 URL 重写
它只支持前缀匹配和注册固定路径，没有正则、捕获组或重写规则的概念。你注册 /api/v1/users，它就只认这个字面路径；想把 /v1/users 自动转成 /api/v1/users？原生 http.ServeMux 做不到。
常见错误现象：用 http.Redirect 模拟“重写”，结果浏览器地址栏跳变、方法丢失（POST 变 GET）、状态码不对（默认 302）——这不是重写，是重定向。
- 真正 URL 重写必须在服务器内部完成：请求路径被修改后，再交由后续 handler 处理，客户端无感知
- Go 标准库不提供重写中间件，得自己构造或借助第三方
- 别试图 patch
req.URL.Path后再调用handler.ServeHTTP—— 如果 handler 内部又读了req.URL或用了http.StripPrefix，行为可能不一致
用 http.StripPrefix + 自定义 handler 实现路径前缀重写
这是最轻量、无依赖的方案，适合“/old → /new”类简单映射，本质是改写 req.URL.Path 后转发。
使用场景：静态资源目录映射（/static/xxx → ./public/xxx），或统一 API 前缀剥离（/api/v1/… → 转给 v1 handler）。
立即学习“go语言免费学习笔记（深入）”；
-
http.StripPrefix只删前缀，不重定向，也不改 method 或 body - 它返回一个新 handler，但不会自动处理子路径匹配逻辑，你得确保后续 handler 能响应 stripped 后的路径
- 注意 trailing slash：若注册
/api/，StripPrefix 会去掉末尾斜杠，但/api（无斜杠）不会被匹配
http.Handle("/api/", http.StripPrefix("/api/", apiV1Handler))
用 net/http 中间件模式实现带条件的重写
当需要正则匹配、路径参数提取、或按 Host/User-Agent 等条件重写时，就得手写中间件。核心是修改 req.URL.Path 和 req.URL.RawPath（后者影响编码字符）。
容易踩的坑：
- 只改
req.URL.Path不改req.URL.RawPath，遇到含空格、中文的路径，后续http.ServeFile或路由库可能解码失败 - 重写后没调用
req.URL.Opaque = ""，某些 handler（如http.FileServer）会误用 Opaque 字段跳过 Path 解析 - 重写逻辑放在 handler 最外层，避免被其他中间件（如日志、CORS）提前消费了原始路径
func rewriteMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if strings.HasPrefix(r.URL.Path, "/v1/") {
r.URL.Path = "/api" + r.URL.Path
r.URL.RawPath = ""
r.URL.Opaque = ""
}
next.ServeHTTP(w, r)
})
}
用 gorilla/mux 的 Redirect 和 Subrouter 混合处理重定向与重写
gorilla/mux 本身也不支持服务端重写，但它能清晰区分“重定向”（3xx）和“内部转发”（重写）。很多人混淆这两者，导致 SEO 或 API 兼容性出问题。
性能提示：重定向会多一次 HTTP 往返；重写是纯内存操作，延迟几乎为零。
- 用
router.Redirect做 301/302 跳转（比如旧文档链接迁移），浏览器地址栏会变 - 用
router.PathPrefix+Subrouter做前缀接管，再配合自定义 handler 改写路径，实现真重写 - 别在
Subrouter里注册HandleFunc("/", …)期望匹配所有子路径——它只匹配字面 “/”，要用HandleFunc("/{rest:.*}", …)捕获剩余路径
复杂点在于：重写规则越多，越容易和静态文件服务、API 版本路由、反向代理逻辑冲突。建议把重写逻辑收敛到最外层中间件，统一决策，别分散在各 subrouter 里。
