Go 的 http.Redirect 默认是 302（临时重定向），非 301；真要永久跳转须显式传 http.StatusMovedPermanently，否则影响 SEO、缓存及浏览器行为。
Go 的 http.Redirect 默认是 302，不是 301
很多人写完 http.Redirect(w, r, "/new-path", http.StatusFound) 就以为自己在做“永久跳转”，其实不是。http.StatusFound 是 302 的别名，语义是“临时重定向”。搜索引擎不会更新索引，浏览器也不会缓存这个跳转。真要 301，必须显式传 http.StatusMovedPermanently —— 这个常量值是 301，但名字长，容易漏看。
常见错误现象：
• 改了 URL 后用 302 跳转，SEO 排名没迁移
• 用户刷新页面时反复重定向（302 不被缓存，每次走服务端）
• 浏览器地址栏显示新路径，但后退按钮失效或行为异常（和中间代理、缓存策略有关）
- 301：适合域名变更、路径永久下线、SEO 迁移场景
- 302：适合登录跳转、A/B 测试分流、表单提交后防重复提交（POST-Redirect-GET）
- 别用
http.StatusTemporaryRedirect（307）代替 302，它会保留原始请求方法（比如 POST 不变），多数前端不预期这个行为
重定向时 r.URL 和 req.URL 容易混淆
在 handler 里调用 http.Redirect 之前，如果手动拼接跳转目标，常有人直接用 r.URL.Path 做基础路径，比如："https://example.com" + r.URL.Path。这会出问题：当请求带 query 参数（如 /old?x=1），r.URL.Path 不含 query，导致参数丢失；更糟的是，如果用了反向代理（Nginx、Cloudflare），r.URL.Host 可能是内网地址（如 localhost:8080），直接拼出来就跳错地方。
正确做法是用 r.Referer() 或明确配置的 base URL，但最稳妥的是从 r.Header.Get("X-Forwarded-Proto") 和 r.Header.Get("X-Forwarded-Host") 构建完整目标 URL，或者干脆用相对路径（如 "/new"）让浏览器自己补全协议和 host。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 绝对 URL 必须带协议（
https://），否则浏览器按相对路径解析，可能变成http://current-host/new - 如果服务跑在子路径（如
/app/），r.URL.Path是带前缀的，硬切字符串极易出错，建议用strings.TrimPrefix(r.URL.Path, "/old")这类明确操作 - 调试时打印
r.Header看实际转发头，别假设 Nginx 一定传了X-Forwarded-*
301 重定向后，本地开发环境容易卡在浏览器缓存里
Chrome 和 Safari 对 301 缓存非常激进。你本地改了代码，把 301 换成 302，浏览器可能还在用旧的 301 缓存跳转，根本不发请求到你的 Go 服务。这时候看日志没记录、curl 却正常，就是这个原因。
解决办法不是重启浏览器，而是针对性清理：
• Chrome 地址栏输入 chrome://net-internals/#hsts，删掉对应域名的 HSTS 记录（301 有时触发 HSTS 预加载）
• 或者用隐身窗口测试
• 更快的是在开发时强制用 302，上线前再切 301
- Firefox 缓存略宽松，但仍有类似问题，可用
about:networking#httpcache清理 - 用 curl 测试时加
-v看真实响应头：curl -v http://localhost:8080/old，确认Location和Status字段是否符合预期 - Docker 或 k8s 环境里，如果 Ingress 层（如 Nginx Ingress）也配了重定向，Go 应用的 301 可能被覆盖或叠加，得查两层日志
自定义重定向函数要小心 w.Header().Set 和 w.WriteHeader 冲突
有人想封装一个带日志的 redirect 函数，手写 w.Header().Set("Location", url) + w.WriteHeader(status)，结果返回空响应体或状态码错乱。这是因为 http.Redirect 内部已经调用了 WriteHeader 和 Write，而 Go 的 ResponseWriter 不允许多次 WriteHeader —— 第二次会被忽略，且可能触发 panic（取决于底层实现）。
所以别自己造轮子拼 header。真要加日志或埋点，包一层 http.Redirect 即可：
func loggedRedirect(w http.ResponseWriter, r *http.Request, url string, status int) {
log.Printf("redirect %d %s -> %s", status, r.URL.Path, url)
http.Redirect(w, r, url, status)
}
- 不要在调用
http.Redirect前写任何w.Write或w.WriteHeader - 如果用了中间件（如 auth、gzip），确保 redirect 发生在中间件链的“写响应”阶段之前，否则 gzip 中间件可能已锁住 writer
- status 必须是 3xx 系列整数，传 200 或 404 不会报错，但浏览器行为未定义，有些会静默忽略 Location 头
301 和 302 的根本区别不在 Go 代码里，而在客户端怎么理解、怎么缓存、搜索引擎怎么索引。写代码只是起点，上线后得盯日志、抓包、查搜索控制台，不然重定向就只是表面上跳过去了。
