c.Redirect 是 HTTP 重定向（地址栏变化），r.HandleContext 是服务端内部转发（URL 不变）；前者用于 SEO 和用户可见跳转，后者适用于隐藏路径和复用上下文。
c.Redirect 和 r.HandleContext 是 Gin 中实现重定向的两个核心手段，但它们语义和行为完全不同：前者是 HTTP 层真正的重定向（浏览器地址栏会变），后者是服务端内部转发（URL 不变，只是复用路由逻辑）。
用 c.Redirect 做外部或内部 URL 重定向
这是标准的 HTTP 3xx 重定向，客户端收到响应后会发起新请求，地址栏变化，SEO 友好。
常见错误是传错状态码或目标 URL 格式不合法：
-
http.StatusMovedPermanently（301）和http.StatusFound（302）最常用；307/308 要求方法和 body 保持原样，但 Gin 默认不透传 body，慎用 - 目标 URL 必须是完整 URL（含协议），比如
"https://example.com"；写成"/test2"会导致跳转到当前域名根路径下的相对路径，容易误跳到http://localhost:8080/test2（如果当前是http://localhost:8080/somepath，则实际跳去http://localhost:8080/test2，而非预期的同级路径） - 如果目标 URL 含中文或特殊字符，需提前
url.PathEscape或用url.JoinPath拼接，否则可能触发net/http: invalid header field value
示例：
r.GET("/old", func(c *gin.Context) {
c.Redirect(http.StatusFound, "https://new-site.com/path")
})
用 c.Request.URL.Path = "..."; r.HandleContext(c) 做内部转发
这不是 HTTP 重定向，而是让当前请求“假装”访问另一个路由路径，直接复用 Gin 的路由匹配和 handler 执行逻辑。地址栏不变，无额外网络请求，适合权限校验后透传、A/B 测试路由分发等场景。
立即学习“go语言免费学习笔记（深入）”；
关键限制和坑点：
-
c.Request.URL.Path只改路径，不改查询参数（c.Request.URL.RawQuery仍保留），如需清理或替换，得手动操作 - 必须在调用
r.HandleContext(c)前确保目标路径已注册对应 handler，否则会 404 —— Gin 不做路径存在性校验，它只是硬执行 - 中间件不会重新执行（因为不是新请求），所以若目标路由依赖某些中间件（如鉴权、日志），需提前在原始路由里显式调用或统一挂载到组上
- 不能跨路由组直接跳转；若目标路径在
/api/v2/...组下，而当前在/legacy组，r.HandleContext仍能工作，但中间件链可能缺失
示例：
r.GET("/legacy", func(c *gin.Context) {
c.Request.URL.Path = "/api/v2/data"
r.HandleContext(c)
})
r.GET("/api/v2/data", func(c *gin.Context) {
c.JSON(200, gin.H{"ok": true})
})
别把 c.Redirect 当转发，也别把 r.HandleContext 当重定向
两者目的不同，选错会导致行为完全偏离预期：
- 想让用户看到新 URL、支持书签、需要搜索引擎识别新地址 → 必须用
c.Redirect - 想隐藏真实后端路径、避免两次请求开销、保持请求上下文（如
c.MustGet("user")）→ 只能用r.HandleContext - 混用场景（比如登录后跳首页）：先
c.Redirect到/，而不是在登录 handler 里r.HandleContext去执行首页逻辑 —— 否则刷新页面会丢失 session 状态或重复提交
真正容易被忽略的是：Gin 的 r.HandleContext 不会重置请求上下文中的键值对（比如中间件存的 c.Set("trace_id", ...)），但也不会自动继承目标路由绑定的中间件，这个边界得靠人脑对齐。
