SpringMVC全自动 配置在 Spring Boot 中引入了 spring-boot-starter-web 依赖，并完成了 DispatcherServlet 的全自动 配置之后，便会通过 WebMvcAutoConfiguration 进行 Spring MVC 的全自动 配置。
与 DispatcherServletAutoConfiguration 一样，首先会在 spring-boot-autoconfigure 包中的ME TA-INF/spring.factories 配置文件中配置注册类 WebMvcAutoConfiguration,源代码如下。
#全自动 配置
org. springframework . boot . autoconfigure . EnableAutoConfiguration=
org. springframework . boot . autoconfigure . web. servlet .WebMvcAutoConfiguratio
n,
直接进入源代码，先就这样看 WebMvcAutoConfiguration 的注解部分。
@Configuration( proxyBeanMethods = false)
@Condit ionalOnWeb应用 lication(type = Type . SERVLET)
@ConditionalOnClass({ Servlet. class, DispatcherServlet.class, WebMvcConfigu
rer.class })
@ConditionalOnMissingBean(WebMvcConfigurationSupport. class)
@AutoConfigureOrder (Ordered . HIGHEST_ PRECEDENCE + 10)
@AutoConfigureAfter({ DispatcherServletAutoConfiguration. class,
TaskExecutionAutoConfiguration . class, Validat ionAutoCo
nfiguration.class })
public class WebMvcAutoConfiguration {
WebMvcAutoConfiguration 类的实例化需要满足很多条件，其中 就包含一定 先完成上节讲到的全自动 配置 DispatcherServletAutoConfiguration 的初始化。
Spring MVC 在全自动 配置中的代码较多，官方网站 文档中要点 提到了以下功能的实现。定义 ContentNegotiatingViewResolver 和 BeanName ViewResolver 的 Bean。
.对静态资源的接受 ，包括对 WebJars 的接受 。
.全自动 注册 Converter、 GenericConverter、 Formatter 的 Bean。
.对 的接受 。
.全自动 注册 MessageCodeResolver.
.对静态 index.html 的接受 。
:使用 ConfigurableWebBindingInitializer 的 Bean。
当然，在全自动 配置类中不只包括了以上的功能实现，还包括很多 功能，限于篇幅，这里就不一一-列举 了。下面会选择 几个有代表性的功能进行源代码及实例化过程的解析 。
ViewResolver 解析
这里以 ContentNegotiatingViewResolver 和 BeanNameViewResolver 的 bean 的实例化为例进行相应解析 。
ContentNegotiatingViewResolver 实例化有关 源代码如下。
@Bean
@ConditionalOnBean(ViewResolver . class)
@ConditionalOnMissingBean(name = “viewResolver” ,
value = ContentNegotiatingViewResolver . class)
public ContentNegot iatingViewResolver viewResolver(BeanFactory beanF actory)
ContentNegotiatingViewResolver resolver = new ContentNegotiatingViewResolver();
resolver . setContentNegotiationManager(
beanF actory. getBean(ContentNegot iationManager . class));
resolver. setOrder (Ordered . HIGHEST_ PRECEDENCE);
return resolver;
ContentNegotiatingViewResolver 实例化比较简单，创建对象，设置请求资源类别 管理器为ContentNegotiationManager, 并 设 置 优 先 级 。 需 要 注 意 的 是 ， 要 让ContentNegotiatingViewResolver 正 常 工 作 ， 需要设置更高的第一时间 级 ( 默觉得 Ordered.HIGHEST_ PRECEDENCE)。
ContentNegotiatingViewResolver 类实现了 ViewResolver,但它并不直接解析 视图，而是委托给很多 解析 器来完成。默认情况 ，它是从 Spring 上下文查找视图解析 器，并调用这些解析 器 。 也 可 以 在 初 始 化 该 类 时 通 过 setViewResolvers 方 法 设 置 解 析 器 属 性(viewResolvers) 。在此，默认的实例化操作中并没有对 SetViewResolvers 途径 进行设置。
BeanNameViewResolver 实例化有关 源码如下。
@Bean
@ConditionalOnBean(View. class)
@Conditiona lOnMissingBeanpublic BeanNameViewResolver beanNameViewResolver() {
BeanNameViewResolver resolver = new BeanNameViewResolver();
resolver . setOrder(Ordered. LOWEST_ PRECEDENCE- 10);
return resolver;
BeanNameViewResolver 主要通过逻辑视图名称匹配定义好的视图 Bean 对象。基本 一般 情况 下，对应的 Bean 对象需要注册到 Spring 的上下文中,BeanNameViewResolver 会返回名称匹配的视图对象。
BeanNameViewResolver 实例化的前提条件是容器中 View 实现类的 Bean 存在。
BeanNameViewResolver 的部分源码如下。
public class BeanNameViewResolver extends Web应用 licationObjectSupport imple
ments ViewResolver, Ordered {
//实现 Ordered 接口，接受 对 ViewResolver 排序， 值越小第一时间 级越高
private int order = Ordered. LOWEST_ PRECEDENCE;
@Override
@Nullable
public View resolveVi ewName (String viewName, Locale locale) throws Beans –
Exception
//获得 上下文
应用 licationContext context = obtain应用 licationContext();
//查找上下文中是否有”viewName”的 Bean 定义
if (!context . containsBean(viewName)) {
return null;
//判断”viewName”的 bean 对象是否是 View 类别
if (!context. isTypeMatch(viewName, View. class)) {
if (logger . isDebugEnabled()) {
logger. debug(“Found bean named '”+ viewName +”' but it does not i
mplement View”);
return null;
返回上下文中指定名称的 View 类别 的 Bean
return context . getBean(viewName, View. class);
BeanNameViewResolver 的 resolveViewName 途径 首先通过名称判断对应视图是否存在，当通过名称无法匹配时，会通过类别 进行视图判断，如果存在对应的 Bean,则获得 对应的View 对象并返回。
静态资源的接受
前端页面基本 需要采访 到静态资源，SpringBoot 对静态资源(比如 图片、CSS、JS 等)的接受 ， 也 包 括 对 webjars 的 支 持 ， 主 要 是 通 过 实 现 接 口 WebMvcConfigurer 的addResource-Handlers 途径 来完成的。
WebMvcConfigurer 的接口实现类为 WebMvcAutoConfiguration 的内部类，这样设计的主要目的是保证 WebMvcConfigurer 不在类路径中时不会读取 WebMvcConfigurer 的实现类。
这里的内部实现类为 WebMvcAutoConfigurationAdapter。
而人类 要讲的对静态资源的接受 就是 通过 WebMvcAutoConfigurationAdapter 实现接口WebMvcConfigurer 的 addResourceHandlers 途径 来完成的。
@Override
public void addResourceHandlers (ResourceHandlerRegistry registry) {
//如果默认资源处理器为不可用情况 则返回
if (!this . resourceProperties. isAddMappings()) {
logger . debug(“Default resource handling disabled”);
return;
Duration cachePeriod = this . resourceProperties . getCache()- getPeriod();
CacheControl cacheControl = this. resourceProperties . getCache( )
. getCachecontrol() . to();
//针对 webjars 做了固定 的判断处理
if (!registry . hasMappingForPattern(” /webjars/**”)) {
//如果不存在针对 webjars 的配置， 则在此处添加，并没置默认路径等
customizeResourceHandlerRegistrat ion(registry
. addResourceHandler(” /webjars/**”)
. addResourceLocations(“classpath:/
META-INF/resources/webjars/”)
. setCachePeriod(getSeconds (cachePe
riod))
. setCacheControl(cacheControl));
String staticPathPattern = this . mvcProperties . getStaticPathPattern();
//如果目前 的 ResourceHandlerRegistry 里面资源映射没有”/**”,则启用默认的静态资源处
理if (!registry. hasMappingForPattern(staticPathPattern)) {
customi zeResourceHandlerRegistration(
registry . addResourceHandler(staticPathPattern)
. addResourceLocations (getResourceLocations(
this. resourceProperties . getStaticLocations()))
. setCachePeriod(getSeconds( cachePeriod))
. setCacheControl(cacheControl));
以上代码中要点 进行了 webjars 资源路径和静态资源路径等默认值的初始化。首先，如果判断目前 ResourceHandlerRegistry 中不存 在“/webjars/**”,则设置 webjars 的资源路径和缓存 配 置 为 默 认 值 ; 其 次 ， 判 断 当 前 ResourceHandlerRegistry 是 否 存 在“/**”(getStaticPathPattern 方 法获得 的默认值)映射，如果不存在，则使用默认的映射路径、资源路径和缓存配置。
默 认 的 静态 资 源 映 射 路 径 在 ResourceProperties 类 中 定 义， 在 上 面 的 代 码 中是 由resourceProperties 的 getStaticLocations()途径 获得 。
ResourceProperties 中默认路径定义有关 代码如下。
@ConfigurationProperties(prefix = “spring . resources”, ignoreUnknownFields =
false)
public class ResourceProperties{
private static final String[] CLASSPATH RESOURCE_ LOCATIONS = { “classpat
h: /META- INF/resources/”,
“classpat
h:/resources/”, “classpath:/static/”, “classpath:/public/” };
private String[] staticLocations = CLASSPATH RESOURCE LOCATIONS;
至此人类 可以就这样看 出，Spring Boot 默认会加载 classpath:/META-
INF/resources/
classpath:/resources/
classpath:/static/
classpath:/public/路径下的静态资源。这是“约定”的一部分，也是为什么人类 在实践中默认会将静态资源都放置在以上路径下。
静态 index.html
当 Spring Boot 的 web 项目启动时，会找到 默认的欢迎页面。下面人类 来当 Spring Boot 的web 项目启动时，会找到 默认的欢迎页面。下面人类 来就这样看 Spring Boot 默认对静态 index.html的接受 是怎么样 实现的。该功能是在内部类 EnableWebMvcConfiguration 中通过 WelcomePageHandlerMapping来实现的。主要用来查找默认路径下的 index.html (或 index 模板)页面，并展示默认的欢迎页面，代码如下。
@Bean
public We lcomePageHandlerMapping welcomePageHandlerMapping(应用 licationConte
xt applicationContext ，
FormattingConver
sionService mvcConversionService, ResourceUrlProvider mvcResourceUrlProvide
r) {
//构造 welcomePageHandLerMapping 对象
WelcomePageHandlerMapping
we
lcomePageHandlerMapping
new
WelcomePageHand
ler-
Mapping(
new TemplateAvailabilityProviders (applicationContext), applicationConte
xt,
getWelcomePage(),
this . mvcProperties . getStaticPathPattern());
//设置拦截器
welcomePageHandlerMapping . setInterceptors(getInterceptors (mvcConversionSe
rvice, mvcResourceUrlProvider));
return welcomePageHandlerMapping;
//获得 默认查找 index. html 的路径数组
static String[] getResourceLocations (String[] staticLocations) {
String[] locations = new String[staticLocations . length
SERVLET_ _LOCATIONS. length];
System. arraycopy(staticLocations, 0, locations, 0, staticLocations. lengt
h);
System. arraycopy(SERVLET_ LOCATIONS, 0, locations, staticLocat ions . length,
SERVLET_ LOCATIONS. length);
return locations;
//遍历资源路径并拼接每一个 路径下的 index. htmL 文件，过德出可用的 index. htmL 文件
private OptionalResource getwelcomePage() {
String[] locations = getResourceLocations (
this . resourceProperties . getStaticLocations());//转换并筛选出符合条件的第一个
return Arrays . stream(locations ) . map(this: :getIndexHtml)
. filter(this: :isReadable). findFirst();
//获得 欢迎页资源的名称:路经+ index. html
private Resource getIndexHtml (String location) {
return this . resourceLoader . getResource(location + “index. html”);
关于以上代码，人类 首先就这样看 WelcomePageHandlerMapping 类, 该类本身就是为欢迎页面量身定做的，实现了抽象类 AbstractUrlHandlerMapping。该类的构造途径 接收以下 4 个参数。
-TemplateAvailabilityProviders: TemplateAvailabilityProvider 的 Bean 的集合，可用来 检查哪 些 ( 如 果 有 ) 模 板 引 擎 支 持 给 定 的 视 图 。 默 认 支 持 缓 存 响 应 ， 除 非 将spring.template .provider.cache 属性设置为 false。
:应用 licationContext:为应用软件程序 提供配置的控制接口。在应用软件程序 运行时，它是只读的，但是如果实现类接受 ，则可以从头开始 加载。
.Optional : index.html 对 应的 Resource，主要通过上述代码中的 getWelcome-Page 途径 获得 。
:String staticPathPattern:静态资源路径表示 式，默觉得 “/**”，值定义于 WebMvc- Properties中。
再简单就这样看 一下 WelcomePageHandlerMapping 类构造途径 中的业务逻辑处理源码。
final class WelcomePageHandlerMapping extends AbstractUrlHandlerMapping {
WelcomePageHandlerMapping(TemplateAvailabilityProviders templateAvailabil
ityProviders，
应用 licationContext applicationContext, Optional
Resource welcomePage,
String staticPathPattern) {
if (welcomePage . isPresent() “/**” . equals(staticPathPattern)) {
logger . info(“Adding welcome page: ”+ welcomePage .get());
setRootVi ewName(“forward: index . html”);
} else if (welcomeTemplateExists (templateAvailabilityProviders, applica
tion-
Context)) {
logger. info(“Adding welcome page template: index”);
setRootViewName(” index”) ;
WelcomePageHandlerMapping的构造途径 中处理了两个分支判断:当index.html资源存在，并且静态资源路径为“**”时，设置 RootView 的名称为“forward:index.html”。也就是说会跳转到 index.html 页面。如果不满足上述情况 ，再判断是否存在欢迎模板页面，如果存在，则设置 RootView 为 index。
另外，在获得 WelcomePageHandlerMapping 的 OptionalResource参数时，默认会在classpath:/META-INF/resources/、classpath:/resources/.classpath:/static、classpath:/public/路径 下去找到 index.htmI 作为欢迎页面。
这些路径的定义一样 位置在于 上节提到的 ResourceProperties 类中。如果有多个 index.html 文件存在于以上路径中，它们的第一时间 级根据 上面路径的顺序从高到低排列。
关于 Spring MVC 配置的有关 内容较多，以上只是针对在官方网站 文档中提到的有些 典型功能的代码实现和原理进行教学 。在学习 Spring MVC 有关 全自动 配置时，把握住一个核心思路就可以 :
对照没有使用 Spring Boot 的场景，人类 集成 MVC 需要进行哪些配置、涉 及哪些类，而Spring Boot 又是怎么样 将其全自动 配置的。
本文给各位 教学 的内容是SpringBootWeb应用源码解析 ：SpringMVC的全自动 配置下篇文章给各位 教学 的是SpringBootWeb应用源码解析 ：综合实战；觉得 文章不错的朋友可以转发此文关注小编；感谢各位 的接受 ！
