301/302重定向会将POST转为GET，导致表单数据丢失和API失败；应改用307（临时）或308（永久）重定向以严格保留请求方法和body。
会，而且影响很直接——特别是对 POST、PUT 等非 GET 类 API 请求。
301/302 重定向会把 POST 变成 GET
HTTP 协议规定：浏览器收到 301 或 302 响应后，必须将后续请求转为 GET 方法，并丢弃原始请求体（body）。这意味着：
- 用户提交的登录表单（POST /login）被 301 跳转后，第二次请求变成 GET /login，后端收不到用户名密码；
- API 接口返回 400 或 405（Method Not Allowed），Network 面板能看到“POST → 301 → GET”两步；
- 这类问题在线上常表现为“接口突然不可用”，但只发生在 HTTP 入口，HTTPS 直连则正常。
不是所有重定向都这样，选对状态码很关键
想保留原始请求方法，就不能用 301/302：
- 307 Temporary Redirect：临时跳转，严格保留方法和 body，适合调试或过渡期；
- 308 Permanent Redirect：永久跳转，同样保留方法，是 301 的安全替代；
- Nginx 示例：
return 308 https://$host$request_uri;（别写 301）； - 注意：307/308 不会被浏览器长期缓存，更适合 API 场景。
重定向还可能间接破坏 Cookie 和会话
即使请求没丢，协议切换也可能让身份凭证失效：
- 后端设了
SecureCookie，但用户从 HTTP 进来，浏览器可能拒绝写入； - 重定向跨子域（如 api.example.com → www.example.com），若 Cookie 的
Domain写死为前者，新页面就拿不到； -
SameSite=Lax在重定向后的首屏加载中不发送 Cookie，导致登录态丢失。
更隐蔽的问题：反向代理 + 重定向组合出错
当 Nginx 作为 HTTPS 终结点，后端是 HTTP 服务时，容易产生错误跳转：
- 后端应用（如 Spring Boot）看到的是 Nginx 转发来的 HTTP 请求，若未识别
X-Forwarded-Proto: https，生成的重定向 URL 就是http://...； - Nginx 默认开启
port_in_redirect on，可能把内部端口（如 :8080）暴露到 Location 头里； - 修复方式：加
proxy_set_header X-Forwarded-Proto $scheme;，并设port_in_redirect off;。
