Gin 的 Redirect 方法仅支持 301 和 302，因源码硬编码校验其余状态码会 panic；需手动调用 c.Status()、c.Header("Location") 和 c.Writer.Write([]byte("")) 实现 307/308 重定向，并立即 return 防止覆盖。
Gin 默认的 Redirect 方法只支持 301 和 302，想用 307、308 或其他自定义重定向状态码，必须绕过封装直接操作响应头和状态码。
为什么 c.Redirect() 不能设任意状态码
Gin 的 Redirect 方法内部做了硬编码校验：只允许 http.StatusMovedPermanently（301）和 http.StatusFound（302），其余值会 panic 报错 "invalid redirect status code"。这不是 bug，是设计限制。
- 源码位置在
gin/context.go的Redirect方法里有明确判断 - 它还会自动补全 Location 头，但状态码部分不开放自定义入口
- 想用 307（临时重定向，保留方法/主体）或 308（永久重定向，保留方法/主体），必须手动写
手动设置重定向：三步写法
用 c.Status() + c.Header() + c.Writer.Write() 组合实现，绕过 Redirect 封装。
-
c.Status(307)：先设置响应状态码 -
c.Header("Location", "https://example.com/new")：显式写入 Location 头（注意大小写，Gin 对 Header 名不敏感，但规范要求首字母大写） -
c.Writer.Write([]byte(""))：必须触发写入，否则某些中间件（如 Recovery）可能拦截或覆盖响应；空字节即可，不用写 body
示例：
c.Status(308)
c.Header("Location", "/api/v2/users")
c.Writer.Write([]byte(""))
307 和 308 的实际行为差异
浏览器和客户端对这两个状态码的处理逻辑不同，选错会导致 POST 请求被转成 GET，或缓存异常。
-
307 Temporary Redirect：临时跳转，要求客户端**严格保留原始请求方法和 body**（比如 POST 带 JSON 不变） -
308 Permanent Redirect：永久跳转，同样保留方法和 body，且会被浏览器缓存，后续相同请求可能直接跳转，不再发原请求 - 别用 301/302 替代——它们会把 POST 强制转成 GET，丢失 body
- Nginx 或 CDN 如果介入，需确认是否透传 307/308（旧版本可能降级为 302）
中间件中重定向容易被覆盖
如果在自定义中间件里调用上述手动重定向，但后续 handler 还执行了 c.Next() 或又写了响应，会导致 HTTP 状态码冲突或 header 被覆盖。
- 务必在重定向后立即 return，避免继续执行后续逻辑
- 不要在
c.Next()之后写重定向逻辑 - 若用
c.Abort()，它不会终止已写入的状态码和 header，但能阻止后续 handler 执行——建议重定向后紧跟return
安全写法：
if needRedirect {
c.Status(307)
c.Header("Location", "/new-path")
c.Writer.Write([]byte(""))
return // 必须 return，不然可能被后续逻辑污染
}
真正麻烦的不是怎么写这三行，而是记住：每次用 307/308，都要检查客户端是否真按语义执行，以及链路中是否有代理悄悄改了状态码。
