-Pprod打包后仍连开发库，大概率因资源过滤未开启、占位符未被Maven替换，或settings.xml中同名profile静默覆盖；需启用filtering、使用@xxx@避免双重解析，并确保profile定义在pom.xml中。
为什么 -Pprod 打包后还是连着开发库？
大概率不是 profile 没定义，而是资源过滤没开、占位符没被替换、或者 profile 被 settings.xml 里同名配置静默覆盖。Maven profile 本身不改任何文件内容，它只决定“用哪组变量去替换 ${xxx}”。如果 src/main/resources/application.properties 里写着 spring.datasource.url=${db.url}，但构建时没触发 filtering，那这个字符串就原样打进 jar —— Spring Boot 启动时自然报 Could not resolve placeholder 'db.url'。
必须同时满足三点：
true - 占位符文件（如
application.properties）在src/main/resources） - 用
mvn clean package -Pprod显式激活，别依赖activeByDefault=true—— 它极易被settings.xml里的同名 profile 覆盖
怎么避免 ${db.url} 被 Maven 和 Spring Boot 双重解析？
Maven 资源过滤阶段默认识别 ${xxx}，Spring Boot 启动时也默认解析 ${xxx}。两者撞车，要么 Maven 先替换成空，要么 Spring Boot 再次尝试解析已替换完的值，结果错乱。最稳的解法是：让 Maven 换一套占位符语法，避开 Spring Boot 的默认扫描范围。
在 pom.xml 的
<delimiters><delimiter>@</delimiter></delimiters>
然后把配置文件里的 ${db.url} 改成 @db.url@。这样 Maven 过滤时只认 @xxx@，Spring Boot 默认完全无视它，各干各的，互不干扰。
别用 $${db.url} —— Maven 3.5+ 已弃用该写法，且在某些插件组合下行为不可靠。
Profile 定义在 pom.xml 还是 settings.xml？
项目级环境配置（比如 dev/test/prod 的数据库地址、API 域名）必须定义在项目 pom.xml 的 settings.xml 是用户/全局配置，只影响仓库地址、镜像、认证等构建基础设施，不参与资源内容替换。
常见误用是把 settings.xml，然后指望它注入到 application.properties —— 不行。Maven 资源过滤只读取 pom 中激活的 profile 的 settings.xml 的
如果你真要在 settings.xml 里配 profile，只能用于控制构建行为本身（比如换私有仓库、设代理），不能用来注入运行时配置。
Spring Boot 的 application-{profile}.yml 和 Maven Profile 怎么协同？
这是两套独立机制，别混用。Spring Boot 的 spring.profiles.active=dev 控制的是启动时加载哪个 application-dev.yml；Maven Profile 控制的是打包时把哪套值塞进 application.yml（或公共 application.properties）里。
推荐做法：用 Maven Profile 管构建时变量注入（比如把不同环境的 db.url 注入到一个通用的 application.yml），再用 Spring Boot 的 profile 控制日志级别、是否启用调试端点等纯运行时开关。两者叠加用没问题，但职责要分清。
如果硬要共用 profile 名（比如都叫 prod），记得显式传参：java -jar app.jar --spring.profiles.active=prod，否则 Spring Boot 默认只认 default，不会自动继承 Maven 激活的 profile。
最容易被忽略的是：profile 的 dev，它又可能覆盖 pom 里的 —— 这类覆盖是静默的，没有警告，排查时得逐层检查 mvn help:effective-pom -Pdev 输出的实际生效配置。
