目录一.核心原理yml配置文件都可以放在哪重点1.模式A打包在java项目里面开发环境首选2.模式B放置在服务器上生产环境首选关键机制加载优先级谁覆盖谁二.SpringBoot项目的yml配置文件的加载逻辑到底用哪个三.代码实战如何在Java代码中使用yml配置文件中的数据步骤1在yml配置文件中定义数据步骤2定义配置属性类桥梁步骤3在业务代码中注入使用步骤4验证双重位置的效果四.总结与避坑指南摘要很多同学在第一次做“配置与代码分离”时最困惑的两个问题是1. 配置文件到底该打包进jar里还是扔到服务器上2. 无论放哪Java代码怎么统一读取本文基于实际项目经验严格复盘配置文件的两种存放模式及其加载优先级并总结出最稳妥的“代码读取三步走”套路助你一次性跑通配置化流程。一.核心原理yml配置文件都可以放在哪重点Spring Boot 的设计非常人性化它允许配置文件存在于两个主要位置。理解这一点你就理解了为什么开发时在 IDE 里能跑部署到服务器也能跑。1.模式A打包在java项目里面开发环境首选位置src/main/resources/目录下。场景本地开发、单元测试。特点配置文件会被直接打包进app-server-application.jar文件内部。优点方便调试代码和配置一起版本控制Git。缺点修改配置需要重新编译、重新打包、重新部署。2.模式B放置在服务器上生产环境首选位置服务器上jar 包同级目录下的config/文件夹中。场景测试环境、生产环境。特点配置文件独立于 jar 包存在不会被打包进去。优点配置与代码彻底分离。修改application-dev.yml中的黑名单或参数后只需重启服务无需重新编译打包 Java 代码。运维极其方便。结构示意/opt/app/ ├── app-server-application.jar -- 代码包不含外部配置 └── config/ -- 外部配置目录关键 ├── application.yml └── application-dev.yml -- 这里修改立即生效重启后关键机制加载优先级谁覆盖谁如果两个地方都有同名配置文件Spring Boot 听谁的 铁律外部配置 内部配置Spring Boot 启动时的加载顺序决定了服务器外部config/目录下的配置优先级最高会覆盖 jar 包内部的同名配置。开发时只有内部配置直接读取src/main/resources里的内容。部署时通常只打基础包内部可能只有默认空配置或 dev 配置然后在服务器上放一份完整的prod或dev配置在外部config/目录。结果程序启动时会自动优先读取服务器外部的文件。如果外部没找到才会回退去读jar 包内部的。这就是为什么同一套代码在本地读的是 A 配置在服务器读的是 B 配置而代码完全不需要修改的原因二.SpringBoot项目的yml配置文件的加载逻辑到底用哪个(1)解读①项目启动时肯定是先加载application.yml这个默认的配置文件。这个配置文件中明确显示了activedev也就是激活开发环境对应的那个yml配置文件对应文件名固定为application-dev.yml(即这是spring官方定义的记住这个规律就行)②再去加载application-dev.yml这个配置文件中的信息(2)总结链条为项目启动 — 加载application.yml配置文件里面明确要激活dev开发环境的配置文件 — 加载 application-dev.yml配置文件三.代码实战如何在Java代码中使用yml配置文件中的数据无论配置文件是放在src/main/resources还是服务器的config/目录下Java 代码的读取方式是完全一致的。Spring Boot 已经帮我们把加载好的数据准备好了我们只需要用一套标准的“三步走”方案把它取出来。步骤1在yml配置文件中定义数据步骤2定义配置属性类桥梁我们需要新建一个 Java 类专门用来“承接/映射”配置文件中的数据。package com.example.config; import lombok.Data; import org.springframework.boot.context.properties.ConfigurationProperties; import org.springframework.stereotype.Component; import java.util.ArrayList; import java.util.List; Data // 1. 自动生成 get/set 方法 Component // 2. 注册为 Spring Bean必须加这个才能被Autowired注入使用 ConfigurationProperties(prefix business) // 3. 【核心】指定前缀自动绑定 yml 中 business 开头的配置信息 public class BusinessConfig { // 4. 字段定义变量名需与 yml 中的 key 对应支持驼峰转换 // yml 中是 purchase-blacklist这里写 purchaseBlacklist 即可 private ListString purchaseBlacklist new ArrayList(); // 5. 【重要细节】防御性初始化new ArrayList() // 作用防止配置文件中该项为空或未配置时代码调用报空指针异常(NPE) }关键点解读ConfigurationProperties(prefix business)这是灵魂注解。它告诉 Spring“请把当前加载到的配置文件无论是内部的还是外部的里所有以business开头的数据自动填充到这个类的对应字段里”。private ListString ... new ArrayList()这是一个非常好的编程习惯。即使配置文件中没写黑名单这个列表也是空的集合而不是null后续代码直接.size()或.contains()都不会报错。步骤3在业务代码中注入使用配置类写好后就可以在任何需要校验的业务逻辑如 Service 层中使用了。Service public class OrderService { // 1. 注入刚才定义的配置类 Autowired private BusinessConfig businessConfig; public void checkUserPermission(String userId) { // 2. 直接获取黑名单列表 // 注意这里拿到的数据取决于启动时加载的是哪个配置文件 ListString blacklist businessConfig.getPurchaseBlacklist(); // 3. 业务校验逻辑 if (blacklist.contains(userId)) { throw new RuntimeException(❌ 禁止下单该用户在黑名单中); } System.out.println(✅ 校验通过当前黑名单人数 blacklist.size()); // 继续执行下单逻辑... } }步骤4验证双重位置的效果场景一本地开发你在src/main/resources/application-dev.yml写了user_001。启动 IDEA代码读到[user_001]。场景二服务器部署你打包时resources 里可能还是user_001。但在服务器上你在config/application-dev.yml里改成了user_002,user_003。启动 jar 包由于外部服务器上的的yml配置文件优先级高代码读到的是[user_002, user_003]。结论代码一行没改行为却变了这就是配置化的魅力。四.总结与避坑指南基于本次实践总结出以下核心要点供日后查阅1.位置灵活性开发期放心放在src/main/resources打包进 jar 里方便调试。运行期务必在服务器 jar 包同级建config/目录放入最终配置文件。优先级外部config/永远覆盖内部resources。2.代码套路万能公式建类加Component和ConfigurationProperties(prefix...)。定义字段类型要匹配List 对 List记得 new ArrayList()防空指针。使用Autowired注入该类直接调 getter 方法。3.核心心态不要纠结文件在哪Spring Boot 会自动按优先级加载合并。你的代码只需要关心“配置类”里的字段剩下的交给框架。结语掌握“内外两套配置外部优先”的机制配合标准的ConfigurationProperties读取方式你就掌握了 Spring Boot 配置管理的精髓。既保证了开发的便利又实现了运维的灵活这才是企业级开发的正确姿势