SpringBoot多环境配置实战：从基础用法到源码解析与生产避坑

SpringBoot多环境配置实战：从基础用法到源码解析与生产避坑

先讲一段我真实经历的事。去年接手一个老项目，application.properties里一大堆配置，dev环境的数据库地址和prod环境混在一起，每次发版前靠人肉注释来回切换。结果有一次同事上线前忘了改回来，生产环境用开发库跑了两小时，几万条脏数据写进去，全组加班洗数据洗到凌晨。技术群里哀嚎一片。从那以后我就特别在意多环境配置这件事——它不只是一个spring.profiles.active=dev这么简单，背后涉及配置文件加载机制、PropertySource顺序、profile组合推导，以及生产环境里那些文档根本不会告诉你的坑。

这篇文章我想把SpringBoot多环境配置这件事从基础到源码到实战避坑完整串一遍。适合正在用SpringBoot做项目、想彻底搞懂配置加载机制、或者马上要部署到生产环境但又怕配置出幺蛾子的同学。我会用自己踩过的坑作为主线，尽量把“为什么”讲透，而不是只给结论。

1. 最初的问题：为什么多环境配置不是一个开关，而是一套机制

很多人第一次接触SpringBoot多环境配置，看到的教程多半是“新建application-dev.yml、application-prod.yml，然后启动参数加一个--spring.profiles.active=prod”就完事了。这套路没错，但只覆盖了最简单的场景。当你真正维护一个中大型项目，会遇到至少这些问题：

• 一个环境不只对应一个配置文件。比如application-common.yml存公共内容，application-dev-db.yml存开发库连接，application-dev-mq.yml存开发环境的MQ地址，这些文件如何组合生效？
• profile之间如何继承和叠加？spring.profiles.include和spring.profiles.group有什么区别？
• 配置优先级到底是怎样的？application.yml、application-{profile}.yml、命令行参数、环境变量、外部配置文件，谁覆盖谁？一旦搞错优先级，生产环境很可能用了你以为没生效的配置。
• SpringBoot到底是在哪个阶段读取profile的？是在IOC容器初始化之前还是之后？如果配置加载阶段就用到了profile，那这个机制是怎么实现的？
• 生产环境怎么做到“同一个jar包，不同的运行环境自动读取不同配置”？不用改包、不用改代码、只靠外部参数控制。

最后一个问题尤其关键。一个jar包扔到服务器上，怎么知道自己是跑在测试环境还是生产环境？靠的就是profile。但profile只是“标识”，真正干活的是SpringBoot配置加载链路里对profile的处理逻辑。我们先把基础用法跑通，再往下挖原理。

2. 基础用法：SpringBoot多环境配置的标准姿势与隐藏细节

2.1 标准姿势：命名规范 + 激活方式

SpringBoot默认支持按application-{profile}.yml的命名规范来组织分环境配置。这是大家最熟悉的做法：

src/main/resources/ ├── application.yml # 公共配置 + 默认profile配置 ├── application-dev.yml # 开发环境 ├── application-test.yml # 测试环境 └── application-prod.yml # 生产环境

application.yml里可以放公共配置，比如应用名、端口默认值。也可以在这里指定默认激活的profile：

spring: application: name: order-service profiles: active: dev

但说实话，这个写在配置文件里的active: dev只适合本地开发。生产环境正确的做法是通过启动参数覆盖：

java -jar order-service.jar --spring.profiles.active=prod

或者用环境变量：

export SPRING_PROFILES_ACTIVE=prod java -jar order-service.jar

也能在部署平台的启动命令里直接加-Dspring.profiles.active=prod（针对SpringBoot 2.x以前的传统方式，实际上SPRING_PROFILES_ACTIVE环境变量映射到这个属性）。这三种方式的优先级从高到低大致是：命令行参数 > 环境变量 > 配置文件。所以写在application.yml里的active: dev，在生产环境会被启动命令里的--spring.profiles.active=prod直接干掉，这就是不用改包的关键。

2.2 很多人忽略的profile-specific文件加载细节

application-dev.yml和application.yml不是“二选一”的关系，而是“叠加”的关系。SpringBoot会同时加载application.yml和application-dev.yml，且profile-specific文件的优先级更高。也就是说，两个文件里都有的配置项，以application-dev.yml为准；只有application.yml里有的配置项，仍然生效。

这个特性非常有用。比如：

# application.yml server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/default_db username: root password: 123456

# application-dev.yml spring: datasource: url: jdbc:mysql://192.168.1.100:3306/dev_db username: dev_user password: dev_pass

激活dev之后，最终server.port=8080（继承公共），spring.datasource.url=jdbc:mysql://192.168.1.100:3306/dev_db（profile覆盖）。公共配置不会因为激活了别的profile而丢失。

但这里有个我早年吃过亏的点：如果你用了spring.config.additional-location或修改了spring.config.location，这个叠加规则会变复杂。比如设置了spring.config.location=classpath:/config/，那SpringBoot会默认忽略classpath根目录下的application.yml，只去/config/目录找。没搞清楚这个，容易出现“我配置明明写了，怎么没加载”的离奇问题。后面生产避坑部分我会专门展开。

2.3 多配置组合：profile不是只能激活一个

实际项目中单profile往往不够用。比如dev环境既要连开发库，又要连本地MQ，而test环境要连测试库和测试MQ。如果拆成application-dev.yml、application-test.yml两个文件，数据库和MQ配置全堆在里面，不同环境之间复制粘贴的配置越来越多，早晚出问题。

更好的做法是拆分维度：所有环境的数据库配置拆成application-mysql-dev.yml、application-mysql-test.yml，所有环境的MQ配置拆成application-rabbitmq-dev.yml、application-rabbitmq-test.yml，然后用组合的方式激活：

java -jar order-service.jar --spring.profiles.active=mysql-dev,rabbitmq-dev

SpringBoot完全支持多profile同时激活，用逗号分隔。这样配置的复用性、可读性都强很多。

如果你用的是SpringBoot 2.4+，还有更优雅的spring.profiles.group方式：

spring: profiles: group: dev: mysql-dev, rabbitmq-dev test: mysql-test, rabbitmq-test

这样启动时只需要--spring.profiles.active=dev，SpringBoot会自动展开成dev, mysql-dev, rabbitmq-dev三个profile。组和组员之间的加载关系、优先级关系都帮你处理好了。这是我目前在团队里主推的做法——组的概念贴近真实部署场景，而且比在启动命令里写一长串profile更不容易出错。

2.4 一个容易踩的坑：profile切换但配置没覆盖

有一种情况特别容易让人抓狂：我在application-prod.yml里把server.port改成了8081，但启动后还是8080。

排查思路是这样的：

1. 先确认profile到底有没有激活成功。可以看启动日志里The following 1 profile is active: "prod"这句话。
2. 再确认你的application-prod.yml是不是真的叫这个名字，有没有拼写错误。application-prod.yam这种低级错误我见过不止一次。
3. 确认文件位置对不对。application-prod.yml必须在classpath根目录下，或者被spring.config.location纳入搜索范围。
4. 最后一个隐蔽原因：spring.profiles.active被其他更高优先级的配置源覆盖了。比如你在application.yml里写了active: dev，又用环境变量SPRING_PROFILES_ACTIVE=prod，环境变量优先级高于配置文件，那实际生效的是prod。反过来，如果你想在环境变量里临时用dev但发现不生效，就得查是不是启动脚本里存在硬编码的--spring.profiles.active=prod参数——命令行参数优先级最高，会覆盖环境变量。

这套排查思路其实就是在脑子里过一遍配置优先级链。所以我们接下来说说SpringBoot的配置优先级体系。

3. 配置优先级体系：知道谁覆盖谁，才能避免玄学问题

SpringBoot的配置来源非常多：命令行参数、SPRING_APPLICATION_JSON、ServletConfig参数、JNDI、系统属性、操作系统环境变量、application-{profile}.yml、application.yml、@PropertySource……全部排下来有一长串。生产环境最常打交道的就这几个，按优先级从高到低：

也就是说：命令行参数能覆盖环境变量，环境变量能覆盖配置文件，profile-specific文件能覆盖公共文件。这个顺序必须牢记，排查问题时效率能翻倍。

举一个真实场景。有次生产环境某个服务端口不对，运维说他在环境变量里设了SERVER_PORT=8090，但服务起来还是8080。我让他在启动脚本里搜--server.port，果然找到一行硬编码的--server.port=8080。这就是命令行参数压过环境变量的典型案例。优先级设计是SpringBoot的底层原则，不是随便定的，理解它能省掉大量排查时间。

另外要注意，SpringBoot的配置属性是用“松散绑定”（relaxed binding）来解析环境变量的。比如spring.profiles.active这个配置项，可以用环境变量SPRING_PROFILES_ACTIVE来表达；server.port对应SERVER_PORT。因为环境变量不允许用点号，SpringBoot做了这套映射规则。如果你在代码里用@Value("${server.port}")读取，环境变量SERVER_PORT是可以命中的。但@Value读取不到环境变量里没按这个规则命名的东西，所以别在代码里瞎猜属性名，一律按SpringBoot官方文档的relaxed binding规则来。

4. 源码解析：SpringBoot启动时profile到底是怎么被处理的

基础用法玩明白了，接下来进入重头戏——源码解析。我最早也想跳过这块，觉得“能跑就行”。但直到碰到一个诡异问题：profile明明没激活，application-prod.yml却被加载了，我才不得不去翻源码。翻完之后豁然开朗，很多问题根本不用靠猜。

4.1 从SpringApplication.run()到Environment准备阶段

入口在SpringApplication.run()：

public ConfigurableApplicationContext run(String... args) { long startTime = System.nanoTime(); DefaultBootstrapContext bootstrapContext = this.createBootstrapContext(); ConfigurableApplicationContext context = null; ... // 关键步骤1：准备Environment ConfigurableEnvironment environment = prepareEnvironment(...); ... }

prepareEnvironment()里核心逻辑是：

1. 创建或获取ConfigurableEnvironment（默认是StandardServletEnvironment或StandardEnvironment）。
2. 把命令行参数、系统属性、环境变量等早期配置源添加到Environment中。
3. 触发ApplicationEnvironmentPreparedEvent事件。

private ConfigurableEnvironment prepareEnvironment(SpringApplicationRunListeners listeners, DefaultBootstrapContext bootstrapContext, ApplicationArguments applicationArguments) { ConfigurableEnvironment environment = getOrCreateEnvironment(); configureEnvironment(environment, applicationArguments.getSourceArgs()); ... // 事件发布，这是配置加载的关键 listeners.environmentPrepared(bootstrapContext, environment); ... }

注意，在触发事件之前，Environment里其实只有几个基础PropertySource，application.yml还没被加载。真正加载配置文件的是监听ApplicationEnvironmentPreparedEvent的ConfigDataEnvironmentPostProcessor。

4.2ConfigDataEnvironmentPostProcessor：配置文件加载的大管家

SpringBoot 2.4版本后，配置文件加载逻辑重构成了ConfigDataEnvironmentPostProcessor（如果你看的是2.3以前的源码，对应的是ConfigFileApplicationListener）。它干的事可以概括为：

1. 查找所有ConfigDataLocationResolver（配置数据位置解析器），确认去哪找配置文件。
2. 查找所有ConfigDataLoader（配置数据加载器），真正把文件读进来。
3. 把读到的配置数据包装成PropertySource，按顺序加入Environment的MutablePropertySources。
4. 关键一步：从早期加载的配置中解析出spring.profiles.active，然后去加载对应profile的配置文件。

这里有个设计细节值得注意：spring.profiles.active这个属性本身也是配置属性，它的来源可能是命令行参数（已经在Environment里了），也可能是application.yml里的值（还没加载）。所以ConfigDataEnvironmentPostProcessor要先做一次“临时加载”，把application.yml读进来，从里面拿到spring.profiles.active的值，再去加载application-dev.yml等profile-specific文件。加载完profile-specific文件后，还要再替换掉之前的临时PropertySource。整个阶段可以理解为“两阶段加载”：

• 第一阶段：加载基础配置文件，解析出激活的profile列表。
• 第二阶段：根据profile列表加载对应的profile配置文件，并调整PropertySource顺序。

如果profile里还嵌套了spring.profiles.include或者spring.profiles.group，就会递归触发类似逻辑，把关联的profile也加载进来。

4.3Environment接口与PropertySource的核心抽象

讲到这里，必须把几个核心接口掰开揉碎说清楚，否则看源码就是看天书。

• PropertySource<T>：最底层的配置数据单元，一个名字加一份数据源。比如CommandLinePropertySource封装命令行参数，MapPropertySource封装一个Map，ResourcePropertySource封装一个配置文件。
• PropertyResolver：配置解析器接口，提供getProperty(String key)、containsProperty(String key)、resolvePlaceholders(String text)等方法，负责从一堆PropertySource里找值。
• Environment：继承PropertyResolver，代表“当前应用运行的环境”这一抽象。在SpringBoot中，它持有MutablePropertySources（可变配置源集合），并提供getActiveProfiles()、acceptsProfiles()等与profile相关的方法。
• ConfigurableEnvironment：Environment的可配置扩展接口，额外提供了setActiveProfiles(String...)、addActiveProfile(String)、getPropertySources()等方法。
• AbstractEnvironment：ConfigurableEnvironment的抽象实现，内部维护一个MutablePropertySources propertySources字段，并在构造时默认添加系统属性和系统环境变量两个PropertySource。

看明白这层抽象，你就能理解为什么“命令行参数优先级最高”了：因为在prepareEnvironment阶段，configureEnvironment会把CommandLinePropertySource加到propertySources的第一个位置，而PropertyResolver遍历的时候是从前往后找的，先找到就先返回，于是命令行参数覆盖了后面所有配置源。抽象的排序逻辑直接决定了优先级。

4.4 关键源码走读：active profiles是如何被设置的

我们追一下ConfigDataEnvironmentPostProcessor加载profile的核心流程。简化后的逻辑类似：

class ConfigDataEnvironmentPostProcessor implements EnvironmentPostProcessor, Ordered { @Override public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) { // 1. 构建ConfigDataEnvironment ConfigDataEnvironment configDataEnvironment = new ConfigDataEnvironment(environment, application.getResourceLoader(), application.getAdditionalProfiles(), application.getEnvironmentPostProcessors()); // 2. 处理配置数据，加载配置文件并设置profiles configDataEnvironment.processAndApply(); } }

ConfigDataEnvironment里有一段核心方法processProfiles，它会把已解析出的profiles集合应用回environment。大致逻辑：

private void processProfiles(ConfigDataEnvironment environment, Profiles profiles) { // 更新Environment中的activeProfiles environment.getEnvironment().setActiveProfiles(profiles.getActiveProfiles()); // 更新defaultProfiles ... }

而profile的解析在ConfigDataEnvironmentContributors里。配置加载后，SpringBoot会把这些contributors产出的PropertySource合并，然后通过Profiles类来推导最终的profile集合。推导逻辑主要是处理spring.profiles.active、spring.profiles.default、spring.profiles.include和spring.profiles.group（2.4后新增）这些属性。

这里面最核心的关系是：只有当一个配置文件的spring.config.activate.on-profile匹配上当前活跃的profiles时，这个配置文件才会被加载。注意，我们平时写的application-dev.yml之所以能被加载，不是因为SpringBoot对文件名做了字符串匹配，而是因为SpringBoot把它当成一个带有spring.config.activate.on-profile=dev语义的配置数据。它对文件名的处理逻辑是：解析application-{profile}.yml时，提取{profile}作为该文件匹配的profile条件，然后通过Profiles的匹配机制决定是否加载。

这就是为什么如果你改了spring.config.location去指定了别的配置文件目录，SpringBoot可能会完全忽略classpath下的application-dev.yml——因为搜索路径变了，文件名匹配也变了。

我们团队里经常有人拷代码抄得飞快，但遇到“为什么我的dev配置没生效”就卡住。我建议有时间把ConfigDataEnvironmentPostProcessor、ConfigDataEnvironment、Profiles三个类通读一遍，半小时功夫，之后遇到配置疑难杂症基本都能自己定位。

4.5 为什么我推荐至少读一遍profile加载源码

真不是装逼。多环境配置的很多“玄学”问题，源码里都有明确答案：

• “为什么命令行--spring.profiles.active=prod没用？”看CommandLinePropertySource在propertySources里的顺序就知道，如果后面又有一个PropertySource塞到它前面，高优先级就被挤掉了。
• “为什么我把spring.profiles.active写在application-dev.yml里没用？”因为SpringBoot加载profile-specific文件时，spring.profiles.active可能已经被固定了，你再在profile文件里改它，优先级和时机都不对。
• “为什么spring.profiles.group里配置的include不生效？”那是SpringBoot 2.4+的API，旧源码里根本没有这个属性名，你还在用2.3的依赖跑，当然不生效。

搞懂源码，排查问题的思路就从“到处试”变成“按加载顺序推演”。

5. 生产实战：多环境配置架构设计与避坑清单

5.1 实战架构：一套代码，五种环境

我现在参与的服务采用的模式是这样的，给大家参考：

一套代码，五种环境： - local（本地开发） - dev（联调环境） - test（测试环境） - staging（预发布环境） - prod（生产环境） 配置文件按两维度拆分： - 按环境拆分：application-local.yml、application-dev.yml、... - 按模块拆分：application-db.yml、application-redis.yml、application-mq.yml、application-oss.yml

然后通过spring.profiles.group来组合：

spring: profiles: group: local: local, db-local, redis-local, mq-local, oss-local dev: dev, db-dev, redis-dev, mq-dev, oss-dev test: test, db-test, redis-test, mq-test, oss-test staging: staging, db-staging, redis-staging, mq-staging, oss-staging prod: prod, db-prod, redis-prod, mq-prod, oss-prod

这样每个配置文件的职责非常单一，改动某个中间件的连接信息不会误伤其他内容。而且新环境来了，只要复制粘贴加一组profile文件、加一行group映射，不需要动业务代码。

启动时：

# 本地 java -jar order-service.jar --spring.profiles.active=local # 生产 java -jar order-service.jar --spring.profiles.active=prod

部署平台（Nacos、K8s等）上，只需要配置好环境变量SPRING_PROFILES_ACTIVE=prod，同一个jar包到哪个环境读哪个配置。

5.2 配置外置：不要把你的数据库密码打包进jar

生产环境最重要的一条经验：敏感配置和易变配置不要打进jar包。jar包一旦构建出来，里面的application-prod.yml是静态的，改任何东西都得重新构建、重新发布。

我推荐的方式：

1. 公共非敏感配置放jar包内application.yml。
2. 环境相关的非敏感配置放jar包内application-{profile}.yml。
3. 敏感配置（密码、密钥、token）放环境变量、K8s Secret或配置中心，不要出现在任何版本控制的文件里。

SpringBoot天然支持这种方式。比如：

# application-prod.yml spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME} username: ${DB_USERNAME} password: ${DB_PASSWORD}

启动时通过环境变量注入：

export DB_HOST=10.0.0.10 export DB_PORT=3306 export DB_NAME=order_db export DB_USERNAME=prod_user export DB_PASSWORD='xxxxxx' java -jar order-service.jar --spring.profiles.active=prod

SpringBoot会通过${...}占位符解析环境变量。密码不会出现任何配置文件和git历史里，即使仓库源码泄露，数据库也相对安全。

5.3 外部配置文件优先级：spring.config.location和spring.config.additional-location

SpringBoot支持把配置文件放在jar包外面。常见做法是在jar包同级的config/目录下放一份application.yml，SpringBoot会自动优先加载外部的配置文件，规则是：

外部config目录 > 外部classpath根目录 > 内部config目录 > 内部classpath根目录

具体来说：

./config/application.yml # 优先级最高 ./application.yml # 次之 classpath:/config/application.yml # 再次 classpath:/application.yml # 默认

更精确的控制用spring.config.location（完全替换搜索路径）和spring.config.additional-location（追加搜索路径）：

java -jar order-service.jar --spring.config.additional-location=/etc/order-service/ --spring.profiles.active=prod

这样/etc/order-service/application.yml、/etc/order-service/application-prod.yml都会被加载，且优先级高于jar包内的配置文件。

这里有个大坑必须提醒：spring.config.location是替换而不是追加。如果你设置了spring.config.location=/etc/order-service/，SpringBoot就只去这个目录找配置文件，不会再看classpath下的application.yml。很多人用错这个参数，导致原本生效的配置全部失效。

正确做法是：

• 需要保留原有配置搜索路径，用spring.config.additional-location追加外部目录。
• 只有明确“我只想让服务读这个外部目录，完全不读jar包内配置”，才用spring.config.location。

5.4 生产避坑清单（每一条都是实战换来的）

我把这几年多环境配置踩过的坑整理成清单，每一条都真实导致过线上问题或长时间排查：

1. 配置文件编码问题。application.yml用UTF-8没问题，但Windows上的某些编辑器默认GBK，一旦文件里有中文注释或中文配置值，SpringBoot读取时可能出现乱码，甚至直接解析失败。建议IDE统一配置UTF-8，并且提交前检查文件编码。

2. profile名和Spring的@Profile注解不匹配。代码里@Profile("dev")的Bean，只有在dev激活时才会注册。如果启动命令里profile名写错（比如dev写成了develop），配置虽然加载了，但代码里的条件装配全部失效，可能出现“本地好的，测试环境这个Bean就是不在”的诡异问题。

3. spring.profiles.active不要写在profile-specific文件里。有人习惯在application-dev.yml里写spring.profiles.active: dev，这是错误的循环逻辑——加载application-dev.yml的前提是先知道dev被激活，而你又在它的内容里告诉SpringBoot去激活dev，这有点先有鸡还是先有蛋的意思，容易导致加载顺序出错。正确的默认profile写在application.yml里，或者干脆不写，完全靠启动参数控制。

4. spring.profiles.group只对SpringBoot 2.4+有效。如果你还在用2.3或更早版本，这个配置会被当未知属性忽略，然后部署时发现profile组不生效、一堆配置缺失。升级SpringBoot版本时尤其注意。

5. 敏感信息日志泄露。SpringBoot启动时会打印Active profile，但某些组件（比如DataSource、Redis客户端）Debug级别日志会打印完整的连接串，包括密码。生产环境务必把日志级别调到WARN以上，否则密码可能随日志一起进入日志平台。

6. Bootstrap上下文与多环境配置冲突。如果你引用了spring-cloud-starter-bootstrap或使用Spring Cloud Config，配置加载阶段会比普通SpringBoot更早，spring.cloud.config等配置不在这个时候完整加载。这时候profile的解析依然遵循同样的PropertySource优先级机制，但对配置中心的依赖会让排查变复杂。记住：Spring Cloud Config的application-{profile}.yml只是客户端配置，真正的远程配置来源优先级需要参考Spring Cloud Config的文档。

7. 多环境测试数据污染。这个不是SpringBoot的问题，而是团队习惯问题。开发环境连了生产数据库，测试环境用了线上数据，最后脏数据无处不算，出了事故又互相甩锅。在profile配置层面就要把库做隔离，DBA那边最好连账号都分开，从源头掐断。

8. 配置项删除了但代码还在读。有一次我把app.version这个配置项从application.yml里删了，但代码里还有@Value("${app.version}")，本地没报错，因为本地加载的是老配置缓存；生产启动直接报IllegalArgumentException: Could not resolve placeholder 'app.version'。排查后才知道这个问题。建议上线前统一搜一遍@Value引用和配置文件字段，确保没有悬空引用。

9. 外部配置文件权限。/etc/order-service/目录如果权限过于宽松，任何人能读密码；如果权限过于严格，服务启动时报读取失败。我一般建议chown -R appuser:appuser /etc/order-service，权限设750，只允许服务账号读写。

5.5 一个真实事故复盘：spring.config.location导致的全环境配置丢失

把这个放到最后讲，因为它是我认为最值得复盘的坑。

那是一个微服务改造项目，团队想把配置全部外置到/data/config目录，方便运维统一管理。有人图省事，直接在启动脚本里写：

java -jar order-service.jar --spring.config.location=/data/config/ --spring.profiles.active=prod

结果上线后，所有服务都起不来了，报错是找不到数据源。排查发现，spring.config.location=/data/config/把SpringBoot默认的classpath搜索路径完全替换掉了，application.yml（打包在jar内部）根本没被加载，/data/config目录下又只有一个application-prod.yml，公共配置全部丢失。

更隐蔽的是，/data/config/application.yml当时是不存在的，但SpringBoot启动时对缺失的配置位置只打一个Debug日志，不会报错，看起来就像“启动成功了但配置不对”。等你发现时，服务已经因为数据源无法初始化而失败。

正确改法是：

java -jar order-service.jar --spring.config.additional-location=/data/config/ --spring.profiles.active=prod

一条命令之差，效果完全不同。

复盘下来，我的建议是：能不动spring.config.location就不要动，优先用spring.config.additional-location。如果一定要替换默认搜索路径，请先在测试环境完整验证加载顺序和处理缺失配置的行为，不要直接上生产。

5.6 多环境切换的工具链建议

除了SpringBoot本身，生产运维层面有些配套工具能让多环境切换更可控：

• Maven/Gradle的profile和SpringBoot profile联动：构建时通过Maven profile设置资源过滤，但不建议把构建期profile和运行期profile强绑定。更推荐“一次构建、多次部署”，也就是构建时不区分环境，运行时通过参数注入。这样同一个jar包可以在测试环境验证后原封不动发布到生产，避免“测试环境验证的是A版本，生产部署的是B版本”的尴尬。

• 配置中心：配置多了以后，可以考虑引入Nacos或Spring Cloud Config集中管理。这能解决“配置文件难审计、改错难回滚”的问题，但也带来了新的学习成本和运维复杂度。真要引入，先从非敏感配置试水，不要一上来就把数据库密码全部迁过去。

• 部署脚本模板化：我们团队在每个服务目录下维护一个deploy.sh，里面把profile写死为prod或test，配合环境变量注入敏感信息。人工误操作的概率大幅降低。建议所有环境切换操作都通过脚本执行，不要人肉敲命令。

6. 最后说点实在的

我特别想强调一点，多环境配置这件事，真正难的不是语法，而是配置加载时序和优先级的心智模型。你一旦掌握了PropertySource顺序、ConfigDataEnvironment两阶段加载、spring.profiles.group展开机制，以后遇到任何配置失效问题，都能按图索骥，而不是靠“重启试试”碰运气。

这些年我的体会就是：多环境配置的架构设计，其实是在为团队减少“环境差异”带来的认知负担。一套代码跑遍所有环境，靠的是清晰的配置文件拆分和严格的启动参数规范。如果你现在还在用“注释法”切环境，真心建议花一下午时间改成spring.profiles.group的组合方案——长期收益远超那一下午的成本。

最后再分享一个小技巧：调试配置问题时，可以在启动命令里加--debug，SpringBoot会打印自动配置报告，里面会标明哪些配置类生效、哪些条件不匹配；配合看ConfigDataEnvironmentPostProcessor的日志，说是“配置问题福尔摩斯”也不过分。希望这篇实战总结能帮你在多环境配置这条路上少踩几个坑。