SpringMVC学的越深越发现，光是“Controller返回一个字符串”这个看似不起眼的小操作，背后牵扯出来的转发、重定向、视图解析器优先级的问题，足够让你掉几层头发。我这次在回顾Spring框架的时候，专门把SpringMVC的页面跳转流程整个翻出来捋了一遍，重点就是标题里说的三件事：直接页面转发、自定义视图、页面重定向。这篇就把我这次重温的完整笔记和踩坑过程记录下来，给同样卡在这一块的同学做个参考。
先说清楚这篇适合谁看。如果你已经会用@RequestMapping写接口，知道return "hello"能跳到一个JSP页面，但对forward:和redirect:前缀的底层区别、为什么有时候自定义View不生效、多个视图解析器谁先执行这类问题比较懵，那这篇就是给你准备的。我会从“为什么要这样设计”讲到“实际代码怎么写”，再放到常见问题里说排查思路，尽量把这块硬骨头啃透彻。
1. 请求出口的三种姿势：转发、重定向和自定义视图，到底怎么选
在SpringMVC里，一个请求从进入DispatcherServlet开始，到最终返回给浏览器内容，中间经历了HandlerMapping找Controller、HandlerAdapter调用业务方法、ViewResolver解析视图、View渲染内容这几大环节。很多教程喜欢把重点放在前面两步，也就是“请求怎么找到Controller”，但很少讲清楚后面两步的细节。这次重温我最大的收获恰恰在这里：视图解析和响应跳转，才是决定你系统请求出口行为的关键。
这三种“出口姿势”，其实对应着三种完全不同的设计意图：
- 转发（Forward）：服务端内部跳转，浏览器地址栏不变，Request作用域的数据可以带到下一个页面。
- 重定向（Redirect）：浏览器重新发一次新请求，地址栏会变化，需要传参只能用URL参数或Flash属性。
- 自定义视图（Custom View）：不在默认的视图解析规则里走，而是由你写逻辑直接控制输出内容或跳转目标。
理解它们是解决很多“页面明明返回了却不对”问题的钥匙。比如你写了一个return "redirect:/user/list"，但如果把它理解成“转发到list页面”，那你就想不通为什么request里的数据没了；反过来如果写return "user/list"，想让浏览器URL变化，那也实现不了。
我做一个模拟项目X——一个简单的用户管理系统，包含注册、登录、列表查询、导出文件这几个功能。整个回顾过程都围绕这个项目来展开，因为只有放到真实场景里，才能把细节讲明白。
1.1 从Servlet原生跳转方式说起，理解SpringMVC封装的逻辑起点
SpringMVC的转发和重定向，底层其实还是Servlet里面的RequestDispatcher.forward()和HttpServletResponse.sendRedirect()。你只是不用写那一坨原生代码了，而是通过返回值字符串加前缀让框架替你完成。
原生Servlet写转发是这样的：
RequestDispatcher dispatcher = request.getRequestDispatcher("/WEB-INF/views/user/list.jsp"); dispatcher.forward(request, response);而SpringMVC只需要：
return "user/list";前提是你配置了内部资源视图解析器。默认的InternalResourceViewResolver会在你返回的字符串前后拼接前缀和后缀，拼出一个真实路径，再替你做forward动作。
这个“字符串到真实资源路径”的映射规则，是所有跳转机制的地基。搞清楚它，你就能明白为什么写return "user/list"的时候，实际请求到了/WEB-INF/views/user/list.jsp，而不是直接到/user/list这个URL。很多人刚学时老在这里绕圈子，其实就是没把“逻辑视图名”和“物理资源路径”分清楚。
1.2 逻辑视图名、物理资源路径与ViewResolver三者关系
我画过一张图在心里：请求进来，HandlerMethod执行完，拿到ModelAndView，里面可能只存了一个字符串（逻辑视图名）。DispatcherServlet把这个字符串交给ViewResolver去解析，ViewResolver像一个翻译官，把逻辑名翻译成真正的View对象。最终的View对象有render()方法，负责把模型数据输出到响应里。
这中间的关键点是：ViewResolver不只一个，而且它们有执行顺序。你返回的字符串可以由多个解析器轮流尝试，第一个能成功解析的就生效。
我项目里配置了俩解析器：
<!-- 优先级高的解析器：解析基于前缀匹配的视图名 --> <bean class="org.springframework.web.servlet.view.UrlBasedViewResolver"> <property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/> <property name="prefix" value="/WEB-INF/views/"/> <property name="suffix" value=".jsp"/> <property name="order" value="1"/> </bean> <!-- 兜底解析器：用于解析自定义视图 --> <bean class="org.example.framework.CustomViewResolver"> <property name="order" value="2"/> </bean>order值越小优先级越高。框架先试第一个，如果它解析不了，再走第二个。这个顺序问题是我这次重温时踩到的一个典型坑：刚开始自定义视图不生效，就是因为内部资源视图解析器的order值比自定义的低，导致所有视图名都被它吞了，根本轮不到自定义解析器出场。
2. 直接页面转发：别只知道return "xxx"，forward前缀才是完整的处理链路
先把我踩过的坑摆出来：我之前一直用return "hello"跳页面，然后听说加了forward:前缀也能跳，而且“更直接”。我就把代码改成了return "forward:hello"，一测试直接404。后来才搞清楚，forward:前缀不走默认的拼接规则，它后面的串是一个URL路径，不是逻辑视图名。
2.1 forward前缀与默认视图解析器的本质区别
默认的return "user/list"，框架会交给ViewResolver解析，加上前缀后缀变成/WEB-INF/views/user/list.jsp，然后转发到那个JSP资源。这里user/list是“相对于视图解析器配置的逻辑视图名”。
而return "forward:/user/list"，前缀告诉DispatcherServlet：别走视图解析器那套逻辑名解析了，直接把后面的/user/list当成一个请求路径，内部转发过去。这个路径会重新走一遍DispatcherServlet的请求处理流程，匹配到对应的@RequestMapping方法，再走那个方法返回的视图。
差异看起来不大，实际影响非常大。最典型的一个场景：做数据预处理后跳同一页面。比如模拟项目X里的用户列表，列表数据平常是从数据库查的，但有一种情况是从 Excel 导入后马上看列表。这时候Controller的做法一般是导入完成后内部转发到列表页的请求地址，复用已有查询接口，而不是自己再去查一遍。
@RequestMapping("/import") public String importData(@RequestParam MultipartFile file, ...) { // 解析Excel，批量插入用户数据 userService.batchImport(file); // 直接走查询接口的请求路径，复用列表页展示逻辑 return "forward:/user/list"; }这里必须用forward:，如果是默认的return "user/list"就去JSP了，绕过了Controller里的查询方法，页面上不会有新导入的数据。而你要特别注意URL路径不能少了开头的/。
2.2 forward跨Controller跳转时，Request作用域数据的传递限制
forward:虽然是一次服务端内部跳转，但有个容易被忽略的细节：它和“直接返回逻辑视图名”比起来，多了“重新经过MVC处理流程”这一步。这带来的结果是，原来Controller方法中Model里的数据能不能带到下一步，取决于你用什么方式放数据。
我在模拟项目X里的一个支付回调场景里踩了这个坑：A方法里request.setAttribute("orderId", orderId)，然后forward:/order/detail。在浏览器上看，detail页面能通过request.getAttribute("orderId")拿到数据，因为在Servlet容器里forward共享同一个Request对象。但如果你用的是model.addAttribute("orderId", orderId)，在forward到Controller方法后，新的Controller方法不一定能直接通过@ModelAttribute拿到旧Model里的值。
我把这个现象仔细验证过后，得出的可靠结论是：Model的生命周期和当前Controller方法绑定，forward到新Controller后，新方法的Model是新创建的。如果想跨方法传数据，最稳的做法还是：
@RequestMapping("/prepare") public String prepare() { // 用RedirectAttributes或手动setAttribute，看目标方法怎么接收 request.setAttribute("fromPrepare", true); return "forward:/user/list"; }在目标方法里，用(Boolean) request.getAttribute("fromPrepare")来取。不过靠request属性传值不够优雅，更推荐的做法是拼到URL参数里，或者改用RedirectAttributes做重定向传参。
2.3 什么时候直接用forward前缀，什么时候交给ViewResolver
很多同学会纠结：既然forward:这么“直接”，为什么不统一都用它？答案很简单：可以，但牺牲的是视图解析的灵活性。
默认return "user/list"的好处是，视图名和物理路径解耦。未来你想把JSP换成Thymeleaf模板，或者迁移到一个远程CDN上的HTML，只要调整ViewResolver配置，Controller代码不用改。而return "forward:/user/list"写死了URL，和代码耦合在了一起。
我现在的习惯是：
- 跳同一个Controller内部、或不要求视图解析器灵活性的场景，直接
return "user/list"，让解析器管。 - 需要立刻走另一个HTTP路径、且希望重新经过SpringMVC整个处理链（比如过拦截器、重新匹配Handler）的场景，用
forward:前缀。 - 凡是涉及登录拦截的页面跳转，我基本都用
forward:，因为这样会重新走拦截器链，安全性更有保障。
这个取舍没有绝对对错，但建议你在项目里定一个统一规范，不然团队里每个人写的跳转方式不一样，排查跨模块问题的时候会非常痛苦。
3. 页面重定向：redirect前缀的底层逻辑与参数传递那些坑
重定向和转发最大的体验差异，用户最直观的感受就是地址栏变了。技术上本质差异更大：重定向会让浏览器发一个全新的GET请求，之前的Request对象就没了。我在模拟项目X里实现“注册成功后跳转到登录页并带上提示信息”时，对这块体会特别深。
3.1 为什么重定向时Model里的数据会丢
先还原一个典型翻车现场。我最初写的是：
@RequestMapping("/register") public String register(User user, Model model) { userService.save(user); model.addAttribute("message", "注册成功"); return "redirect:/login"; }结果在登录页怎么都拿不到message。原因很简单：redirect:告诉浏览器去请求/login，这是一次全新的Request，原来Request里的attribute全丢了，Model自然也不在了。
要传数据，最常见的做法就两种：
- 拼URL参数：
return "redirect:/login?message=" + URLEncoder.encode("注册成功", "UTF-8"); - 用Flash属性：重定向前存到Session的一个特殊区域，重定向后马上取出并立即清掉。
我强烈推荐用Flash属性，因为URL参数遇到中文很容易出乱码，而且有些场景不想让用户看到参数。
3.2 RedirectAttributes传参：Flash机制的正确打开方式
SpringMVC专门为跨重定向传数据准备了一个东西，就是RedirectAttributes。用法不复杂：
@RequestMapping("/register") public String register(User user, RedirectAttributes ra) { userService.save(user); ra.addFlashAttribute("message", "注册成功，请登录"); return "redirect:/login"; }然后在目标Controller方法里这样拿：
@RequestMapping("/login") public String login(@ModelAttribute("message") String message, Model model) { // message就是上个请求通过Flash属性传过来的值，自动放进Model return "login"; }Flash属性能在Session里存活一次请求，从Session中取出后立即删除，避免下次请求还带着脏数据。这里有个坑我特别提醒：Flash属性在“重定向后的那个GET请求”里读完之后就没了，如果你再刷新页面，数据不会重复出现。也正是这个特性，它才叫“一次性的提示信息”。
我在模拟项目X里把注册、登录、退出登录三块都做成重定向+Flash提示，体验比URL参数干净太多。一个额外的小技巧：Flash属性因为存在Session里，如果中间有跨域请求或者浏览器禁用了Cookie，Session不生效，这个方案就白搭。但一般业务系统很少碰到这种情况，所以放心用就好。
3.3 重定向地址的动态处理：相对路径、绝对路径和上下文路径
重定向时最坑的，是目标地址怎么写。我实测过几种写法，直接说结论：
return "redirect:/user/list"：相对于站点根路径的重定向，框架自动加上contextPath。return "redirect:user/list"：相对路径，浏览器会在当前URL所在目录下拼user/list。return "redirect:https://example.com/user/list"：需要拼完整外部地址，一般用于支付回调、单点登录跳转。
绝大多数内部页面跳转，用第一种就好。自动拼接contextPath这个行为，指的是如果你的系统部署在/myapp这个上下文下，redirect:/user/list实际会变成/myapp/user/list，浏览器能正确访问。你手动去拼/myapp反而会出问题。
在我做模拟项目X的时候，遇到过这样一个情况：部署环境上下文路径是/，开发环境是/demo，如果代码里写死redirect:/demo/user/list，线上就404。用redirect:/user/list反而开发、测试、生产都不受影响。这是重定向里最值得记的一条经验，也是很多人掉过坑的“上下文路径陷阱”。
4. 自定义视图：当默认的视图解析器扛不住的时候
前两块内容聚焦转发和重定向，现在回到“视图”本身。大多数情况下InternalResourceViewResolver加一个JSP就完事了，但总有一些特殊输出不好用JSP实现。比如我项目里需要输出CSV格式的用户数据、生成一个JSONP回调、动态生成图片验证码，这些场景用“自定义视图”就比在Controller里直接response.getWriter().write()干净得多。
4.1 实现一个最小可用的自定义视图
SpringMVC里的View接口非常小，核心就一个方法：
public interface View { String getContentType(); void render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception; }但实际开发中你不会直接实现这个接口，而是继承AbstractView。它帮你处理了contentType设置、请求和响应的编码，让你只关心渲染逻辑。
我拿模拟项目X里导出用户CSV的场景举例。写一个CsvView：
public class CsvView extends AbstractView { private static final String CONTENT_TYPE = "text/csv;charset=UTF-8"; public CsvView() { setContentType(CONTENT_TYPE); } @Override protected void renderMergedOutputModel( Map<String, Object> model, HttpServletRequest request, HttpServletResponse response) throws Exception { response.setCharacterEncoding("UTF-8"); response.setContentType(CONTENT_TYPE); // 设置下载响应头，让浏览器弹下载而不是打开页面 response.setHeader("Content-Disposition", "attachment; filename=user_list_" + System.currentTimeMillis() + ".csv"); List<User> users = (List<User>) model.get("users"); StringBuilder sb = new StringBuilder("id,name,email\n"); for (User u : users) { sb.append(u.getId()).append(",") .append(u.getName()).append(",") .append(u.getEmail()).append("\n"); } response.getWriter().write(sb.toString()); response.getWriter().flush(); } }这样一个自定义视图的内容有了，但它怎么被找到呢？这就要引入自定义的ViewResolver了。
4.2 把自定义视图接到ViewResolver里
自定义ViewResolver有两种写法。一种简便的实现是直接在AbstractCachingViewResolver的子类里硬编码一个视图名到View对象的映射；另一种是写一个通用的解析器，先看视图名是否有特殊前缀（比如csv:开头的就分发给CsvView），否则返回null让后面的解析器处理。
我在模拟项目X里用的是第二种，好处是既不影响普通JSP的解析，又能处理CSV的特殊情况。代码大致如下：
public class CsvViewResolver extends AbstractCachingViewResolver { @Override protected View loadView(String viewName, Locale locale) throws Exception { if (viewName.startsWith("csv:")) { return new CsvView(); } return null; } }然后在SpringMVC配置里把它加进去，注意order的顺序。之前强调了，order值小的先执行。如果把CsvViewResolver设为order=1，那所有名字以csv:开头的视图名就会被它接走，别的解析器就不用管了。这样做的好处是Controller里写return "csv:userList"，框架就知道去搭建CSV下载，特别直观。
4.3 自定义视图里的编码与浏览器兼容问题
自定义视图不是写完了就完事，我踩过的坑主要卡在编码上。AbstractView里的render()方法，在renderMergedOutputModel()之前会设置response.setContentType(...)，但如果你在子类里没有先调setContentType再拿Writer，响应头的编码可能不是UTF-8，中文会乱码。
我发现在有些Tomcat版本下，就算设置了text/csv;charset=UTF-8，里面的中文依然可能乱码，原因就是getWriter()在设置编码之前被调用了。稳妥做法是：
response.setCharacterEncoding("UTF-8"); response.setContentType("text/csv;charset=UTF-8"); // 再getWriter另外，CSV文件的BOM问题值得单独提一下。Excel打开UTF-8编码的CSV时，如果文件开头没有BOM（即U+FEFF字节），中文会直接乱成一锅粥。我加了一句response.getWriter().write("\uFEFF");才把这问题解决。这些Windows下的兼容性问题，如果不是实际做过导出功能，光看文档是根本学不到的。
5. 双解析器与顺序匹配：多视图解析器共存时的项目实战
单视角解析器的时候可能感觉不到什么，但我这次在模拟项目X里同时用了JSP解析器和自定义CSV解析器，才发现多个ViewResolver的配合顺序是重头戏。在这个环节我把SpringMVC源码翻了一遍，确认了它的解析流程是：按order值从小到大逐个调用ViewResolver的resolveViewName()，如果哪个解析器能返回非null的View对象，就直接采用，后面的都不执行了。
5.1 order参数决定“谁先说话”
这个机制和拦截器的执行方式有相似之处，但更容易踩坑。比如你给UrlBasedViewResolver配的order是Ordered.LOWEST_PRECEDENCE，给CsvViewResolver配的order是1，那遇到普通视图名时，CsvViewResolver先执行，但它不处理普通名字，返回null，框架继续问下一个解析器。只有名字符合它规则的时候，它才返回View。
反之，如果你把普通JSP解析器放最前面且它处理了所有名字，那自定义视图解析器根本没有机会执行。一个常见做法是：普通解析器只处理以特定前缀开头的视图名，比如内部资源统一叫jsp:开头。但这种情况会让Controller代码看起来挺别扭，我更倾向于让自定义解析器只处理特殊前缀，其他的都放给普通解析器。
5.2 给视图解析器排好队：推荐的项目配置方式
我在模拟项目X里最终采用的配置是这样的：
<!-- 1. 自定义视图解析器：只处理csv:开头的视图名 --> <bean class="org.example.framework.CsvViewResolver"> <property name="order" value="1" /> </bean> <!-- 2. 默认的内部资源解析器：处理剩余情况 --> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/views/" /> <property name="suffix" value=".jsp" /> <property name="order" value="2" /> </bean>Controller里两个路由：
@RequestMapping("/export") public String export(Model model) { List<User> users = userService.findAll(); model.addAttribute("users", users); // 这个视图名不会被JSP解析器处理，而是被CsvViewResolver接走 return "csv:userList"; } @RequestMapping("/list") public String list(Model model) { model.addAttribute("users", userService.findAll()); // 常规JSP页面 return "user/list"; }这样配置最大的好处，是Controller里的返回值语义非常清楚。看到csv:开头就知道是导出类操作，看到普通路径就知道是页面跳转。源码里ViewResolver的职责也因此变得单一，扩展新格式只需要再写一个解析器插到链路上。
5.3 视图名冲突时的处理策略
多个解析器并存时，最怕的就是两个解析器都能解析同一个视图名。比如我给CsvViewResolver加了一个判断，不只是csv:开头的视图名，还额外加了userlistwithdetail这种完整名也让它处理。结果有一次我返回user/list，JSP解析器先看它不认识csv:就不处理，轮到自定义解析器的时候，它因为规则里没有这个名也返回null，最后JSP解析器正常处理。这没问题。
但假设我把两个解析器的order反过来，或者让自定义解析器没有返回null的逻辑，而是硬匹配所有名字，那一切页面就都会被它接管，JSP里的数据就都渲染不出来了。自定义ViewResolver如果没有匹配到合适处理方式，一定要返回null，表示“我干不了，让后面的来”，这几乎是写自定义解析器最重要的守则。
还有一个小细节：AbstractCachingViewResolver默认会缓存解析结果。如果你在开发环境下频繁改视图代码但看不到效果，可能就是缓存闹的。我曾在文档里查到可以通过setCacheLimit设置为0禁用缓存，但生产环境这么做会牺牲性能。更优雅的思路是开启Spring的cleanupAfterInclude之类的清理机制，具体要看你的Spring版本。
6. 常见问题与排查技巧实录
这块算是我这次重温的浓缩精华，很多坑排查了好久，总结成一张速查表方便你以后直接翻。
| 现象 | 根本原因 | 解决方式 |
|---|---|---|
加了forward:前缀后404 | URL路径漏了前导/，或目标路径不存在 | 检查路径是否以/开头，确认目标Controller的@RequestMapping |
| 重定向后Model数据丢失 | 重定向产生新请求，原Request/Model销毁 | 改用RedirectAttributes.addFlashAttribute传参 |
| 重定向的中文变成乱码 | URL参数未编码 | 用URLEncoder.encode，或改用Flash属性 |
| 自定义View不生效 | ViewResolver的order顺序不对，被别的解析器截胡 | 检查order，让自定义解析器优先执行或限定特殊前缀 |
| CSV下载中文乱码 | 未先设置UTF-8编码，或缺少BOM | 设置response.setCharacterEncoding("UTF-8")，CSV开头写\uFEFF |
| Excel打开CSV中文出现乱码 | 缺少UTF-8 BOM | 在输出内容最前面写BOM标记 |
InternalResourceViewResolver无法处理非JSP视图 | 默认解析器没有对应的View类 | 自定义Layer或使用UrlBasedViewResolver指定viewClass |
| Flash属性在二次刷新时消失 | 这是Flash机制的一次性特性，不是Bug | 如果希望每次刷新都显示，就别用Flash，改用URL参数或Cookie |
6.1 排查思维：先确认是哪一层出的问题
遇到跳转相关的故障，我现在的排查顺序基本固定了，分享出来省得你在蛛丝马迹里乱翻：
- 先看浏览器Network里最后一个HTTP状态码和地址栏。如果是302，那是重定向；如果地址栏没变但内容变了，通常是转发。
- 再看Spring日志里有没有“ViewResolver”相关内容。SpringMVC框架会记录每个视图名和解析结果，看到日志基本能知道是哪个解析器处理了。
- 最后再看Controller方法的返回值和Model里的数据。是否是Flash属性没设置、是否是视图解析器吞掉了特殊前缀。
这套顺序适合百分之九十的跳转问题。遇到特别隐蔽的，再开Debug日志，把org.springframework.web.servlet包日志级别调成Debug，信息量大到你想哭，但也能最快定位。
6.2 前端控制器里最容易踩的“伪配置”问题
再说一个非常典型的低级坑：有人以为配置了InternalResourceViewResolver后，所有返回的视图名都会自动拼上前缀后缀，结果在web.xml里配置DispatcherServlet的url-pattern时写了/*。这么做，所有静态资源也会进入DispatcherServlet，让你跳JSP的时候可能被静态资源处理器拦截，第一次访问能通，第二次刷新就各种异常。
正确做法是用/作为url-pattern，然后在Spring配置里单独放行静态资源。这是我做模拟项目X时踩过、也帮不少人解决过的问题。对于SpringBoot项目更简单些，默认静态资源配置基本够用，但如果你从传统Spring项目迁移过来，还是要确认一下有没有这层坑。
6.3 一点关于转发与重定向选择的建议
如果是页面注册、登录、支付这类需要防重复提交的场景，重定向是必然选择。如果是查询列表、预览详情、报表展示这类不希望地址栏变化，又需要带上查询条件和数据的场景，优先转发。
在我看来，SpringMVC的三板斧——forward:、redirect:、自定义View，本质上是把一个简单的“页面跳转”需求拆成了三种不同用途的机制。转发是为了复用内部处理逻辑，重定向是为了让浏览器保持正确的URL语义并防重复提交，自定义视图是为了跳出视图解析的规则限制。你要是能把它们各自的适用场景刻在脑子里，写Controller的时候根本不用犹豫，哪一种该用哪一种，直接就是顺手的事。
最后再分享一个我个人的小习惯：不管用哪种跳转方式，Controller里返回值我尽量不写死路径，能抽常量就抽常量，尤其是重定向和转发的目标URL。因为项目一旦大起来，两个Controller之间跳来跳去，字符串一写错，查起来真的很费劲。把跳转目标集中在常量类里统一管理，既容易排查，也方便以后做重构，别嫌这点小活麻烦。
