A. Spring Boot 外置配置文件
默认情况下，我们 spring boot 项目的配置文件<small>（application.yaml、application.properties）</small>是在项目的 jar 包『里面』的。
如果是要改配置文件中的配置项时，就需要将项目重新打包，在某些情况下，这就显得十分不方便。
对此，我们可以将 spring boot 项目的配置文件『挪到』jar 包之外，然后再启动 spring boot 项目时再指定它使用外部的这些配置文件。
根据上述的 <outputDirectory> 的配置，相关的配置文件会被复制到 target 下的 resources 目录中，并且，jar 包中也不会包含你所配置的这些配置文件。
这种情况下，在启动 spring boot 项目时，需要额外的参数（ -Dspring.config.location ）告诉它项目的配置文件在哪：
注意：
spring boot 默认是以 classpath:/,classpath:/config/,file:./,file:./config/ 这样的配置在查找、加载配置文件，有意思的是查找顺序是上述配置的反向顺序：
因此，如果你在 spring.config.location 中也定义了多个配置文件位置，例如： classpath:/custom-config/,file:./custom-config/ , 那么配置文件的查找、加载顺序同样是反向的:
另外，还有一个功能相似的配置 spring.config.additional-location ，使用它的话，它会作为默认配置路径的『 扩展配置 』路径来使用。扩展的配置路径会比默认的配置优先被扫描到. 比如说, 如果设置了扩展的配置文件所在路径为： classpath:/custom-config/,file:./custom-config/ , 那么查找路径将会是下面的顺序:
这种扫描顺序使得你可以通过自己的自定义配置来修改默认的配置项。
B. SpringBoot的配置文件有哪几种格式
SpringBoot中的配置文件来主要有三种格式，自properties、yaml、和xml方式。- 其中properties格式配置文件后缀是.properties，配置项为：server.port = 9090- yaml格式配置文件后缀是.yml，配置项是：server.port: 9090在SpringBoot中，使用最广泛的配置文件是yaml，yaml之所以流行，除了他配置语法精简之外，还因为yaml是一个跨编程语言的配置文件。在SpringBoot中，除了yaml之外，properties也比较常用，但是XML几乎不用，看得出来Spring团队非常痛恨XML配置文件！认为它不是一个好的语言。如果你对常见的配置文件有哪几种格式不熟悉，就去黑马程序员官网视频库看免费视频。
C. springboot配置文件总结
springboot 本身支持多种灵活的配置方式，为开发 springboot 程序带来了很大的灵活性和扩展性，但是同时由于太灵活，经常会导致明明配置了相关属性，却没有生效。 本文总结了 springboot 配置文件的原理以及多个配置文件生效的顺序。 springboot 配置文件支持灵活的路径，以及灵活的文件名，用一个变量表达式总结如下： 部分源码如下： 当满足上述变量表达式的配置文件有多个时，会有一个配置的优先级。假设 上面每个条件组合起来，则最多有配置文件如下，且顺序从上到下： 获取属性时，按从上到下的顺序遍历由上述文件生成的属性资源对象 PropertySource ，如果遇到匹配的key直接返回。 总结一下：就是如果同一个key的属性只出现一次，则直接取该值即可。如果同一个key的属性出现多次，则取顺序靠前的属性资源对象。另外其中每个文件都是可选的。 需要注意的一点是：如果在同一个 location 下配置了多个文件名一样的文件，则只会取一个，比如在 classpath:/ ，有如下两个文件 application.yml ： 则只会根据 classloader 的 classpath 列表，选取第一个出现的文件。因为 springboot 加载配置文件时最底层是使用的下面的方法： 这两个方法只会获取 classloader 类的 ucp 属性里面第一个匹配到的值。如果对 springboot 自身的机制不满意，想获取所有的classpath:/路径下面的 applicaiton.yml 文件，可以使用下面的方法： 本文总结了 springboot 配置文件的原理以及多个配置文件生效的顺序。如果存在增加了配置文件或者在配置文件里面增加了属性却没有生效，可以参考上面的 springboot 配置文件表达式和配置文件生效顺序进行排查。 后面还会有一篇文章讨论基于 springboot 配置原理如何实现自定义的配置读取方式。
D. Spring MVC 配置文件讲解
使用@Controller定义一个控制器 使用@RequestMapping映射请求 使用@RequestParam绑定请求参数到方法参数 使用@ModelAttribute提供一个从模型到数据的链接 使用@SessionAttributes指定存储在会话中的属性<context:annotation-config/>他的作用是隐式地向 Spring 容器注册、、、 这 4 个BeanPostProcessor。例如：如果想使用@ Resource 、@ PostConstruct、@ PreDestroy等注解就必须声明。如果想使用@PersistenceContext注解，就必须声明的Bean。如果你想使用@Autowired注解，那么就必须事先在 Spring 容器中声明 Bean。传统声明方式如下：<bean class="org.springframework.beans.factory.annotation. "/> 如果想使用 @Required的注解，就必须声明的Bean。同样，传统的声明方式如下：<bean class="org.springframework.beans.factory.annotation."/> 记得，使用注解一般都会配置扫描包路径选项<context:component-scan base-package=”XX.XX”/> <servlet> <servlet-name>dispatcherServlet</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/dispatcherServlet-servlet.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcherServlet</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping>这个配置常常见于web.xml文件中<load-on-startup>1</load-on-startup>是启动顺序，让这个Servlet随Servletp容器一起启动。 <url-pattern>*.do</url-pattern> 会拦截*.do结尾的请求。<servlet-name>dispatcherServlet</servlet-name>这个Servlet的名字是dispatcherServlet，可以有多个DispatcherServlet，是通过名字来区分的。每一个DispatcherServlet有自己的WebApplicationContext上下文对象。同时保存的ServletContext中和Request对象中，关于key，以后说明。 在DispatcherServlet的初始化过程中，框架会在web应用的 WEB-INF文件夹下寻找名为[dispatcherServlet]-servlet.xml 的配置文件，生成文件中定义的bean。<init-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/dispatcherServlet-servlet.xml</param-value> </init-param>指明了配置文件的文件名，不使用默认配置文件名，而使用springMVC.xml配置文件。其中<param-value>**.xml</param-value> 这里可以使用多种写法1、不写,使用默认值:/WEB-INF/<servlet-name>-servlet.xml2、<param-value>/WEB-INF/classes/springMVC.xml</param-value>3、<param-value>classpath*:springMVC-mvc.xml</param-value>4、多个值用逗号分隔springMVC-mvc.xml 配置文件片段讲解<context:annotation-config/><!– 自动扫描的包名 –> <context:component-scan base-package="com.iflysse"/> <!– 默认的注解映射的支持 –> <mvc:annotation-driven/><!– 视图解释类 –> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/><!–可为空,方便实现自已的依据扩展名来选择视图解释类的逻辑 –> <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" /> </bean> <mvc:annotation-driven /> 是一种简写形式，完全可以手动配置替代这种简写形式，简写形式可以让初学都快速应用默认配置方案。<mvc:annotation-driven /> 会自动注册与 两个bean,是spring MVC为@Controllers分发请求所必须的。并提供了：数据绑定支持，@NumberFormatannotation支持，@DateTimeFormat支持，@Valid支持，读写XML的支持（JAXB），读写JSON的支持（Jackson）。后面，我们处理响应ajax请求时，就使用到了对json的支持。后面，对action写JUnit单元测试时，要从spring IOC容器中取与 两个bean，来完成测试，取的时候要知道是<mvc:annotation-driven />这一句注册的这两个bean。<!– json 支持 –> <bean id="" class="org.springframework.http.converter.json."> <property name="objectMapper" ref="commonObjectMapper"/> <property name="supportedMediaTypes"> <list> <value>text/html;charset=UTF-8</value> </list> </property> </bean> <!– ObjectMapper json转换 –> <bean id="commonObjectMapper" class="cn.com.starit.util.CommonObjectMapper"/>
E. spring的xml配置文件的xml文件头详解
在spring的xml配置文件中，在头部会出现如下的东西
这些奇怪的xmlns和很长的url的作用是什么呢？
首先，介绍一下 xmlns 的作用，如下所示，一个 xml 文档中如果包含如下两种定义不同， 但是名称相同的元素， xml 解析器是无法解析的， 因为它不能确定当你调用document.getElementsByTagName(“book”) 时应该返回哪个元素。
这时候可以通过在名称增加前缀解决这个问题
由此，引入一个概念 命名空间 ，通过增加前缀表示不同的那是不同命名空间下的table，从而解决了矛盾，但是不同的人都有自己创建的不同的命名空间来描述同样的东西，不利于xml文件信息的解析，比如说，同样都是水果，可以从颜色和香味不同角度来定义成如下两种形式：
为此，w3c(万维网联盟)对于一些类型，定义了对应的命名空间和这些类型的标准，xml解释器碰到这些类型的时候就会通过这些标准去解析这类型的标签，为了确保命名空间的唯一，所以不同的命名空间的通常使用URL作为被识别的id，如下例子:
这句话的作用是当前引入了一个叫做xsi的命名空间，xsi可以在接下来要使用该命名空间时所使用的，如下:
而 http://www.w3.org/2001/XMLSchema-instance 这个很长的字符串，则是xsi这个名称空间被xml解释器内部所识别的时候所真正使用的id，但也本身只是被当做一个字符串名字去处理，xml解释器根据这个id去获取它对应的标准，从而知道这个命名空间定义有什么样的标签(xml解释器自带有一些通用的命名空间的标准)，这个字符串虽然看起来是URL，但是和对应的网页上的信息没有关系，只是用来提供命名空间 唯一性 的作用，网址有时可以被打开，上面会有关于该命名空间的信息。
所以，spring配置文件中这三句话分别表示，引入了三个命名空间。 其中第一个xmlns后面没有空间名的，表示引入了一个默认的名称空间，下文中不使用命名空间前缀的都默认使用这个命名空间，这个默认的命名空间，其真正的id是 ” http://www.springframework.org/schema/beans ” 。 引入的第二个命名空间叫做xsi，其真正的id是 ” http://www.w3.org/2001/XMLSchema-instance ” 引入的第三个命名空间叫做context，其真正的id是 ” http://www.springframework.org/schema/context ”
在最后可以看到xsi:schemaLocation，这句话的意思表示使用命名空间xsi下的schemaLocatioin，设置了它对应的值为后面很多很多的URL，schemaLocation中存储的值每两个为一组， 第一个代表命名空间，第二个代表该命名空间的标准的文件位置 ，如下所示，这句话就是说明命名空间 http://www.springframework.org/schema/beans 的标准文件是 http://www.springframework.org/schema/beans/spring-beans-3.0.xsd *
因为xml解释器不一定含有所有命名空间的标准，通过这样设置就可以告诉xml解释器不同命名空间的对应的标准是什么了，而这也是xsi这个命名空间的作用，要用到其schemaLocation。
最后，对应一般的xml解释器的工作流程中，xml解释器识别到有 “ http://www.w3.org/2001/XMLSchema-instance ” 这个通用的名称空间后，明白知道要引入一些不同命名空间，就会从其schemaLocation中获取不同命名空间和其对应的标准。
F. SpringBoot 配置文件详解（告别XML）
快速学会和掌握 SpringBoot 的 核心配置文件的使用。
SpringBoot 提供了丰富的 外部配置 ，常见的有：
其中核心配置文件我们并不陌生，主要以Key-Value的形式进行配置，其中属性Key主要分为两种：
在 application.properties 添加配置如下：
① 添加数据源信息
在 application.propertis 添加配置如下：
① 添加认证信息，其中 socks.indentity.* 是自定义的属性前缀。
② 添加随机值，其中spring.test.* 是自定义的属性前缀。
使用方法： @ConfigurationProperties(prefix = “spring.datasource”)
使用说明：提供 Setter方法 和 标记组件 Component
如何验证是否成功读取配置？答：这里可以简单做个验证，注入 MyDataSource ，使用 Debug 模式可以看到如下信息：
使用方法： @Value(“spring.datasource.*”)
使用说明：提供 Setter方法 和 标记组件 Component
注意事项：@Value不支持注入静态变量，可间接通过Setter注入来实现。
关于两者的简单功能对比：
显然，前者支持松绑定的特性更强大，所以在实际开发中建议使用@ConfigurationProperties来读取自定义属性。
SpringBoot 默认会加载这些路径加载核心配置文件，按优先级从高到低进行排列：具体规则详见 ConfigFileApplicationListener
如果存在多个配置文件，则严格按照优先级进行覆盖，最高者胜出：
举个简单的例子，例如再上述位置都有一个application.properties ，并且每个文件都写入了server.port=xx （xx分别是9001，9002，9003，9004），在启动成功之后，最终应用的端口为：9004。图例：
如果想修改默认的加载路径 或者 调改默认的配置文件名，我们可以借助命令行参数进行指定，例如：
YAML是JSON的一个超集，是一种可轻松定义层次结构的数据格式。
答： 因为配置文件这东西，结构化越早接触越规范越好。这里推荐阅读阮一峰老师写的 YAML语言教程 ，写的很简单明了。
引入依赖： 在POM文件引入 snakeyaml 的依赖。
使用说明： 直接在类路径添加 application.yml 即可。
例如下面这两段配置是完全等价的：
① 在 application.yml 配置数据源:
② 在 application.properties 配置数据源：
在项目的实际开发中，我们往往需要根据不同的环境来加载不同的配置文件。例如生产环境，测试环境和开发环境等。此时，我们可以借助 Profiles 来指定加载哪些配置文件。例如：
温馨提示：如果spring.profiles.active指定了多个配置文件，则按顺序加载，其中最后的优先级最高，也就是最后的会覆盖前者。
使用方法： 使用Maven插件打包好项目，然后在当前路径，执行DOS命令： java -jar demo.jar –server.port=8081 ，在控制台可看到应用端口变成了8081。
实现原理： 默认情况下，SpringBoot会将这些命令行参数转化成一个 Property ，并将其添加到 Environment 上下文。
温馨提示： 由于命令行参数优先级非常之高，基本高于所有常见的外部配置，所以使用的时候要谨慎。详见 PropertySource 执行顺序 。
关闭方法： 如果想禁用命令行属性，可以设置如下操作：springApplication.setAddCommandLineProperties(false)
