上篇我们把第一个 Spring Boot 程序跑通以后很多读者私信问我说项目是能启动了但看到application.properties和application.yml这两种 Profile 写法就有点慌到底该用哪一种多环境配置怎么管理日志打印出来乱七八糟生产环境怎么落文件这篇我把 YAML 配置文件和日志配置这两块一次讲清楚内容完全围绕 Spring Boot 日常开发中最常用的姿势展开偏实操带一点踩坑经验适合刚跑完第一个 Spring Boot 程序、准备正经做项目的同学。YAML 这个东西第一眼会觉得不就是“键值对换了个缩进格式”嘛实际用起来才知道它比 properties 更贴近人的阅读习惯层级关系靠缩进表达天然适合描述对象、列表、嵌套结构。日志配置则更像一门“被低估的必修课”很多人只会在代码里写log.info直到线上排查问题才发现日志级别、滚动策略、格式规范这些没搭好排查问题要了半条命。下面我会从配置设计思路开始一步步把 YAML 的常见用法、属性绑定和日志配置的完整姿势说完。1. YAML 到底香在哪先聊几个绕不开的设计点1.1 为什么我建议用 YAML 而不是 properties很多老项目到现在还是application.properties一打开就是一堆扁平的键spring.datasource.url、spring.datasource.username、spring.datasource.password一个挨一个。这种写法不是不能用就是看久了眼睛疼特别是碰上 Redis、MQ、多数据源这种本身就有一堆子配置的场景光看前缀就要数半天。YAML 用缩进把层级关系直接画出来同样的配置在application.yml里长这样spring: datasource: url: jdbc:mysql://localhost:3306/demo username: root password: 123456 redis: host: localhost port: 6379一眼就能看出 Redis 和 DataSource 是平级URL、用户名、密码都是 DataSource 的子级。除了好看YAML 还能直接表达列表和对象比如配置一组白名单 URL 或者多个 Redis 集群节点properties 要搞下标索引YAML 一个列表就搞定app: whitelist: - /api/public - /api/health redis-cluster: - node1:6379 - node2:6379Spring Boot 从 2.4 版本开始对 YAML 的支持也做了不少调整特别是多文档配置和 Profile 激活方式整体上更推荐新项目直接以application.yml作为主配置。当然如果你只是跑个小 Demo用 properties 也没问题但既然标题叫“轻松玩转”我建议直接跨过 properties尽早习惯 YAML 的表达逻辑。1.2 YAML 里最容易坑新手的缩进与类型YAML 的语法本身不复杂最难的是“缩进”这件事。不用 Tab必须用空格而且同一层级的缩进必须一致。我见过太多新手的报错归根结底就是缩进混用了 Tab 和空格或者层级多缩进了一个空格。这种错误启动时往往会给你一段密密麻麻的解析异常看半天才反应过来是格式问题。另外一个容易被忽略的是“类型”。YAML 里port: 8080是数字port: 8080是字符串enabled: false是布尔值enabled: false是字符串。如果你把一个字符串值绑定到一个 Integer 字段上Spring Boot 的自动类型转换一般能帮你兜住但兜不住的时候就是启动报错。更典型的是日期、超时时间这类配置比如redis.timeout: 5000到底是毫秒还是秒Spring Boot 支持直接用带单位的写法spring: redis: timeout: 5s这种写法背后是 Spring Boot 的DurationUnit绑定机制它能识别ms、s、m、h等单位比裸数字直观得多。还有一点同一个层级里不要重复定义同一个 key比如上面已经写了port: 8080后面又写一个相同缩进的port: 9090很多解析器会直接报错或者只取最后一个。配置多了以后再排查这种问题真的是浪费时间所以我的习惯是尽量分层写一个 key 只出现一次。1.3 一份配置打天下多环境 Profile 的正确姿势刚跑通第一个 Spring Boot 程序的时候一般只有一个application.yml。等你开始正经做项目就会遇到开发环境、测试环境、生产环境的配置完全不一样的问题数据库地址不同、日志级别不同、第三方接口的密钥不同。Spring Boot 最朴素的多环境方案就是用application-{profile}.yml然后在application.yml里通过spring.profiles.active指定当前激活的 profile。比如# application.yml spring: profiles: active: dev# application-dev.yml server: port: 8081 logging: level: com.example: DEBUG# application-prod.yml server: port: 8080 logging: level: com.example: INFO启动的时候就能用--spring.profiles.activeprod覆盖这样同一个 jar 包在不同环境跑起来加载的就是不同的配置。Spring Boot 2.4 之后还支持在同一个application.yml里用---分隔多份文档再配合spring.config.activate.on-profile来指定生效条件server: port: 8081 --- spring: config: activate: on-profile: prod server: port: 8080这种单文件多文档方案适合配置差异不大的项目配置差异大还是建议拆成多个application-{profile}.yml查起来更直观NoSQL、消息队列那种一抄一大段的配置也不容易写错。2. 从零配置把 YAML 用出“实体类绑定”的高级感2.1 自定义属性与 ConfigurationProperties 绑定YAML 不只是放 Spring Boot 官方配置我们自己的业务配置也经常放这里。比如我做一个商城项目把支付回调地址、商品图片前缀、订单超时时间写死在代码里显然不行更好的做法是定义一组app.*开头的前缀然后用一个配置类来接收。看一段实际例子app: order: timeout: 30m prefix: /api/order storage: local-path: /data/files max-size: 100MB对应的配置类用ConfigurationProperties绑定Component ConfigurationProperties(prefix app) public class AppProperties { private Order order new Order(); private Storage storage new Storage(); // getter / setter 省略 public static class Order { private Duration timeout; private String prefix; // getter / setter } public static class Storage { private String localPath; private String maxSize; // getter / setter } }ConfigurationProperties的好处是自动绑定、类型安全、支持复杂嵌套还能通过Validated加校验注解。比如订单超时时间30m会直接被解析成Duration100MB也能转成合适的存储单位。这里有个细节Spring Boot 2.x 之后使用该注解的类如果没有被Component或ConfigurationPropertiesScan扫到是不会自动注册成 Bean 的。所以我一般在启动类上加ConfigurationPropertiesScan或者直接在配置类上标Component。Spring Boot 3.x 还支持构造绑定配合 Java 的 record 类型写起来很清爽ConfigurationProperties(prefix app) public record AppProperties(Order order, Storage storage) { public record Order(Duration timeout, String prefix) {} public record Storage(String localPath, String maxSize) {} }构造绑定最大的好处是属性字段可以定义为final对象创建完就不可变不用再担心别的地方把配置值改掉了。2.2 用 Value 还是 ConfigurationProperties我的取舍不少教程里喜欢直接用Value(${app.order.timeout})注入单个配置项这个方法在小配置里确实方便但一旦配置项多了就会很难受。首先每个字段都要写一遍注解其次字段名和 YAML key 之间没有强对应关系类型转换也比较隐式最后你是拿不到类型安全检查的key 写错了往往跑到运行期才暴露。我个人的习惯是超过两个关联属性就封装成ConfigurationProperties。比如商城项目里订单相关的超时、前缀、开关这几个属性它们本来就属于同一业务域应该收口到一个配置类里。这样在业务代码里直接注入一个对象IDE 自动补全也友好配置重构时能全局感知改动。单个零散的开关还是可以偷懒用Value但要注意默认值写法Value(${app.switch.enable:true})冒号后面的就是缺省值。还有一点是 Spring Boot 的“宽松绑定”规则。YAML 里写local-pathJava 字段写localPath也能匹配命令行里的--app.order.timeout1h也能覆盖 YAML 中的值。这就是为什么配置名最好统一用小写加中划线既符合 Spring Boot 规范环境变量映射时也少踩坑。2.3 配置加密与敏感信息处理的现实问题很多新手会把数据库密码、第三方密钥直接明文写在application-prod.yml里然后整个配置文件传进 Git 仓库。自己练习倒无所谓但一旦项目要发布或者多人协作这就是个明显的安全隐患。配置里的敏感信息最好用环境变量占位符而不是直接写死。Spring Boot 支持${}占位符写法和 Maven 有点像spring: datasource: password: ${DB_PASSWORD}部署平台把DB_PASSWORD作为环境变量注入代码库里不出现真实的密码。更严谨一点的做法是引入配置加密组件把敏感字段加密保存在配置里启动时用密钥解密。这里不展开具体工具了只想提醒一句密钥管理是单独的一块内容不要在没有明确方案的情况下自己发明加密方式容易画蛇添足。3. Spring Boot 日志配置别只会 log.info3.1 日志级别、分组与 Spring Boot 默认行为Spring Boot 默认使用 Logback 作为日志实现默认的日志级别是 INFO也就是说DEBUG和TRACE级别的日志默认不会输出。log.info(xxx)应该是我写过最多的日志语句但如果你没搞清楚日志级别的作用范围线上环境想查个问题就发现该打的日志全被 INFO 挡住了。常用的级别从低到高是TRACE、DEBUG、INFO、WARN、ERROR。设置日志级别可以直接写在 YAML 里logging: level: root: info com.example.service: debug上面的配置表示整个项目的默认级别是 INFO但com.example.service这个包下的日志输出 DEBUG 级别。这在调试局部问题时很有用比如怀疑某个 Service 里逻辑不对把它的日志单独调成 DEBUG不用整个项目乱刷屏。Spring Boot 还支持日志分组比如把一组业务包归到一个组里统一调级别logging: group: business: com.example.order,com.example.pay level: business: debugbusiness这个组在配置里可以直接当 package 用。分组的用途是把散落的多个包合并管理比一个个包写过去省事得多。3.2 把日志写到文件并滚动归档控制台输出只能满足本地调试真正上生产环境日志是一定要落文件的。Spring Boot 提供了两个基础配置logging: file: name: logs/app.log或者用logging.file.path指定目录Spring Boot 会在该目录下生成一个默认名为spring.log的文件。我建议直接指定name文件名自己掌控。如果你用的是 Spring Boot 2.2 之前的老版本配置项是logging.file和logging.path新版本虽然兼容但 IDE 里会提示 deprecated。只写文件还不够日志文件会无限增长最终把磁盘撑爆。所以生产环境必须做滚动归档。默认配置下 Spring Boot 只做了按大小滚动超过 10MB 自动切割但历史日志不会自动清理时间一长旧文件照样堆积。要精细化控制就得自定义logback-spring.xml或者logback-spring.xml的配置内容。一个可用的滚动策略示例configuration include resourceorg/springframework/boot/logging/logback/defaults.xml/ appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender filelogs/app.log/file rollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy fileNamePatternlogs/app.%d{yyyy-MM-dd}.%i.log/fileNamePattern maxFileSize10MB/maxFileSize maxHistory30/maxHistory totalSizeCap2GB/totalSizeCap /rollingPolicy encoder pattern${FILE_LOG_PATTERN}/pattern charsetUTF-8/charset /encoder /appender root levelINFO appender-ref refFILE/ /root /configuration这段配置里fileNamePattern同时按日期和大小切割每天一个目录文件单个文件超过 10MB 会生成新的%i序号文件maxHistory控制保留 30 天totalSizeCap控制所有日志文件总大小上限。${FILE_LOG_PATTERN}引用了 Spring Boot 自带的默认日志格式省去自己拼格式的麻烦。3.3 自定义 logback-spring.xml我踩过的两个坑先说第一个坑文件名必须叫logback-spring.xml不要图省事叫logback.xml。虽然叫logback.xmlLogback 也能加载但 Spring Boot 的高级功能比如springProfile、springProperty这些 XML 标签就用不了了我最早就是因为图省事直接写logback.xml结果想按环境切换日志级别时怎么都报错。第二个坑是重复输出。配置了 ConsoleAppender 又配置了 RollingFileAppender但如果不小心在root里挂了两遍同一个 Appender日志会打两份排查时很容易被混淆。我的习惯是控制在logback-spring.xml里定义好 Logger 树避免在代码里重复创建新的 Logger 实例。另外logback-spring.xml里的日志路径千万别写绝对路径。我见过有同学在本地调试时写了D:/logs/app.log部署到 Linux 服务器直接启动失败。正确做法是用相对路径比如logs/app.log或者通过application.yml里的logging.file.path传入变量再用springProperty读取springProperty scopecontext nameLOG_PATH sourcelogging.file.path defaultValuelogs/ property nameLOG_FILE value${LOG_PATH}/app.log/这样一来日志落盘路径和application.yml保持了一个入口改环境配置时不用动 XML 文件。4. 常见问题与排查速查4.1 YAML 绑不上属性 / 启动报错平时反馈最多的就是“配置读出来是 null”或者“启动直接 Failed to bind”。这类问题九成逃不过下面几个原因。第一ConfigurationProperties类没有注册成 Bean。检查启动类有没有ConfigurationPropertiesScan或者配置类上有没有Component。第二前缀写错。YAML 里的app.order.timeout对应ConfigurationProperties(prefix app)类里的order.timeout注意大小写和宽松绑定的规则app.order.timeout写成app.ordertimeout是匹配不上的。第三类型不匹配。比如 YAML 里写的是数组Java 字段却是 String。启动时日志会给出具体哪个字段转换失败顺着提示改就行。还有一个比较隐蔽的是“多模块项目里 resources 没编译进去”。我遇到过一次改完 YAML 重启结果还是老配置后来发现是构建工具把自定义配置目录排除在 classpath 之外。遇到这种灵异现象先看一下target目录里的application.yml有没有更新没有更新就说明构建配置有问题。4.2 日志不输出 / 编码乱码 / 不滚动日志不输出先检查日志级别。com.example.util的代码里打的是 DEBUG但全局是 INFO不输出是完全正常的。这种情况不要急着改代码把对应包的级别调成 DEBUG 再看。编码乱码在 Windows 上很常见。控制台乱码一般不是logback的问题而是 IDE 启动时的运行环境编码没有设成 UTF-8。日志文件乱码则要在encoder里显式指定UTF-8否则根据系统默认编码输出中文很容易出问题。日志不滚动最常见的表现是logs/app.log一直增长没有历史文件。这时候重点看fileNamePattern和rollingPolicy的配置。SizeAndTimeBasedRollingPolicy要同时设置maxFileSize和fileNamePattern里的%i缺一个都可能不触发期望的切割。4.3 从 Spring Boot 2.x 升到 3.x 要注意的配置变化升级到 Spring Boot 3.x 之后最直观的是包名从javax.*换成了jakarta.*这个不光影响代码也影响一部分配置项。比如老项目里如果配置了server.servlet.session.*相关内容要确认新版仍然兼容。Spring Boot 3 对属性绑定也更严格一些原来能容忍的_、-混写行为现在可能直接报错。另一个要注意的是spring.config.use-legacy-processing这个开关在 Spring Boot 2.4 之后就已经不建议用3.x 里彻底移除了。也就是说配置加载顺序完全按新标准走跨版本升级时最好把原来的 Profile 切换方式重新梳理一遍不要指望靠一个开关蒙混过关。日志方面Spring Boot 3 默认还是 Logback但一些自动配置的日志 Property 名称做过微调。如果之前自定义过很复杂的logback.xml升级后建议先看官方对应的迁移文档再逐个字段验证。最后再分享一个实操中的小习惯我在实际维护项目的过程中慢慢养成一个习惯把application.yml拆成主配置和 Profile 配置之后尽量在仓库里放一个application-example.yml把需要用到的占位符和环境变量都列出来但值全部留空或者写一下注释。比如数据库密码写${DB_PASSWORD}第三方回调 URL 写一个假地址。这样新同事加入项目时不需要跑来问我一堆配置怎么填复制一份改成自己的环境就能启动。日志配置也一样先在开发环境把级别调到 DEBUG把滚动策略设小一点拿本地流量验证完切割逻辑再上生产环境用真正的容量参数。配置这东西看着不起眼但越到后面越能体会到“前期多花十分钟后期少熬夜一小时”的道理。