在 Spring Boot 项目中，配置管理通常会遇到一个典型场景：开发环境使用本地数据库，测试环境连接内网测试库，生产环境则指向经过调优的正式数据库。如果每次切换环境都修改 application.properties 中的地址、账号和日志级别，不仅操作繁琐，还容易把测试配置带到生产环境。Spring Boot Profiles 提供了一套轻量但强大的配置隔离机制，核心思路是保留一份通用配置，再按环境拆分配置文件，启动时通过激活项决定加载哪一份环境配置。
一、Profiles 的配置加载模型
Spring Boot 对配置文件有一套约定优于配置的加载规则。应用启动时，框架会先加载 application.properties 或 application.yml 作为基础配置，这些内容对所有环境都生效。随后，Spring Boot 会检查当前激活的 profile，并尝试加载对应的 application-{profile}.properties 或 application-{profile}.yml 文件，例如 application-dev.yml、application-prod.yml。
这种加载顺序带来了一个非常有用的特性：环境专属配置可以覆盖通用配置中的同名属性。也就是说，你可以在基础文件里定义默认端口、服务名等不变的信息，而在环境文件里只写那些会随环境变化的数据库连接、缓存地址、日志级别等内容。比如基础配置如下：
# application.yml 通用配置
server:
port: 8080
spring:
application:
name: order-service
对应的开发环境配置文件就可以只关注数据源差异：
# application-dev.yml 开发环境
spring:
datasource:
url: jdbc:mysql://192.168.1.100:3306/dev_db
username: dev_user
password: dev_pass
jpa:
hibernate:
ddl-auto: update
如果应用没有显式指定 profile，Spring Boot 会使用名为 default 的默认 profile，此时只会加载基础配置文件。你也可以通过 spring.profiles.default 设置一个默认环境，但要注意：当存在显式激活项时，默认值会被覆盖。多个 profile 可以同时激活，只需要用英文逗号分隔，例如 dev,debug，这在需要叠加调试或额外行为时非常实用。
二、激活 Profiles 的常用方式
要让应用启动时加载指定环境的配置，最直接的方式是在配置文件里写入 spring.profiles.active。这种方式适合已经确定部署环境的场景，例如测试服务器上长期使用 test 环境，就可以把激活项直接提交到配置文件中。示例：
spring:
profiles:
active: dev
但在实际部署中，很多团队希望同一个构建产物能够在不修改内部文件的情况下切换环境，这时候命令行参数和环境变量就更灵活。命令行参数拥有较高优先级，启动命令可以写成：
java -jar order-service.jar --spring.profiles.active=prod
使用环境变量同样可以激活指定 profile，而且更适合容器化部署。环境变量名需要遵循 Spring Boot 的宽松绑定规则，将点号替换为下划线并转为大写，例如：
export SPRING_PROFILES_ACTIVE=prod
在 Docker 或 Kubernetes 环境中，这一招尤其方便，因为可以在编排文件里直接注入环境变量，而不用修改镜像内容。三种方式的优先级从高到低大致为：命令行参数、环境变量、配置文件中的 spring.profiles.active。此外，测试时还可以使用 @ActiveProfiles 注解在单元测试或集成测试中指定激活的 profile，避免测试用例受到当前机器环境变量的影响。
三、@Profile 注解与条件装配
除了配置文件切换，Spring Boot 还允许在代码层面根据不同 profile 来控制 Bean 的创建。这就是 @Profile 注解的作用。它可以标注在 @Configuration 类、@Bean 方法或者任何被 Spring 管理的组件上。被标注的类或方法只有在对应 profile 处于激活状态时才会被容器加载和实例化。
举一个缓存策略的例子：开发环境希望使用简单的本地缓存，避免依赖外部 Redis；生产环境则需要接入 Redis 以保证性能和数据共享。通过 @Profile 可以非常干净地拆分两套配置：
@Configuration
public class CacheConfig {
@Bean
@Profile("dev")
public CacheManager simpleCacheManager() {
return new ConcurrentMapCacheManager("items");
}
@Bean
@Profile("prod")
public CacheManager redisCacheManager(RedisConnectionFactory factory) {
RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
.entryTtl(Duration.ofMinutes(30));
return RedisCacheManager.builder(factory)
.cacheDefaults(config)
.build();
}
}
@Profile 的表达式能力远不止单个环境名。你可以写成 @Profile({"dev", "test"}) 来表示开发或测试环境都启用，也可以使用 @Profile("!prod") 表示除了生产环境之外的所有环境。在 Spring 5.3 及以上版本中，还支持 & 和 | 操作符，例如 @Profile("dev & debug") 表示必须同时激活 dev 和 debug 两个 profile。不过在表达式里使用 & 时要注意 YAML 或 XML 文件中的转义，Java 代码中直接书写即可。
这种条件装配机制让代码更加清晰：开发者不需要在业务逻辑里写大量 if-else 判断当前环境，而是由容器在启动阶段决定哪些 Bean 被注册。这样做还能避免把生产环境的敏感配置类误加载到测试环境，降低干扰。
四、Profiles 分组管理与加载细节
当项目逐渐复杂，一个环境可能不仅要切换数据库，还要切换消息队列、文件存储、日志采集等多个组件。如果每个组件都单独定义一个 profile，激活时就需要写出一长串名称，比如 prod-db,prod-mq,prod-oss。Spring Boot 从 2.4 版本开始支持 profile 分组，允许你定义一个逻辑环境名，并在其下包含多个子 profile。配置如下：
spring:
profiles:
group:
prod:
- prod-db
- prod-mq
- prod-oss
dev:
- dev-db
- dev-mq
这样的好处是，启动时只需要激活 prod，Spring Boot 就会自动把 prod-db、prod-mq、prod-oss 一并激活，对应的 application-prod-db.yml、application-prod-mq.yml 等文件都会被加载。这样一来，运维人员看到的环境名始终保持简洁，而配置文件内部依然可以保持细粒度拆分。
除了使用多个物理文件，你还可以在同一个 YAML 文件中通过 --- 分隔多个文档块，每个文档块用 spring.config.activate.on-profile 声明自己属于哪个 profile。例如：
spring:
config:
activate:
on-profile: dev
datasource:
url: jdbc:mysql://localhost:3306/dev_db
---
spring:
config:
activate:
on-profile: prod
datasource:
url: jdbc:mysql://prod-host:3306/prod_db
这种方式适合环境差异不大、配置总量较少的项目，把所有环境放在一个文件里查看会更直观。但要注意，多文档块和独立文件可以混合使用，加载顺序依然遵循后加载覆盖先加载的原则。如果同一个属性在多个位置出现，优先级大致为：命令行参数、环境变量、当前 profile 专属文件、基础配置文件。理解这一顺序可以避免排查配置不生效时的困惑。
综合来看，Spring Boot Profiles 并不是一个复杂的概念，但它能显著提升多环境部署的规范性和安全性。建议在项目初期就规划好环境拆分策略，将敏感信息通过环境变量或外部配置中心注入，而不是直接写在 application-prod.yml 并提交到代码仓库。结合 @Profile 注解和分组管理，可以让整个配置体系既灵活又易于维护。
Spring BootProfiles多环境配置修改时间：2026-10-05 21:27:45