面经策

Spring MVC 中的视图解析器有什么作用？ ​

  • 标签：后端、Spring

🏛 业务架构师 ​

视图解析器（ViewResolver）的作用是把 Controller 返回的逻辑视图名解析成真正的视图对象（View）并渲染：return "order/detail" → ViewResolver 加前缀后缀（/templates/order/detail.html）→ 模板引擎（Thymeleaf/Freemarker/JSP）填充数据 → 输出 HTML。

架构师视角，我把它放在应用形态的演进里讲：

  1. 服务端渲染时代：ViewResolver 是 MVC 的半壁江山，视图解析策略（InternalResourceViewResolver、多解析器优先级、content negotiation 按 Accept 头切换 JSON/HTML）是标配知识；
  2. 前后端分离时代：@RestController 直接序列化 JSON，ViewResolver 在业务系统里基本退场，仅存于后台管理系统、邮件模板渲染、报表导出（Freemarker 生成 HTML 转 PDF 这类"非浏览器输出"场景反而是它的新用途）；
  3. 仍要懂的原因：遗留系统迁移（老门户改造为 API 服务时要拆掉这套链路）、以及内容协商机制（ContentNegotiationViewResolver）的思想在 API 版本化、多端适配中延续——"同一业务能力，多形态输出"的思路没变，载体变了。

面试我会补一句趋势：SSR 在部分 C 端场景（SEO 优先的官网、活动页）有回潮，但多由 Node/Next.js 承担——Java 服务端的定位收敛为"业务能力与数据 API 提供方"，这是技术栈分工的大势。

🏗 系统架构师 ​

作用：Handler 返回逻辑视图名 → ViewResolver 解析为具体 View（JSP/Thymeleaf/Freemarker）→ View 渲染写回响应。例如 InternalResourceViewResolver 配前后缀，把 "order/detail" 映射到 /WEB-INF/views/order/detail.jsp。

架构演进视角（我回答的主线）：

  • 它是服务端渲染时代的核心组件，承担「数据与表现分离」；前后端分离后，@ResponseBody/@RestController 路径完全绕开视图解析，直接走 HttpMessageConverter 序列化 JSON——今天多数服务里 ViewResolver 已不再配置；
  • 但它没有彻底退出：管理后台与内部工具（Thymeleaf 服务端渲染省掉前端工程）、邮件与短信模板渲染（复用同一套模板技术离线渲染文本）、PDF 报表生成（模板加数据出文档）；
  • 遗留价值在于理解渲染的抽象分层：逻辑视图名与物理视图解耦，换模板引擎只换 Resolver——这种「间接层」设计思想在所有架构分层里通用。

💻 全栈开发专家 ​

ViewResolver 把 handler 返回的逻辑视图名解析成 View 再渲染。经典配置：

java
@Bean
public ViewResolver viewResolver() {
    UrlBasedViewResolver resolver = new UrlBasedViewResolver();
    resolver.setPrefix("/WEB-INF/views/");   // "order/list" → /WEB-INF/views/order/list.jsp
    resolver.setSuffix(".jsp");
    return resolver;
}

链路：Controller 返回 ModelAndView/视图名 → DispatcherServlet 遍历 ViewResolver（多个时按 order 排序）→ View 渲染写响应。

Boot 时代：引 spring-boot-starter-thymeleaf 自动配好 ThymeleafViewResolver，模板放 resources/templates/、静态资源放 resources/static/，零配置可用。

现状要讲清楚：前后端分离项目里 ViewResolver 基本失业——@RestController 返回值走 HttpMessageConverter 直接序列化 JSON，不进视图解析。它还有生命力的场景：邮件/短信模板渲染（Thymeleaf 离线渲染 HTML）、服务端渲染的官网/管理后台、PDF 导出。所以答这题我会带上"什么时候绕过它"，体现对完整链路的认知——知道一个组件何时不用，比知道怎么用更能体现实操。