Maven 的 是实现多环境配置的核心机制,通过命令行(-P)或 IDE 显式激活,结合 resource filtering 与 spring.profiles.active 实现配置文件切换,需避免自动激活、跨模块继承误用及敏感信息硬编码。
环境配置">
在 Maven 的 pom.xml 中, 是实现多环境配置的核心机制,它允许你为不同环境(如开发、测试、生产)定义差异化的构建行为——比如不同的依赖、插件配置、资源过滤、属性值等。关键不在于“写几个 profile”,而在于**如何激活它们并让配置真正生效**。
profile 的基本结构和作用范围
每个 可以定义独立的:
- :供 ${xxx} 占位符引用的变量(如数据库 URL、日志级别)
- :按环境引入/排除特定依赖(如 H2 数据库只在 dev 用)
- 下的 和 :控制资源拷贝、打包逻辑、参数注入等
- :决定 profile 在什么条件下自动启用(可选)
常用激活方式(推荐显式指定)
避免依赖自动激活带来的不确定性,建议通过命令行或 IDE 显式激活:
- 命令行指定:mvn clean package -Pdev 或 mvn clean package -Ptest,with-docker(支持多个,逗号分隔)
- IDEA 中设置:在 Maven 工具窗口的 Profiles 区勾选,或运行配置里填入 -Pprod
- 默认激活(慎用): —— 仅适合本地开发默认环境,上线前务必禁用
配合 resource filtering 实现配置文件切换
这是最典型的多环境实践:把不同环境的配置(如 application.yml)放在对应目录,用 profile 控制哪个被拷贝进最终 jar:
- 目录结构示例:
src/main/resources/
├──application.yml(通用基础配置)
├──application-dev.yml
├──application-test.yml
└──application-prod.yml - 在 profile 中启用资源过滤并指定目标路径:
src/main/resources
true
- 再结合 Maven 属性 + Spring Boot 的
spring.profiles.active,启动时自动加载对应配置
避免常见坑
profile 不会跨模块自动继承:父 pom 定义的 profile,子模块不会自动拥有,需显式声明或使用 管理
属性覆盖有顺序:命令行 -Dxxx=yyy > profile 中 > pom 根节点
不要在 profile 里改 或 :这违反 Maven 坐标唯一性,会导致依赖解析失败
敏感信息别硬编码在 pom 中:密码、密钥等应通过外部 settings.xml 或 CI 环境变量注入
基本上就这些。profile 本身不复杂,但容易忽略激活时机和资源过滤的配合。用好它,一套代码打三套环境,不费劲。









