SpringBoot早就给出了答案Profile机制。核心思路是把不同环境的配置拆到独立文件里通过一个开关决定激活哪一套。默认的application.yml放通用配置比如应用名称、端口、日志格式。环境相关的配置分别放进application-dev.yml、application-test.yml、application-prod.yml。数据库连接、Redis地址、第三方密钥各归各的文件。激活方式有好几种按优先级从高到低命令行参数--spring.profiles.activeprodJava系统属性-Dspring.profiles.activeprod操作系统环境变量SPRING_PROFILES_ACTIVEprod最后才是配置文件里的spring.profiles.active。生产环境推荐用环境变量容器化部署时在Kubernetes的Deployment里注入改环境不用动代码也不用重新打包。Maven多模块项目里还可以结合Maven Profile做资源过滤。在pom.xml里定义不同环境的profile打包时用mvn clean package -Pprod让Maven把对应环境的配置文件复制到target/classes。这样连application-prod.yml都不用提交到代码库敏感信息留在构建服务器上。但要注意Maven资源过滤会替换...占位符和SpringBoot的${...}语法容易混淆用之前先统一约定。有些配置项在所有环境都一样只是值不同比如连接池大小、超时时间。可以放在application.yml里用占位符引用环境变量spring.datasource.url: ${DB_URL:jdbc:mysql://localhost:3306/dev}。冒号后面是默认值本地开发不设环境变量也能跑。生产环境通过环境变量覆盖既安全又灵活。代码层面Profile注解可以控制Bean的注册。比如本地开发用内存缓存生产用Redis定义两个CacheService实现分别标上Profile(dev)和Profile(prod)Spring会根据激活的Profile自动选择。Profile也支持表达式比如Profile(!prod)表示非生产环境生效。测试环境有个坑SpringBootTest默认不激活任何Profile会加载application.yml里的默认配置。如果默认配置指向本地库CI流水线跑测试就会失败。解决办法是在测试类上加ActiveProfiles(test)并确保application-test.yml存在且配置正确。配置中心是更彻底的方案。Nacos、Apollo、Spring Cloud Config把配置从代码库抽离放到远程服务器应用启动时拉取。改配置不用重新打包支持灰度发布和版本回滚。但引入配置中心也带来新的复杂度网络依赖、配置缓存、本地降级。中小项目用Profile文件足够等配置项超过几十个、环境超过三个、变更频率高了再考虑上配置中心。最后记住一条敏感信息永远不要写进application-prod.yml并提交到Git。数据库密码、API密钥、JWT签名盐全部用环境变量注入。SpringBoot的spring.datasource.password: ${DB_PASSWORD}配合K8s Secret或Docker Secret既安全又符合十二要素应用的原则。别再手动改配置文件了。把环境差异交给Profile把敏感信息交给环境变量把构建差异交给Maven Profile。人容易犯错让机器去处理这些重复劳动。