Maven Profile 如何管理多环境配置才不容易出错？
Maven Profile 适合解决“同一套项目，在不同构建场景下需要少量差异配置”的问题，比如 dev、test、prod 使用不同资源过滤值，或者 CI 构建时额外打开跳过集成测试的开关。它不适合承载所有运行时配置，更不应该把数据库密码、生产密钥直接写进 pom.xml。判断边界很简单：影响构建产物、依赖、插件行为的配置可以放 Profile；应用启动后才读取的配置，优先交给配置中心、环境变量或部署平台。
Profile 放在哪里更合适？
项目级 Profile 通常写在 pom.xml，便于团队共享，适合资源过滤、插件参数、可选依赖这类和项目强相关的内容。用户级 Profile 写在 ~/.m2/settings.xml，适合仓库、账号、个人本地路径，不建议提交到仓库。全局 Maven 配置也能写 Profile，但团队协作里很少依赖它，因为不同机器的 Maven 安装目录不一致，排查起来很费劲。
<profiles> <profile> <id>dev</id> <properties> <app.env>dev</app.env> <db.url>jdbc:mysql://localhost:3306/demo_dev</db.url> </properties> </profile> <profile> <id>prod</id> <properties> <app.env>prod</app.env> <db.url>${env.PROD_DB_URL}</db.url> </properties> </profile> </profiles>
如果要让这些属性进入资源文件，需要显式开启 filtering。踩坑最多的是以为定义了 Profile 属性，application.properties 就会自动替换；实际上没有资源过滤时，${app.env} 会原样留在文件里。
<build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build>
常见激活方式怎么选？
命令行 -Pdev 最直观，也最适合 CI/CD，因为构建脚本里能清楚看到使用了哪个环境。自动激活适合本地便利配置，比如根据 JDK 或操作系统调整插件参数，但它的代价是隐蔽：同一条命令在两台机器上可能得到不同结果。多人项目里，生产 Profile 最好显式激活，不要依赖文件存在、环境变量这种容易被忽略的条件。
mvn clean package -Pdev mvn clean package -Pdev,skip-it mvn help:active-profiles
<profile> <id>jdk17</id> <activation> <jdk>[17,)</jdk> </activation> <properties> <maven.compiler.release>17</maven.compiler.release> </properties> </profile>
实战里怎样控制边界？
Profile 最好只处理“构建时必须确定”的差异，例如资源过滤值、是否附加源码包、是否启用某个测试阶段。像连接池大小、灰度开关、第三方接口地址这类运行期变量，放在应用配置或部署系统里更合适。否则一次重新打包就可能被误认为一次配置变更，回滚时也分不清到底是代码问题还是环境值问题。团队里可以约定只有 dev、test、prod 这类环境 Profile 允许改产物内容，skip-test、local 这类辅助 Profile 只能影响本地效率，不参与正式发布。
因此，Profile 的价值不是把所有环境差异都塞进 Maven，而是让构建结果可解释、可复现。
追问
Profile 能不能直接管理生产数据库密码？
不建议，尤其不要把密码明文提交到 pom.xml。Profile 可以引用环境变量，例如 ${env.PROD_DB_URL}，但真正的密钥仍应由 CI 密文变量、部署平台或配置中心管理。这样做的取舍是本地复现稍麻烦，但换来的是仓库泄露时不会连带泄露生产凭据。边界在于 Maven 只负责构建，不应该变成运行时密钥仓库。
pom.xml 里的 Profile 和 settings.xml 里的 Profile 有什么区别？
pom.xml 更适合项目共享配置，任何开发者拉下代码都能得到一致构建规则。settings.xml 更适合个人或公司内部环境，比如私服地址、认证账号、本机路径。踩坑点是 settings.xml 不随代码提交，CI 机器如果没配置对应 Profile，本地能过、流水线会失败。一般做法是项目必需配置放 POM，机器差异配置放 settings。
多个 Profile 同时激活时谁覆盖谁？
同名属性后生效的配置可能覆盖先生效的配置，但不要把业务正确性建立在这种隐式顺序上。多个 Profile 同时改同一个属性，很容易让排查变成猜谜。更稳妥的方式是拆清职责，比如 dev 管环境，skip-it 管测试开关，避免两个 Profile 都写 db.url。如果确实要覆盖，至少用 mvn help:effective-pom 看最终结果。
为什么资源文件里的占位符没有被替换？
最常见原因是忘了给 resource 开启 <filtering>true</filtering>。另一个坑是占位符语法和框架自己的变量冲突，例如 Spring 配置里也常用 ${}，Maven 过滤可能提前替换掉本该运行时解析的值。取舍上，构建期固定的值可以过滤，运行期变化的值不要过滤。遇到问题先看打包后的 target/classes 文件，而不是只看源码。
CI/CD 里应该怎么用 Maven Profile？
CI 里推荐显式写出 mvn clean package -Pprod，不要依赖某个文件是否存在来自动激活。这样日志可追溯，回滚或复现构建时也更清楚。边界是 Profile 只决定构建差异，不应该决定部署到哪台机器；部署目标应该由流水线参数或发布系统控制。踩坑最多的是 dev Profile 被默认激活，结果生产包里混入了测试配置。