这期继续Spring MVC的学习。标题里写了三件事直接页面转发、自定义视图、页面重定向。在很多人看来这不就是在controller里return一个字符串的事吗实际没那么简单。这三件事背后对应的正是Spring MVC的视图解析和视图渲染机制也是面试时容易被问倒的地方——“你return redirect:/xxx的时候框架到底做了什么”“为什么自定义的视图不生效”“为什么重定向之后模型数据取不到了”如果你还没认真想过这些问题这篇文章正好帮你把整个视图处理链路打通。适合谁看准备找工作正在刷Spring MVC面试题的Java开发、刚开始学SSM整合的学生、还有工作两三年想回头啃框架源码的人。很多人一开始只会用Spring MVC知道控制器返回一个字符串视图解析器帮你拼JSP路径再往后的细节就不清楚了。今天这个黑盒要打开看看。1. 先搞清楚视图解析链路ViewResolver在做什么1.1 InternalResourceViewResolver到底怎么拼路径大多数Spring MVC项目里都有类似这样一段配置bean idviewResolver classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/jsp// property namesuffix value.jsp/ /bean这个配置看着简单但它是整个视图处理链路的起点。控制器方法返回一个逻辑视图名比如user/listDispatcherServlet接手之后会遍历容器中所有的ViewResolver逐个调用resolveViewName()方法。InternalResourceViewResolver做的事可以概括成一句话把prefix 逻辑视图名 suffix拼成一个内部资源路径得到/WEB-INF/jsp/user/list.jsp然后用InternalResourceView包装这个路径最终通过RequestDispatcher.forward()把请求转发过去。注意“拼”这个字意味着你返回的字符串不能乱写。返回user/list没问题返回/user/list有时候也能匹配因为内部资源路径的解析逻辑会自动处理多余斜杠。但如果你在逻辑视图名里写了完整的相对路径甚至把.jsp后缀也带上了比如return user/list.jsp那么拼接结果会变成/WEB-INF/jsp/user/list.jsp.jsp等待你的就是404。DispatcherServlet的视图解析流程大致是这样HandlerAdapter执行完controller方法后得到一个ModelAndViewprocessDispatchResult()里调用render()render()里通过resolveViewName()遍历ViewResolver链取到View对象最后调用View的render()方法把模型数据输出到响应里。所以视图解析器和视图本身在Spring MVC里是两个相对独立的抽象这也是后面自定义视图能成立的基础。1.2 默认机制能解决大部分场景但边界很明显InternalResourceViewResolver能覆盖最常见的技术栈组合Spring MVC JSP。但它有几个硬伤第一输出类型固定是JSP页面。想直接返回一个Excel报表、PDF文件、JSON数据或者XML靠默认的JSP路径拼接是做不到的。第二无法优雅地处理重定向。forward和redirect在HTTP层面是两种完全不同的语义InternalResourceViewResolver本身不认识redirect:这类前缀它只会傻乎乎地拼路径。本质上还是需要Spring MVC基于UrlBasedViewResolver构建视图时识别特殊前缀才能把重定向和转发交给对应的视图类。第三逻辑视图名与物理路径强绑定。JSP目录一调整一堆controller里的视图名可能都要跟着改。这种设计在大型项目里很痛苦。我接过一个老项目为了给现有页面加一个导出Excel功能最初直接在controller里往HttpServletResponse的输出流里写POI生成的Workbook写了几百行后来改成自定义视图代码量直接砍半逻辑也清爽得多。所以在开始动手之前先建立整体认知Spring MVC的视图体系由ViewResolver和View两层组成。ViewResolver负责把逻辑视图名解析成View对象View负责把模型数据渲染到响应。搞懂这两层今天说的三件事就都不难理解。2. 直接页面转发显式控制forward的三种姿势2.1 用forward:前缀让转发意图一目了然你可以在controller里直接这样写GetMapping(/send) public String send() { return forward:/target; }这个返回值和普通的return target不一样。当DispatcherServlet拿着视图名forward:/target去解析时UrlBasedViewResolver会识别出forward:前缀不再走prefix/suffix拼接逻辑而是直接创建一个InternalResourceView目标路径就是/target。渲染阶段InternalResourceView会通过RequestDispatcher把这个请求转发到/target这个URL对应的处理器让框架重新匹配一次路径。为什么需要这种写法最常见的场景是在拦截器或者控制器里做权限跳转。比如用户没登录你想让他去看登录页但你又不想把登录页的JSP物理路径写死在代码里用forward:/login就能让框架重新走一遍路由匹配交给login对应的controller处理后续逻辑都在同一个请求内完成。需要注意两点。第一forward:后面的路径必须以/开头表示相对于应用根路径如果你写成forward:target这是相对于当前请求URL的相对路径很容易解析到不存在的地址基本全是坑。第二forward是一次请求内的服务器端跳转浏览器地址栏不会变request作用域里的数据在转发前后是共享的这一点和后面要讲的重定向有本质区别。2.2 直接操作HttpServletResponse的底层转发在Controller里手动控制转发其实也不复杂GetMapping(/legacy) public void legacy(HttpServletRequest request, HttpServletResponse response) throws Exception { request.getRequestDispatcher(/WEB-INF/jsp/legacy.jsp).forward(request, response); }注意这个方法的返回类型是void转发完成后不需要再返回任何东西。这里传给getRequestDispatcher()的是物理路径也就是真实存在的一个JSP文件路径和上面的forward:/target逻辑路径不是一回事。这种方法更底层、更直白但带来的问题是代码测试难度上升。你没法用MockMvc简单地断言返回的视图名因为你根本没有返回视图名视图的渲染逻辑被硬编码到controller里了。而且千万要小心在调用forward()之前不能往响应里写过任何内容否则会抛IllegalStateException现场可以复盘一下是不是哪里提前flush了。2.3 直接转发和默认视图解析怎么选场景默认逻辑视图名显式forwardJSP路径固定推荐配置清晰也可以但冗余需要走路由重新匹配不支持会拼成JSP路径推荐语义明确拦截器里做页面跳转很别扭推荐带模型数据自动合并Model同样支持测试友好度高中我个人在实际项目里很少用forward:/xxx这种写法因为大部分页面转发场景用逻辑视图名就够了。真正要用到forward:的地方是当你需要从一个处理器跳到另一个处理器并且希望它们共享同一个请求对象时。比如一个统一入口的Controller按参数分流到不同的处理逻辑用forward就比重定向更合适因为数据不需要序列化到URL参数或session里。3. 自定义视图与视图解析器把渲染逻辑从JSP中解放出来3.1 ViewResolver接口其实很简单自定义视图解析器的门槛比自己想象的低得多。ViewResolver接口就一个方法public class SimpleXmlViewResolver implements ViewResolver { Override public View resolveViewName(String viewName, Locale locale) throws Exception { if (viewName.startsWith(xml:)) { return new SimpleXmlView(viewName.substring(4)); } // 解析不了就返回null让下一个解析器处理 return null; } }在Spring MVC配置里注册这个解析器bean idxmlViewResolver classcom.example.resolver.SimpleXmlViewResolver/ bean idjspViewResolver classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/jsp// property namesuffix value.jsp/ property nameorder value3/ /bean这里的关键在于order属性。DispatcherServlet维护了一个有序的ViewResolver集合解析器按order从小到大逐个尝试。InternalResourceViewResolver默认的order值是Integer.MAX_VALUE意味着它排在最后。如果自定义解析器能够解析的视图名必须先返回一个View对象框架就不会继续往后找。如果返回null框架会问下一个解析器。这是整个自定义机制能正常工作的前提。3.2 自定义View的实现render方法决定一切View接口同样很简单核心是一个getContentType()和一个render()public class SimpleXmlView implements View { private String viewName; public SimpleXmlView(String viewName) { this.viewName viewName; } Override public String getContentType() { return text/xml;charsetUTF-8; } Override public void render(MapString, ? model, HttpServletRequest request, HttpServletResponse response) throws Exception { response.setContentType(getContentType()); PrintWriter writer response.getWriter(); writer.write(?xml version\1.0\ encoding\UTF-8\?); writer.write(data); for (Map.EntryString, ? entry : model.entrySet()) { writer.write( entry.getKey() ); writer.write(String.valueOf(entry.getValue())); writer.write(/ entry.getKey() ); } writer.write(/data); } }这个视图做的事情很简单把Model里的键值对直接渲染成XML片段。controller里这样返回GetMapping(/api/xml) public String xml(Model model) { model.addAttribute(status, ok); return xml:hello; }这里有个容易踩的坑render方法里的response输出如果controller里已经做了什么操作导致response被提交再调用getWriter()或者write()就会报错。还有一个经验是getContentType()一定要带charsetUTF-8不然中文全部变问号这个坑我踩过不止一次。3.3 自定义视图的经典战场Excel、PDF、JSON自定义视图最常见的应用场景是非HTML响应。现在一些项目需要导出接口如果直接用HttpServletResponse输出文件流代码会散落在controller里不好维护。推荐思路是这样的定义一个ExcelView继承Spring的AbstractXlsxView在buildExcelDocument()方法里把模型数据填充到Workbook里。然后在Spring配置里用BeanNameViewResolver搭配视图Beanbean idbeanNameViewResolver classorg.springframework.web.servlet.view.BeanNameViewResolver property nameorder value1/ /bean bean iduserExcelView classcom.example.view.UserExcelView/controller方法GetMapping(/export) public String export(Model model) { model.addAttribute(users, userService.listAll()); return userExcelView; }BeanNameViewResolver的逻辑非常简单拿着视图名去Spring容器里找同名的Bean找到了就返回这个Bean找不到就返回null。这种写法下controller不用关心Excel是怎么生成的视图名和Bean名天然对应测试和替换都很方便。对于JSON输出Spring MVC自带的MappingJackson2JsonView做了类似的事。你配置好Jackson依赖之后返回一个带有MappingJackson2JsonView的视图名就能输出JSON前提是你把处理JSON的逻辑从ResponseBody里挪出来。不过日常开发中ResponseBody和RestController已经够用了并不是所有场景都需要自定义视图来输出JSON但理解这套机制对排查奇怪问题很有帮助。3.4 自定义视图的一个隐藏细节缓存Spring的AbstractCachingViewResolver默认会对解析结果做缓存也就是说同一个视图名第一次解析之后结果会被缓存起来之后的请求直接走缓存。这在生产环境里是性能优化但在开发期就是个坑你改了JSP或者改了自定义视图类刷新页面发现不生效十有八九是ViewResolver的缓存没清。解决方式有两种。第一种开发阶段设置InternalResourceViewResolver的cache属性为falseproperty namecache valuefalse/第二种如果你用的自定义解析器继承自AbstractCachingViewResolver在实现类的构造器里调用setCache(false)。不过这种配置只建议在开发环境用线上还是要开缓存不然每次请求都解析一遍视图压力都在JVM上。4. 页面重定向redirect的完整玩法与隐藏坑4.1redirect:前缀背后的RedirectView先看最熟悉的写法PostMapping(/save) public String save() { // 保存业务数据 return redirect:/user/list; }当视图名以redirect:开头时Spring MVC会忽略那些普通视图解析器的前后缀逻辑直接创建一个RedirectView目标是/user/list然后在渲染阶段调用response.sendRedirect(/user/list)浏览器收到302响应后再发起一次GET请求。这里要理解一个关键区别redirect:不是服务器端转发而是告诉浏览器去访问另一个地址。所以重定向是两次HTTP请求第一次请求的模型数据默认不会传递到第二次请求。很多人刚接触时都会困惑——为什么redirect之后model里的数据取不到了答案就在这里新请求是浏览器发出的全新请求模型数据只存在于第一次请求的模型对象里。RedirectView本身也可以手动创建GetMapping(/go) public ModelAndView go() { RedirectView view new RedirectView(/target); view.setContextRelative(true); return new ModelAndView(view); }setContextRelative(true)表示这个路径是相对应用根路径的自动拼接应用上下文路径。这种方式比字符串更灵活但一般用字符串就够了。4.2 PRG模式与RedirectAttributes防表单重复提交的标准方案重定向最经典的应用场景是PRG模式也就是Post/Redirect/Get。一个表单POST提交之后如果处理逻辑完成时用的是forward用户按F5刷新页面浏览器会用同样的POST数据再发一次请求表单就重复提交了。而如果用PRGPOST请求响应是302浏览器自动发起GET请求刷新页面时重复的是GET请求不会造成重复提交。但PRG有个问题——怎么把操作结果提示交给下一个页面有人用URL拼接?messagesuccess丑不说参数一多还容易超长敏感数据也会暴露在地址栏里。Spring MVC为此提供了RedirectAttributesPostMapping(/save) public String save(RedirectAttributes attributes) { // 保存业务数据 attributes.addFlashAttribute(message, 保存成功); return redirect:/user/list; }在目标JSP里直接${message}就能取到。这个机制的实际载体是FlashMap。Spring MVC在请求结束时会把FlashMap保存到session中重定向产生的新请求开始时会从session读取FlashMap把它合并到当前请求的属性里然后立即清除。这意味着flash attribute只在重定向后的第一次请求里有效不会被后续请求反复读到正合“提示一次就消失”的预期。4.3 重定向的常见问题路径、编码、数据传递第一个坑是路径写错。return redirect:user/list不带前导斜杠会被解析成相对于当前URL的相对路径。比如当前请求路径是/admin/doSave最终跳转目标是/admin/user/list这通常不是你想要的。养成好习惯一律写成redirect:/user/list以斜杠开头就一定从应用根路径算起不容易出错。第二个坑是中文参数乱码。重定向时如果想在URL里带参数return redirect:/search?keyword URLEncoder.encode(keyword, StandardCharsets.UTF_8.name());直接拼字符串遇到中文和特殊字符会出问题必须做URL编码。更规范的做法是用UriComponentsBuilderUriComponentsBuilder.fromPath(/search) .queryParam(keyword, keyword) .build().encode().toUriString();第三是flash attribute丢失。有个常见场景重定向目标是外部域名或者目标Controller配置了特殊的拦截器把Attr清掉了后者少见前者比较典型。FlashMap默认只在同一应用内的重定向中生效如果你跳转到外网地址比如redirect:http://other.example.com/notifyflash attribute是传不过去的因为外网请求里没有你的session信息。5. 一条请求里的视图控制策略综合实例与选择原则5.1 一个带登录拦截和导出功能的综合场景把今天说的东西组合起来设计一个完整场景。假设系统里有一个用户列表页面要求登录后才能访问支持导出Excel登录成功后显示欢迎信息。先写拦截器处理未登录用户public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(false); if (session null || session.getAttribute(loginUser) null) { // 未登录直接转发到登录页 request.getRequestDispatcher(/WEB-INF/jsp/login.jsp).forward(request, response); return false; } return true; } }登录成功后的控制器PostMapping(/login) public String login(String username, RedirectAttributes attributes) { if (admin.equals(username)) { attributes.addFlashAttribute(welcomeMsg, 欢迎回来); return redirect:/user/list; } // 登录失败回到登录页 return forward:/login; }用户列表控制器GetMapping(/user/list) public String userList(Model model) { model.addAttribute(users, userService.findAll()); return user/list; }导出Excel的控制器配合BeanNameViewResolver和自定义视图GetMapping(/user/export) public String export(Model model) { model.addAttribute(users, userService.findAll()); return userExcelView; }这套组合里拦截器用RequestDispatcher.forward保证地址栏不变化登录失败用forward:/login回到登录页并且保留错误提示登录成功用redirect:/user/list防止表单重复提交加addFlashAttribute传递欢迎信息导出功能用自定义视图隔离渲染细节。一个简单的CRUD项目三种视图控制机制全用上了。5.2 什么时候用forward什么时候用redirect什么时候自定义视图维度forwardredirect自定义视图URL变化不变变化取决于响应类型请求次数1次2次1次数据传递request域共享需flash或URL参数模型数据直出防重复提交不支持支持不涉及跨应用跳转不支持支持不涉及最适合的场景权限拦截、页面渲染表单提交、登录成功导出、非HTML响应我的原则很简单只要不需要改变浏览器地址栏就优先用forward只要涉及表单提交、外部跳转、防重复提交就用redirect只要响应类型不是HTML页面就考虑自定义视图。反过来如果既希望地址栏不变又希望响应的是一个JSON文件那自定义视图是最干净的选择。6. 常见问题与排查技巧实录6.1 视图解析失败的三个典型现象现象可能原因排查方向404且路径明显不合理视图名带后缀或物理路径打印最终拼接URL确认prefix/suffix500抛JSP编译异常JSP语法错误或缺少taglib依赖看具体异常堆栈定位JSP行号抛Could not resolve view with name所有ViewResolver都返回了null检查解析器order、名称前缀是否匹配排查的时候我一般先在DispatcherServlet的resolveViewName附近加断点或者看日志里有没有打印视图名。Spring MVC默认日志级别看不到这些细节但把org.springframework.web的日志级别调到DEBUG视图解析过程就一目了然了。6.2 重定向相关的隐藏坑重定向后模型数据取不到是出现频率最高的问题。理解“两次请求”概念后就不奇怪了但解决方式要分情况。如果目标页面需要的数据在重定向前已经存在数据库里直接重新查询。如果只是提示消息用RedirectAttributes.addFlashAttribute。如果你确实需要在重定向后继续访问原请求的request级数据说明这个场景本质上应该用forward重新考虑跳转方式。还有一次我在项目里遇到重定向后HTTP 405原因是原始请求是POSTcontroller POST方法处理完返回redirect:/user/list但/user/list这个路径只配置了GET请求。请求是重定向成功了浏览器发起的是GET最终因为没有匹配的Handler直接405。所以重定向目标地址必须保证有对应请求方法的Handler。6.3 自定义视图不生效的排查自定义视图不生效先别急着怀疑配置写错。按顺序排查自定义ViewResolver有没有注册到容器order设置对不对视图名是否匹配到了前缀目标View的render方法是否真的执行了其中order设置不对是最隐蔽的问题——如果你没设置order自定义解析器和InternalResourceViewResolver的优先级相同都排在默认值阶段此时解析顺序就不确定很可能InternalResourceViewResolver先拿到视图名拼了一个不存在的JSP路径导致404。给你一个调试技巧在自定义ViewResolver的resolveViewName方法第一行加一行日志输出当前请求解析的视图名。如果没有输出说明这个解析器根本没被调用如果有输出但返回了null说明你的前缀匹配条件不满足。两种情况的下一步操作完全不同有日志就能快速分流。DEBUG - resolve viewName: userExcelView, resolver: BeanNameViewResolver日志里看到这种情况就去检查BeanNameViewResolver对应的Bean是否真的定义了id为userExcelView的视图类。这类问题八成是Bean命名不一致。我在实际项目中摸索出的组合拳就是默认JSP用InternalResourceViewResolver特殊响应用BeanNameViewResolver加自定义View对外跳转一律redirect加flash attribute。这套思路用顺手之后再来应对任何视图层怪问题都不慌了核心其实就一句话把ViewResolver和View当成两个可插拔的环节靠日志和order理顺它们的关系。
这期继续Spring MVC的学习。标题里写了三件事直接页面转发、自定义视图、页面重定向。在很多人看来这不就是在controller里return一个字符串的事吗实际没那么简单。这三件事背后对应的正是Spring MVC的视图解析和视图渲染机制也是面试时容易被问倒的地方——“你return redirect:/xxx的时候框架到底做了什么”“为什么自定义的视图不生效”“为什么重定向之后模型数据取不到了”如果你还没认真想过这些问题这篇文章正好帮你把整个视图处理链路打通。适合谁看准备找工作正在刷Spring MVC面试题的Java开发、刚开始学SSM整合的学生、还有工作两三年想回头啃框架源码的人。很多人一开始只会用Spring MVC知道控制器返回一个字符串视图解析器帮你拼JSP路径再往后的细节就不清楚了。今天这个黑盒要打开看看。1. 先搞清楚视图解析链路ViewResolver在做什么1.1 InternalResourceViewResolver到底怎么拼路径大多数Spring MVC项目里都有类似这样一段配置bean idviewResolver classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/jsp// property namesuffix value.jsp/ /bean这个配置看着简单但它是整个视图处理链路的起点。控制器方法返回一个逻辑视图名比如user/listDispatcherServlet接手之后会遍历容器中所有的ViewResolver逐个调用resolveViewName()方法。InternalResourceViewResolver做的事可以概括成一句话把prefix 逻辑视图名 suffix拼成一个内部资源路径得到/WEB-INF/jsp/user/list.jsp然后用InternalResourceView包装这个路径最终通过RequestDispatcher.forward()把请求转发过去。注意“拼”这个字意味着你返回的字符串不能乱写。返回user/list没问题返回/user/list有时候也能匹配因为内部资源路径的解析逻辑会自动处理多余斜杠。但如果你在逻辑视图名里写了完整的相对路径甚至把.jsp后缀也带上了比如return user/list.jsp那么拼接结果会变成/WEB-INF/jsp/user/list.jsp.jsp等待你的就是404。DispatcherServlet的视图解析流程大致是这样HandlerAdapter执行完controller方法后得到一个ModelAndViewprocessDispatchResult()里调用render()render()里通过resolveViewName()遍历ViewResolver链取到View对象最后调用View的render()方法把模型数据输出到响应里。所以视图解析器和视图本身在Spring MVC里是两个相对独立的抽象这也是后面自定义视图能成立的基础。1.2 默认机制能解决大部分场景但边界很明显InternalResourceViewResolver能覆盖最常见的技术栈组合Spring MVC JSP。但它有几个硬伤第一输出类型固定是JSP页面。想直接返回一个Excel报表、PDF文件、JSON数据或者XML靠默认的JSP路径拼接是做不到的。第二无法优雅地处理重定向。forward和redirect在HTTP层面是两种完全不同的语义InternalResourceViewResolver本身不认识redirect:这类前缀它只会傻乎乎地拼路径。本质上还是需要Spring MVC基于UrlBasedViewResolver构建视图时识别特殊前缀才能把重定向和转发交给对应的视图类。第三逻辑视图名与物理路径强绑定。JSP目录一调整一堆controller里的视图名可能都要跟着改。这种设计在大型项目里很痛苦。我接过一个老项目为了给现有页面加一个导出Excel功能最初直接在controller里往HttpServletResponse的输出流里写POI生成的Workbook写了几百行后来改成自定义视图代码量直接砍半逻辑也清爽得多。所以在开始动手之前先建立整体认知Spring MVC的视图体系由ViewResolver和View两层组成。ViewResolver负责把逻辑视图名解析成View对象View负责把模型数据渲染到响应。搞懂这两层今天说的三件事就都不难理解。2. 直接页面转发显式控制forward的三种姿势2.1 用forward:前缀让转发意图一目了然你可以在controller里直接这样写GetMapping(/send) public String send() { return forward:/target; }这个返回值和普通的return target不一样。当DispatcherServlet拿着视图名forward:/target去解析时UrlBasedViewResolver会识别出forward:前缀不再走prefix/suffix拼接逻辑而是直接创建一个InternalResourceView目标路径就是/target。渲染阶段InternalResourceView会通过RequestDispatcher把这个请求转发到/target这个URL对应的处理器让框架重新匹配一次路径。为什么需要这种写法最常见的场景是在拦截器或者控制器里做权限跳转。比如用户没登录你想让他去看登录页但你又不想把登录页的JSP物理路径写死在代码里用forward:/login就能让框架重新走一遍路由匹配交给login对应的controller处理后续逻辑都在同一个请求内完成。需要注意两点。第一forward:后面的路径必须以/开头表示相对于应用根路径如果你写成forward:target这是相对于当前请求URL的相对路径很容易解析到不存在的地址基本全是坑。第二forward是一次请求内的服务器端跳转浏览器地址栏不会变request作用域里的数据在转发前后是共享的这一点和后面要讲的重定向有本质区别。2.2 直接操作HttpServletResponse的底层转发在Controller里手动控制转发其实也不复杂GetMapping(/legacy) public void legacy(HttpServletRequest request, HttpServletResponse response) throws Exception { request.getRequestDispatcher(/WEB-INF/jsp/legacy.jsp).forward(request, response); }注意这个方法的返回类型是void转发完成后不需要再返回任何东西。这里传给getRequestDispatcher()的是物理路径也就是真实存在的一个JSP文件路径和上面的forward:/target逻辑路径不是一回事。这种方法更底层、更直白但带来的问题是代码测试难度上升。你没法用MockMvc简单地断言返回的视图名因为你根本没有返回视图名视图的渲染逻辑被硬编码到controller里了。而且千万要小心在调用forward()之前不能往响应里写过任何内容否则会抛IllegalStateException现场可以复盘一下是不是哪里提前flush了。2.3 直接转发和默认视图解析怎么选场景默认逻辑视图名显式forwardJSP路径固定推荐配置清晰也可以但冗余需要走路由重新匹配不支持会拼成JSP路径推荐语义明确拦截器里做页面跳转很别扭推荐带模型数据自动合并Model同样支持测试友好度高中我个人在实际项目里很少用forward:/xxx这种写法因为大部分页面转发场景用逻辑视图名就够了。真正要用到forward:的地方是当你需要从一个处理器跳到另一个处理器并且希望它们共享同一个请求对象时。比如一个统一入口的Controller按参数分流到不同的处理逻辑用forward就比重定向更合适因为数据不需要序列化到URL参数或session里。3. 自定义视图与视图解析器把渲染逻辑从JSP中解放出来3.1 ViewResolver接口其实很简单自定义视图解析器的门槛比自己想象的低得多。ViewResolver接口就一个方法public class SimpleXmlViewResolver implements ViewResolver { Override public View resolveViewName(String viewName, Locale locale) throws Exception { if (viewName.startsWith(xml:)) { return new SimpleXmlView(viewName.substring(4)); } // 解析不了就返回null让下一个解析器处理 return null; } }在Spring MVC配置里注册这个解析器bean idxmlViewResolver classcom.example.resolver.SimpleXmlViewResolver/ bean idjspViewResolver classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/jsp// property namesuffix value.jsp/ property nameorder value3/ /bean这里的关键在于order属性。DispatcherServlet维护了一个有序的ViewResolver集合解析器按order从小到大逐个尝试。InternalResourceViewResolver默认的order值是Integer.MAX_VALUE意味着它排在最后。如果自定义解析器能够解析的视图名必须先返回一个View对象框架就不会继续往后找。如果返回null框架会问下一个解析器。这是整个自定义机制能正常工作的前提。3.2 自定义View的实现render方法决定一切View接口同样很简单核心是一个getContentType()和一个render()public class SimpleXmlView implements View { private String viewName; public SimpleXmlView(String viewName) { this.viewName viewName; } Override public String getContentType() { return text/xml;charsetUTF-8; } Override public void render(MapString, ? model, HttpServletRequest request, HttpServletResponse response) throws Exception { response.setContentType(getContentType()); PrintWriter writer response.getWriter(); writer.write(?xml version\1.0\ encoding\UTF-8\?); writer.write(data); for (Map.EntryString, ? entry : model.entrySet()) { writer.write( entry.getKey() ); writer.write(String.valueOf(entry.getValue())); writer.write(/ entry.getKey() ); } writer.write(/data); } }这个视图做的事情很简单把Model里的键值对直接渲染成XML片段。controller里这样返回GetMapping(/api/xml) public String xml(Model model) { model.addAttribute(status, ok); return xml:hello; }这里有个容易踩的坑render方法里的response输出如果controller里已经做了什么操作导致response被提交再调用getWriter()或者write()就会报错。还有一个经验是getContentType()一定要带charsetUTF-8不然中文全部变问号这个坑我踩过不止一次。3.3 自定义视图的经典战场Excel、PDF、JSON自定义视图最常见的应用场景是非HTML响应。现在一些项目需要导出接口如果直接用HttpServletResponse输出文件流代码会散落在controller里不好维护。推荐思路是这样的定义一个ExcelView继承Spring的AbstractXlsxView在buildExcelDocument()方法里把模型数据填充到Workbook里。然后在Spring配置里用BeanNameViewResolver搭配视图Beanbean idbeanNameViewResolver classorg.springframework.web.servlet.view.BeanNameViewResolver property nameorder value1/ /bean bean iduserExcelView classcom.example.view.UserExcelView/controller方法GetMapping(/export) public String export(Model model) { model.addAttribute(users, userService.listAll()); return userExcelView; }BeanNameViewResolver的逻辑非常简单拿着视图名去Spring容器里找同名的Bean找到了就返回这个Bean找不到就返回null。这种写法下controller不用关心Excel是怎么生成的视图名和Bean名天然对应测试和替换都很方便。对于JSON输出Spring MVC自带的MappingJackson2JsonView做了类似的事。你配置好Jackson依赖之后返回一个带有MappingJackson2JsonView的视图名就能输出JSON前提是你把处理JSON的逻辑从ResponseBody里挪出来。不过日常开发中ResponseBody和RestController已经够用了并不是所有场景都需要自定义视图来输出JSON但理解这套机制对排查奇怪问题很有帮助。3.4 自定义视图的一个隐藏细节缓存Spring的AbstractCachingViewResolver默认会对解析结果做缓存也就是说同一个视图名第一次解析之后结果会被缓存起来之后的请求直接走缓存。这在生产环境里是性能优化但在开发期就是个坑你改了JSP或者改了自定义视图类刷新页面发现不生效十有八九是ViewResolver的缓存没清。解决方式有两种。第一种开发阶段设置InternalResourceViewResolver的cache属性为falseproperty namecache valuefalse/第二种如果你用的自定义解析器继承自AbstractCachingViewResolver在实现类的构造器里调用setCache(false)。不过这种配置只建议在开发环境用线上还是要开缓存不然每次请求都解析一遍视图压力都在JVM上。4. 页面重定向redirect的完整玩法与隐藏坑4.1redirect:前缀背后的RedirectView先看最熟悉的写法PostMapping(/save) public String save() { // 保存业务数据 return redirect:/user/list; }当视图名以redirect:开头时Spring MVC会忽略那些普通视图解析器的前后缀逻辑直接创建一个RedirectView目标是/user/list然后在渲染阶段调用response.sendRedirect(/user/list)浏览器收到302响应后再发起一次GET请求。这里要理解一个关键区别redirect:不是服务器端转发而是告诉浏览器去访问另一个地址。所以重定向是两次HTTP请求第一次请求的模型数据默认不会传递到第二次请求。很多人刚接触时都会困惑——为什么redirect之后model里的数据取不到了答案就在这里新请求是浏览器发出的全新请求模型数据只存在于第一次请求的模型对象里。RedirectView本身也可以手动创建GetMapping(/go) public ModelAndView go() { RedirectView view new RedirectView(/target); view.setContextRelative(true); return new ModelAndView(view); }setContextRelative(true)表示这个路径是相对应用根路径的自动拼接应用上下文路径。这种方式比字符串更灵活但一般用字符串就够了。4.2 PRG模式与RedirectAttributes防表单重复提交的标准方案重定向最经典的应用场景是PRG模式也就是Post/Redirect/Get。一个表单POST提交之后如果处理逻辑完成时用的是forward用户按F5刷新页面浏览器会用同样的POST数据再发一次请求表单就重复提交了。而如果用PRGPOST请求响应是302浏览器自动发起GET请求刷新页面时重复的是GET请求不会造成重复提交。但PRG有个问题——怎么把操作结果提示交给下一个页面有人用URL拼接?messagesuccess丑不说参数一多还容易超长敏感数据也会暴露在地址栏里。Spring MVC为此提供了RedirectAttributesPostMapping(/save) public String save(RedirectAttributes attributes) { // 保存业务数据 attributes.addFlashAttribute(message, 保存成功); return redirect:/user/list; }在目标JSP里直接${message}就能取到。这个机制的实际载体是FlashMap。Spring MVC在请求结束时会把FlashMap保存到session中重定向产生的新请求开始时会从session读取FlashMap把它合并到当前请求的属性里然后立即清除。这意味着flash attribute只在重定向后的第一次请求里有效不会被后续请求反复读到正合“提示一次就消失”的预期。4.3 重定向的常见问题路径、编码、数据传递第一个坑是路径写错。return redirect:user/list不带前导斜杠会被解析成相对于当前URL的相对路径。比如当前请求路径是/admin/doSave最终跳转目标是/admin/user/list这通常不是你想要的。养成好习惯一律写成redirect:/user/list以斜杠开头就一定从应用根路径算起不容易出错。第二个坑是中文参数乱码。重定向时如果想在URL里带参数return redirect:/search?keyword URLEncoder.encode(keyword, StandardCharsets.UTF_8.name());直接拼字符串遇到中文和特殊字符会出问题必须做URL编码。更规范的做法是用UriComponentsBuilderUriComponentsBuilder.fromPath(/search) .queryParam(keyword, keyword) .build().encode().toUriString();第三是flash attribute丢失。有个常见场景重定向目标是外部域名或者目标Controller配置了特殊的拦截器把Attr清掉了后者少见前者比较典型。FlashMap默认只在同一应用内的重定向中生效如果你跳转到外网地址比如redirect:http://other.example.com/notifyflash attribute是传不过去的因为外网请求里没有你的session信息。5. 一条请求里的视图控制策略综合实例与选择原则5.1 一个带登录拦截和导出功能的综合场景把今天说的东西组合起来设计一个完整场景。假设系统里有一个用户列表页面要求登录后才能访问支持导出Excel登录成功后显示欢迎信息。先写拦截器处理未登录用户public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(false); if (session null || session.getAttribute(loginUser) null) { // 未登录直接转发到登录页 request.getRequestDispatcher(/WEB-INF/jsp/login.jsp).forward(request, response); return false; } return true; } }登录成功后的控制器PostMapping(/login) public String login(String username, RedirectAttributes attributes) { if (admin.equals(username)) { attributes.addFlashAttribute(welcomeMsg, 欢迎回来); return redirect:/user/list; } // 登录失败回到登录页 return forward:/login; }用户列表控制器GetMapping(/user/list) public String userList(Model model) { model.addAttribute(users, userService.findAll()); return user/list; }导出Excel的控制器配合BeanNameViewResolver和自定义视图GetMapping(/user/export) public String export(Model model) { model.addAttribute(users, userService.findAll()); return userExcelView; }这套组合里拦截器用RequestDispatcher.forward保证地址栏不变化登录失败用forward:/login回到登录页并且保留错误提示登录成功用redirect:/user/list防止表单重复提交加addFlashAttribute传递欢迎信息导出功能用自定义视图隔离渲染细节。一个简单的CRUD项目三种视图控制机制全用上了。5.2 什么时候用forward什么时候用redirect什么时候自定义视图维度forwardredirect自定义视图URL变化不变变化取决于响应类型请求次数1次2次1次数据传递request域共享需flash或URL参数模型数据直出防重复提交不支持支持不涉及跨应用跳转不支持支持不涉及最适合的场景权限拦截、页面渲染表单提交、登录成功导出、非HTML响应我的原则很简单只要不需要改变浏览器地址栏就优先用forward只要涉及表单提交、外部跳转、防重复提交就用redirect只要响应类型不是HTML页面就考虑自定义视图。反过来如果既希望地址栏不变又希望响应的是一个JSON文件那自定义视图是最干净的选择。6. 常见问题与排查技巧实录6.1 视图解析失败的三个典型现象现象可能原因排查方向404且路径明显不合理视图名带后缀或物理路径打印最终拼接URL确认prefix/suffix500抛JSP编译异常JSP语法错误或缺少taglib依赖看具体异常堆栈定位JSP行号抛Could not resolve view with name所有ViewResolver都返回了null检查解析器order、名称前缀是否匹配排查的时候我一般先在DispatcherServlet的resolveViewName附近加断点或者看日志里有没有打印视图名。Spring MVC默认日志级别看不到这些细节但把org.springframework.web的日志级别调到DEBUG视图解析过程就一目了然了。6.2 重定向相关的隐藏坑重定向后模型数据取不到是出现频率最高的问题。理解“两次请求”概念后就不奇怪了但解决方式要分情况。如果目标页面需要的数据在重定向前已经存在数据库里直接重新查询。如果只是提示消息用RedirectAttributes.addFlashAttribute。如果你确实需要在重定向后继续访问原请求的request级数据说明这个场景本质上应该用forward重新考虑跳转方式。还有一次我在项目里遇到重定向后HTTP 405原因是原始请求是POSTcontroller POST方法处理完返回redirect:/user/list但/user/list这个路径只配置了GET请求。请求是重定向成功了浏览器发起的是GET最终因为没有匹配的Handler直接405。所以重定向目标地址必须保证有对应请求方法的Handler。6.3 自定义视图不生效的排查自定义视图不生效先别急着怀疑配置写错。按顺序排查自定义ViewResolver有没有注册到容器order设置对不对视图名是否匹配到了前缀目标View的render方法是否真的执行了其中order设置不对是最隐蔽的问题——如果你没设置order自定义解析器和InternalResourceViewResolver的优先级相同都排在默认值阶段此时解析顺序就不确定很可能InternalResourceViewResolver先拿到视图名拼了一个不存在的JSP路径导致404。给你一个调试技巧在自定义ViewResolver的resolveViewName方法第一行加一行日志输出当前请求解析的视图名。如果没有输出说明这个解析器根本没被调用如果有输出但返回了null说明你的前缀匹配条件不满足。两种情况的下一步操作完全不同有日志就能快速分流。DEBUG - resolve viewName: userExcelView, resolver: BeanNameViewResolver日志里看到这种情况就去检查BeanNameViewResolver对应的Bean是否真的定义了id为userExcelView的视图类。这类问题八成是Bean命名不一致。我在实际项目中摸索出的组合拳就是默认JSP用InternalResourceViewResolver特殊响应用BeanNameViewResolver加自定义View对外跳转一律redirect加flash attribute。这套思路用顺手之后再来应对任何视图层怪问题都不慌了核心其实就一句话把ViewResolver和View当成两个可插拔的环节靠日志和order理顺它们的关系。
