怎么利用 Maven 的 Profile 功能实现开发、测试与生产环境的配置切换

怎么利用 Ma ven 的 Profile 功能实现开发、测试与生产环境的配置切换

Profile 必须显式用 -P 激活，IDE 不会自动读取 pom.xml 里的 activeByDefault

先说一个核心判断：指望 IDE 自动识别 pom.xml 里那个 true 标签，这事儿基本不靠谱。无论是 IntelliJ IDEA 还是 Eclipse，默认都不会去读它。你可能会疑惑，为什么本地 clean install 有时看起来“生效”了？那多半是 IDE 缓存或者上一次构建的残留物在作祟。真正可靠、放之四海而皆准的激活方式，有且只有一种：在命令行里明确指定，比如 mvn clean package -Pdev（或者 -Ptest、-Pprod）。

问题就出在 IDE 的图形化操作上。当你在 IDE 里直接点击“Ma ven → package”按钮时，它默认是不会传递任何 -P 参数的。结果就是，所有 Profile 都没被激活，${env} 这类变量成了空壳，资源过滤彻底失效。最终打出来的包，你打开 application.yml 一看，里面全是 ${db.url} 这种未被替换的占位符，应用自然无法启动。

• 必须手动配置运行参数：以 IDEA 为例，需要在 “Run Configuration” 的 “Command line” 里明确写上 clean package -Ptest。
• 别指望自动同步：IDE 的 “auto-import” 或 “always update snapshots” 功能只管依赖更新，根本不会同步 Profile 的激活状态。
• 远离隐式激活：像 （根据操作系统激活）或 （根据文件存在与否激活）这类方式，在跨 CI/CD 流水线或不同开发者机器上极容易失效，一律不建议使用。

resources 配置要分两段：先排除所有环境子目录，再单独包含当前 profile 对应目录

一个非常典型的错误是，只在 pom.xml 里配置一段 ，比如指向 src/main/resources/${env}。这会导致什么后果？像 logback-spring.xml、banner.txt 这些不属于任何环境、但应用运行必需的公共配置文件，会被全部漏掉。打出来的 jar 包一启动，直接就会因为找不到这些基础配置而报错。

正确的做法，是用两段 配置来覆盖所有资源，确保万无一失：

• 第一段（抓取公共资源）：目录指向 src/main/resources，但同时要用 排除掉 dev/*、test/*、prod/* 这些环境专属的子目录。
• 第二段（叠加环境配置）：目录指向 src/main/resources/${env}，这里不再设置任何排除规则。
• 关键一步：这两段配置都必须加上 true，否则资源文件里的 ${xxx} 占位符将得不到替换。

这样一来，打包过程就像做了一份“双层蛋糕”：底层是所有公共配置文件，上层则精准覆盖当前环境的 application.yml 等配置，两者完美融合。

Spring Boot 的 spring.profiles.active 和 Ma ven profile 是两套机制，别混着用

这一点至关重要，但恰恰最容易混淆。必须厘清：Ma ven Profile 和 Spring Boot 的 spring.profiles.active，管的是不同阶段的事。

Ma ven Profile 控制的是构建（打包）时的行为：决定哪些文件被打进最终的 jar 包，以及资源文件中的占位符被替换成什么值。而 spring.profiles.active 控制的是运行时的行为：决定 Spring Boot 应用启动时，去加载哪个 application-{profile}.yml 文件。两者职责分明，完全解耦。

典型的“翻车”现场包括：

• 在 application-prod.yml 文件里，又画蛇添足地写上 spring.profiles.active: prod。这不仅是冗余，在某些情况下还可能引发配置循环加载的问题。
• 误以为执行了 mvn clean package -Pprod 之后，应用运行时就会自动启用 prod 配置。实际上，这个命令只是把 src/main/resources/prod/ 目录下的配置文件打进了 jar 包。应用启动时，你仍然需要通过 ja va -jar app.jar --spring.profiles.active=prod 来显式激活。
• 试图在 pom.xml 里利用 Ma ven 的过滤功能，去替换 application.yml 中的 spring.profiles.active=${env}。这相当于把运行时的环境决定权提前到了构建时，让应用失去了通过启动参数动态切换环境的灵活性，是种倒退。

一个清晰的实践建议是：Ma ven Profile 只负责处理那些在构建期就必须确定的、真正的环境变量，比如数据库地址、外部 API 域名等。而 spring.profiles.active 这个开关，应该留给部署脚本、容器编排配置或者运维人员通过启动命令来控制。

filter 文件路径写错或缺失，Ma ven 默认静默失败，${} 变成 ??? 或空字符串

这是另一个“坑”点，而且因为 Ma ven 的“好脾气”而更加隐蔽。当你在 标签里引用了 src/main/filters/dev.properties，但实际上这个文件被命名成了 Dev.properties（大小写问题），或者放错了位置（比如放在了 src/filters/），Ma ven 通常不会抛出明确的错误。它只会在日志里留下一句不痛不痒的提示：Filtering skipped for file。结果就是，打包完成后，所有 ${db.url} 这样的占位符，要么原封不动，要么被替换成了空字符串甚至 ???。

• 路径必须精确： 标签内的文件路径要写全。推荐使用相对项目根目录的路径，例如：src/main/filters/${env}.properties。
• 注意默认约定与大小写：Filter 文件默认应该放在 src/main/filters/ 目录下。尤其在 Linux 系统上，文件路径是大小写敏感的，DEV.properties 和 dev.properties 会被视为两个不同的文件。
• 如何验证：最直接的检查方法是，打包后立刻去查看 target/classes/ 目录下的 application.yml 文件。如果里面的 ${} 占位符已经被替换成了具体的值，说明配置生效；如果还是原样，那么第一排查点就是 filter 文件的路径和名称。

话说回来，其实有个更稳妥、更简单的方案可以完全避免外部 filter 文件带来的麻烦：那就是跳过单独的 .properties 文件，直接在 Ma ven Profile 内部使用 标签定义变量。例如：

  dev
  
    jdbc:mysql://localhost:3306/test
  

然后在资源文件中直接引用 ${db.url} 即可。这种方式将所有配置集中管理在 pom.xml 中，没有额外的文件依赖，简单、可控，堪称优雅。