server: port: 8080 spring: datasource:
url: jdbc:mysql://localhost:3306/test
spring: datasource:
url: jdbc:mysql://localhost:3306/mydb
username: admin
redis:
host: localhost
port: 6379
cluster:
nodes:
- 192.168.1.1:7001
- 192.168.1.2:7002
3.1 服务器配置属性详解
服务器配置决定了SpringBoot应用如何与外界交互。server.port是最常被修改的属性，它指定了应用监听的端口号。默认的8080端口在开发时很顺手，但生产环境可能需要改成80或443。
server.servlet.context-path为应用设置了上下文路径。比如设置为"/api"后，所有请求都要以/api开头。这个配置在微服务架构中特别有用，能避免路径冲突。
超时配置关系到系统的稳定性。server.connection-timeout控制连接超时时间，server.servlet.session.timeout管理会话超时。设置合理的超时值能防止资源被长时间占用。
我记得有个项目因为connection-timeout设置过长，导致在高并发时连接池很快耗尽。后来调整为30秒，系统稳定性明显提升。
SSL配置现在变得越来越重要。server.ssl.key-store指定证书文件路径，server.ssl.key-store-password设置证书密码。启用HTTPS能提升数据传输的安全性。
3.2 数据库连接配置详解
数据库连接是大多数应用的核心。spring.datasource.url定义了数据库的位置和名称。不同数据库的URL格式略有差异，MySQL、PostgreSQL、Oracle各有自己的写法。
连接池配置直接影响性能。spring.datasource.hikari.maximum-pool-size控制最大连接数，需要根据实际负载来调整。太小会导致请求等待，太大又会消耗过多资源。
spring.datasource.username和password是必填项。生产环境中，建议使用环境变量或配置中心来管理这些敏感信息，避免硬编码在配置文件中。
我曾经遇到一个性能问题，最后发现是连接池的minimum-idle设置过大。过多的空闲连接反而成了负担，调整后内存使用率明显下降。
事务超时和隔离级别也很关键。spring.transaction.default-timeout设置事务超时时间，spring.jpa.properties.hibernate.connection.isolation定义隔离级别。这些配置对数据一致性有重要影响。
3.3 日志配置属性详解
日志级别配置是最常用的调试工具。logging.level后面接包名或类名，可以精确控制日志输出。将关键包的级别设为DEBUG，能在不重启的情况下获取详细运行信息。
日志文件配置关系到问题排查。logging.file.name指定日志文件路径，logging.file.max-size控制单个文件大小。合理的滚动策略能避免磁盘被日志占满。
日志格式自定义让输出更易读。logging.pattern.console定义控制台输出格式，logging.pattern.file定义文件输出格式。加入时间戳、线程名等信息，调试时能快速定位问题。
日志框架的选择也很重要。SpringBoot默认使用Logback，但可以通过排除依赖来切换Log4j2。不同的日志框架在性能上各有特点，需要根据项目需求选择。
3.4 缓存配置属性详解
缓存类型选择影响系统性能。spring.cache.type支持多种缓存实现，Redis、Ehcache、Caffeine各有优势。Redis适合分布式场景，Caffeine在单机环境下性能更佳。
缓存过期策略需要仔细设计。spring.redis.timeout设置Redis连接超时，spring.cache.redis.time-to-live定义缓存存活时间。太短会导致缓存命中率低，太长又可能读到过期数据。
序列化配置影响缓存效率。spring.redis.serializer指定序列化方式，Jackson2JsonRedisSerializer能很好地处理复杂对象。选择合适的序列化器能提升性能并减少存储空间。
缓存键生成策略值得关注。默认情况下Spring使用方法的参数生成缓存键，但可以通过自定义KeyGenerator来实现更复杂的逻辑。合理的键设计能提高缓存利用率。
缓存穿透和雪崩防护不容忽视。spring.cache.redis.cache-null-values控制是否缓存空值，能有效防止缓存穿透。设置不同的过期时间可以避免缓存雪崩。
4.1 自定义配置属性与使用
@ConfigurationProperties注解让自定义配置变得优雅。在类上添加这个注解，SpringBoot会自动将配置文件中的属性绑定到类的字段上。prefix属性指定配置前缀，保持配置的清晰组织。
定义配置类时，字段名需要与配置文件中的属性名对应。Spring使用宽松的绑定规则，kebab-case、camelCase、snake_case都能正确映射。这种灵活性让配置编写更加自由。
类型安全是自定义配置的重要优势。编译器能在编码阶段发现类型错误，而不是等到运行时。配合IDE的自动补全，配置使用体验大幅提升。
我最近在一个微服务项目中使用了自定义配置。将第三方API的端点、超时时间、重试策略都封装在配置类里，代码的可读性和维护性明显改善。
属性验证通过@Validated注解实现。在配置类上添加这个注解，配合JSR-303验证注解，能确保配置值的合法性。@NotNull、@Min、@Max等注解提供了丰富的验证能力。
嵌套配置支持复杂场景。在配置类中定义内部类，配置文件使用缩进或点号分隔表示层级关系。这种结构化的配置方式特别适合管理多个相关配置项。
4.2 配置属性验证与安全性
配置验证不应该只停留在类型检查。SpringBoot支持JSR-380标准，@Email验证邮箱格式，@Pattern用正则表达式校验，@Size控制字符串长度。这些验证在应用启动时自动执行。
自定义验证器处理特殊需求。实现ConstraintValidator接口，可以创建业务特定的验证逻辑。比如验证配置文件中的时间范围是否合理，或者检查依赖配置的一致性。
配置加密保护敏感信息。使用Jasypt等工具对数据库密码、API密钥进行加密，配置文件中存储密文。应用启动时解密，避免明文配置带来的安全风险。
环境变量和系统属性提供了另一种安全配置方式。将敏感信息设置在运行环境中，而不是写在配置文件中。这种方式在容器化部署时特别常用。
配置中心集成提升安全管理。SpringCloudConfig、Nacos等配置中心支持配置的版本管理、权限控制和审计日志。大型项目中，配置中心几乎是必需品。
我记得有个项目因为配置泄露导致的安全事件。后来团队建立了配置审查机制，所有包含敏感信息的配置都要经过安全扫描，问题再没出现过。
4.3 配置热更新与动态刷新
@RefreshScope注解开启配置热更新能力。在需要动态更新的Bean上添加这个注解，配置变更时这些Bean会被重新创建。无需重启应用就能生效新配置，对线上服务特别友好。
SpringCloudBus配合ConfigServer实现集群级别的配置刷新。通过消息总线广播配置变更事件，所有服务实例同时更新。这种机制在微服务架构中保证了配置的一致性。
监听配置变更事件能实现更精细的控制。实现ApplicationListener接口，监听EnvironmentChangeEvent事件。在配置更新时执行自定义逻辑，比如重新初始化连接池。
健康检查集成确保配置更新的可靠性。在/actuator/health端点中检查配置状态，确保新配置不会导致服务异常。这种防护机制避免了配置错误引发的服务中断。
条件化配置更新减少不必要的重启。使用@ConditionalOnProperty等条件注解，只有相关配置变更时才触发Bean刷新。这种优化提升了配置更新的效率。
配置版本回滚是生产环境的必备能力。通过配置中心的管理界面，可以快速回退到之前的配置版本。这个功能在配置更新引发问题时能快速恢复服务。
动态配置在实践中确实带来了很多便利。但也需要注意，不是所有配置都适合热更新。像数据库连接池大小这样的配置，动态调整可能引发连锁反应，需要谨慎处理。
5.1 配置文件组织与管理策略
配置文件组织需要清晰的层次结构。按功能模块划分配置段，数据库配置、缓存配置、安全配置各自独立。这种模块化的组织方式让配置维护变得直观。
环境特定的配置使用profile隔离。application-dev.yml、application-prod.yml分别管理不同环境的配置项。SpringBoot根据激活的profile自动加载对应配置，避免环境间的手动修改。
配置继承减少重复定义。在application.yml中定义通用配置，各环境配置文件只覆盖差异部分。这种继承关系显著降低了配置冗余，修改通用配置时只需改动一处。
配置分组提升可读性。使用YAML的锚点和别名特性，定义配置模板并在多个地方引用。复杂的配置结构通过这种方式变得简洁明了。
外部化配置支持灵活的部署方式。将配置文件放在jar包外部的config目录，或者通过spring.config.location参数指定配置路径。这种机制让应用打包和配置管理完全解耦。
我参与过一个项目，初期配置杂乱无章。后来按业务域重新组织配置，每个团队负责自己模块的配置，协作效率明显提升。配置变更时的冲突也大幅减少。
版本控制集成配置管理。将配置文件纳入Git等版本控制系统，每次变更都有记录可追溯。配合代码审查流程，配置修改的质量得到有效保障。
5.2 配置性能优化建议
配置属性懒加载提升启动速度。使用@Lazy注解延迟初始化配置相关的Bean，避免在应用启动时加载所有配置。对于不常用的功能模块，这种优化效果特别明显。
配置缓存减少重复解析。SpringBoot内部对解析过的配置进行缓存，避免每次访问都重新解析配置文件。理解这个机制有助于避免不必要的性能损耗。
精简配置属性降低内存占用。移除不再使用的配置项，定期清理过时的配置。配置越简洁，解析和维护的成本就越低。
配置预编译加速启动过程。在构建阶段预解析配置，生成优化后的配置元数据。SpringBoot的spring-boot-configuration-processor模块支持这种优化。
避免配置循环引用。配置类之间的相互依赖可能导致初始化顺序问题，影响启动性能。保持配置依赖的单向性，让配置加载过程更加顺畅。
配置索引提升查找效率。为常用配置属性建立索引，快速定位配置定义位置。在大型项目中，这个技巧能节省不少调试时间。
配置监控发现性能瓶颈。通过SpringBootActuator的配置端点，分析配置加载的时间和内存消耗。数据驱动的优化往往更有效果。
5.3 常见配置问题排查与解决
配置优先级混淆是常见问题。SpringBoot的配置源有明确的优先级顺序，命令行参数最高，然后是系统属性、环境变量，最后是配置文件。理解这个顺序能快速定位配置冲突。
占位符解析失败经常发生。${property.name}格式的占位符需要对应的属性值存在，否则启动时会报错。检查属性名拼写和配置来源能解决大部分问题。
类型转换异常需要仔细处理。配置值的类型必须与目标字段类型兼容，字符串转数字、日期格式转换都是容易出错的场景。明确的错误信息通常能直接指向问题根源。
配置覆盖行为不符合预期。Profile特定的配置可能没有按预期覆盖通用配置，检查profile激活状态和配置加载顺序。有时候简单的配置顺序调整就能解决问题。
环境变量命名规则导致配置绑定失败。SpringBoot将环境变量名转换为小写并替换下划线，MY_CONFIG需要对应my.config属性名。这个转换规则经常被忽略。
配置验证失败阻止应用启动。@Validated注解的配置类在验证失败时会抛出异常，仔细阅读验证错误信息能快速定位问题配置项。
日志级别调整帮助诊断配置问题。将org.springframework.boot包的日志级别设为DEBUG，可以看到详细的配置加载过程。这个技巧在解决复杂配置问题时特别有用。
配置问题排查需要系统性的方法。从错误信息出发，沿着配置加载链逐步排查，大多数问题都能找到解决方案。经验积累让这个过程越来越顺畅。