一个Servlet准备好数据后交给JSP展示，和服务器告诉浏览器“去另一个地址”，看起来都能换一张页面，但它们改变的是不同层次。
forward在容器内继续处理当前请求；redirect先返回HTTP响应，再由客户端决定是否跟随目标地址。下面讨论Servlet同步处理和浏览器的页面导航。
图是机制示意。一次转发不额外产生浏览器请求；一次被跟随的重定向会产生后续请求，重定向链还可能继续跳转。
Forward保留请求上下文，但不是“原封不动”
Controller已经查询到数据，想让JSP负责展示，可以把展示数据放进请求属性，再转发：
request.setAttribute("message", "参数校验未通过，请检查输入"); request.getRequestDispatcher("/WEB-INF/views/result.jsp") .forward(request, response); return;这里/WEB-INF/views/result.jsp是应用内的资源路径。它不是让浏览器发起第二个HTTP请求，也不是服务端用HTTP客户端访问这个地址。浏览器地址栏仍保留最初导航的URL，JSP可以从当前请求读取message。
不过，转发不等于请求对象所有字段都保持原样。Jakarta Servlet的RequestDispatcher文档说明，目标资源对应的请求路径元素和参数会相应调整。容器也允许规范规定的请求、响应包装对象。
排查日志里“地址怎么变了”时，要区分三样东西：
- 浏览器地址栏里的原始导航地址。
- 目标资源当前看到的请求路径。
- 容器通过
RequestDispatcher.FORWARD_REQUEST_URI等属性保留的原始路径信息。
目标资源还可以检查request.getDispatcherType()，这次分派的类型是FORWARD。这些信息比“服务器偷偷换页”更能解释实际行为。
Redirect跨过了一次响应边界
例如，未登录用户需要去登录页：
response.sendRedirect(request.getContextPath() + "/login"); return;单参数sendRedirect默认发出302响应，并通过Location提供目标。浏览器跟随后续导航时，会为目标地址创建新的请求。第一次请求中的request.setAttribute(...)不会因此自动出现在第二次请求里；需要跨请求保留的数据，应通过资源标识、会话或框架提供的短期消息机制明确传递。
“重定向”也不等于“把请求改为GET”。POST后读取结果适合303；307和308要求保留原请求方法和请求体。状态码应该按期望的后续行为选择。HttpServletResponse API、HTTP重定向语义
如果请求来自fetch，跟随重定向不等于整个页面发生导航，地址栏也不会因为这次接口请求自动切换。这里的“地址栏改变”指浏览器正在跟随文档导航。
选哪一个，看请求接下来该做什么
| 需要的行为 | 选择与原因 |
|---|---|
| 同一次请求中，把准备好的数据交给视图渲染 | forward，请求属性可以继续使用 |
| 表单校验失败，直接展示这次输入对应的错误 | 可以forward，具体也可由框架直接渲染响应 |
| 成功完成POST后，让用户进入独立的结果页 | 采用POST→303→GET；不要用forward代替结果页导航 |
| 用户应看到并停留在另一个文档地址 | redirect，客户端跟随后续地址 |
| 请求任意外部服务并加工它的返回数据 | 这属于HTTP客户端调用，不是RequestDispatcher的职责 |
forward少一次客户端重定向往返，但不能因此给出“所有场景性能都更高”的结论。请求生命周期、结果地址和数据传递方式，通常比这一次往返更先决定方案。
两个容易在代码里踩到的点
响应已经提交后，不能再转发。如果响应内容已经刷新给客户端，forward会抛出IllegalStateException；还没提交的响应缓冲会在转发前清除。不要先输出一段页面，再指望转发补救。RequestDispatcher.forward
调用转发或重定向，不会替Java方法执行return。示例里的return用于结束当前处理分支，避免后面的业务逻辑继续运行或继续写响应。
验证时，在Network里只观察文档请求：转发对应的仍是原始请求；重定向应能看到3xx响应及后续地址。同时在目标资源核对请求属性和分派类型，别只凭页面外观判断。
POST成功后的刷新问题，见PRG的作用与边界。
修订于2026年11月1日：移除对话比喻，补请求路径、状态码、响应提交和客户端导航的适用条件。
