302重定向面试题避坑：这些错误你可能每天都在犯

302 重定向面试题避坑：这些错误你可能每天都在犯

面试高频考点：302 临时重定向，很多开发只懂 “浏览器跳转”，但缓存、请求方法、Cookie、反向代理、SEO、接口幂等这些坑，开发写业务时经常踩，也是面试官最爱深挖的点。

一、基础概念(面试开篇必背)

302 Found：临时重定向。资源临时迁移到新 URL，不建议浏览器缓存这个跳转规则;下次请求仍然访问旧地址。

区分对比(面试必问)

301 Moved Permanently：永久重定向。资源永久迁移，浏览器会缓存跳转，后续直接访问新地址。

307 Temporary Redirect：临时重定向，保留原请求 Method(POST 依然是 POST，不会自动变成 GET)。

308 Permanent Redirect：永久重定向，保留原请求 Method。

✅ 一句话核心区别： 302 在很多浏览器实现上，POST 请求重定向后会自动转为 GET 请求，丢失 body!这是最大坑。

二、面试官高频提问 + 日常开发踩坑点

坑 1：POST 请求返回 302，Body 丢失(最高频面试题)

场景：提交表单 POST /login，校验成功返回 302 跳转到首页。现象：浏览器收到 302 后，发起 GET 请求访问目标地址，原来 POST 的请求体直接丢掉。

问题：如果你后端以为重定向后还是 POST，读取 body / 表单参数，直接拿不到数据。

✅ 解决方案：

POST 场景需要保留请求方法：不要用 302，改用 307

业务最佳实践：POST 接口不要直接 302 跳转;推荐：POST 返回 200，前端 JS 做页面跳转。

面试原话：302 规范本身没有强制修改 method，但主流浏览器历史实现会把 POST 转 GET，这是遗留兼容行为，生产非常危险。

坑 2：混淆 302 和 301，错误缓存重定向规则

很多人写：临时活动页面跳转用 301，结果浏览器永久缓存。现象：活动下线改回原页面，用户浏览器依然自动跳旧活动地址，清缓存才能恢复。

✅ 临时跳转(活动、临时维护、A/B 测试)：302

✅ 永久地址变更(域名迁移、旧接口下线)：301

注意：302 只是语义上不建议缓存，在有 Cache-Control 头的时候，浏览器依然可以缓存 302 响应!不是绝对不缓存。

坑 3：反向代理 / Nginx 配置 302，域名 / 端口错乱(后端开发常踩)

场景：Nginx 反向代理，后端服务返回 302 跳转，Location 头写的是内网地址 http://127.0.0.1:8080/home 浏览器拿到这个内网地址，直接跳转，访问失败。

原因：后端直接拼接内部地址生成 Location，没有感知前端访问域名。 两种修复方案：

后端读取 X-Forwarded-Proto / X-Forwarded-Host，拼接对外域名生成跳转地址(推荐)

Nginx 修改响应头，重写 Location：

proxy_redirect http://127.0.0.1:8080/ https://www.xxx.com/;

面试常问：反向代理场景下 302 跳转异常，你怎么排查?优先看响应头Location的值。

坑 4：Cookie 丢失 / 跨域跳转 Cookie 无法携带

场景：A 域名 302 跳转到 B 域名

跨域跳转时，Cookie 默认不会自动带到新域名

即使同域名，如果 Cookie 的Path、Domain属性配置不当，跳转后 Cookie 丢失。

典型业务：登录接口 302 跳转，登录 Cookie 写在旧路径，跳转后 Cookie 失效，用户还是未登录。

排查：F12 看 Network，跳转后的请求有没有带上 Set-Cookie、Cookie 请求头。

坑 5：无限重定向死循环

场景 A：/a 302 → /b;/b 302 → /a 场景 B：Nginx HTTPS 跳转写错，https://xxx 继续跳 https，循环。浏览器会直接报错：重定向次数过多。排查：抓包看完整请求链路，看每一步 Location。

坑 6：接口测试工具和浏览器行为不一致

Postman/Curl 和浏览器对 302 自动跳转行为不一样：

curl 默认不会自动跟随 302，需要加参数 -L

浏览器默认自动跟随跳转链，最多最多跟随 5~10 次。

开发自测的时候，curl 没加 - L，以为接口没跳转，上线浏览器正常，测试环境表现不一致。

# curl跟随重定向

curl -L https://xxx.com/old

坑 7：302 和业务幂等性

GET 请求天然幂等;POST + 302 跳转后变成 GET，不再具备幂等保护。如果业务逻辑依赖 POST 防重复提交，302 跳转后会破坏这个逻辑。

坑 8：SEO 问题(前端 / 全栈面试附加题)

302 临时跳转：搜索引擎爬虫理解为临时迁移，不会把旧页面权重传递给新页面。网站永久换地址，用 302 会导致 SEO 权重丢失，应该用 301。

三、302、301、307、308 对比速查表(面试背诵版)

表格

状态码含义请求 Method 变化缓存

301永久重定向POST→GET浏览器缓存跳转

302临时重定向POST→GET(浏览器历史行为)默认不缓存(可被 Cache-Control 控制)

307临时重定向保持原 Method不缓存

308永久重定向保持原 Method缓存跳转

面试一句话总结：只要是 POST 请求需要重定向，优先 307，严禁 302。

四、面试经典问答模拟

Q1：302 和 307 的区别?什么时候用 307?

A：302 是临时重定向，浏览器遇到 POST 请求跳转时会转为 GET，丢失 body;307 同样临时重定向，但严格保留原始请求方法。POST 提交场景如果必须服务端跳转，使用 307。页面普通 GET 跳转，302 没问题。

Q2：Nginx 反向代理后端返回 302，跳转地址变成内网 IP 怎么解决?

A：原因是后端生成 Location 时使用了后端自身内网地址。方案：①后端读取代理透传的X-Forwarded-Host、X-Forwarded-Proto，拼接对外域名;②Nginx 配置 proxy_redirect 重写 Location 响应头。

Q3：302 会不会被浏览器缓存?

A：规范定义 302 代表临时资源移动，不建议缓存跳转，但不是强制禁止。如果响应携带 Cache-Control，浏览器依然会缓存 302。永久迁移必须用 301。

Q4：业务登录接口 POST 提交，登录成功返回 302 跳首页，有什么隐患?

A：存在风险。POST 收到 302 后浏览器会改用 GET 请求访问首页，POST 请求体丢失。虽然登录动作已经在上一次 POST 完成，本次跳转只是页面跳转，业务上有时能跑通，但属于不规范写法。如果后续业务改造，很容易引发 bug。更规范方案是 POST 返回 200，前端 JS 跳转。

五、开发编码规范总结(避坑清单)

GET 页面跳转：302 ✔️

POST 接口需要服务端重定向：307 ✔️，禁止 302

永久域名 / 地址迁移：301 ✔️

POST 接口尽量避免服务端跳转，优先前端 JS 跳转

反向代理环境，后端生成跳转地址，必须读取X-Forwarded-Host

上线前抓包检查 Location 响应头，确认域名、协议正确

重定向逻辑做好防死循环校验

六、快速排错步骤

F12 看 Network，查看状态码和Location响应头

检查是否跨域跳转，Cookie 是否正常携带

curl -L 命令复现，确认跳转链路

反向代理场景：检查 proxy_set_header 是否传递 Host、X-Forwarded 系列头

排查是否循环跳转