我记得特别清楚去年做一个跨境电商后台项目开发环境跑得好好的接口一部署到测试服务器就报数据库连接超时。查了半天问题就出在配置文件里写死的localhost:3306上。那时候团队还在用改完配置文件再注释回来的原始方式每次发版都像拆盲盒。后来老老实实把Spring Boot的多环境配置捋清楚用profile机制把开发、测试、生产的环境彻底拆开这类问题才算根治。这篇文章就把我实际项目里的完整拆解、配置方式和踩坑记录分享出来给同样被环境问题折磨的朋友一个能直接抄作业的参考。1. 为什么每套环境都必须独立配置从一次发版事故说起很多刚接触Spring Boot的朋友会想不就改个数据库地址吗至于搞那么复杂说实话项目小的时候确实不至于但当你同时维护开发、测试、预发、生产四套环境并且团队里有三四个人在改同一份配置的时候复杂度会迅速失控。我第一次意识到必须做多环境隔离就是因为那次数据库连接串事故。那天我们准备发测试版测试环境的数据库在另一台机器上。同事A把application.yml里的数据库地址改成了测试库联调完成后忘记改回来同事B接着在这个文件上加了两个新的MQ配置顺手提交了同事C拉代码启动本地服务发现数据库连不上以为是密码错了又改了一版密码提交上去。等真正发测试环境的时候谁都不知道这份配置最终是什么状态结果就是线上环境拿着开发库的地址去连测试库业务直接瘫痪。这个事故的根子在于所有人共用一份配置却要适配不同环境。Spring Boot的profile机制就是专门解决这个痛点的。它的核心思路很简单——把配置按环境拆成多个文件通过激活不同的profile来让应用加载对应文件公共的部分放在主配置文件里各环境特有的部分放在各自的文件里互不干扰。从那之后我定了条规矩任何项目落地第一天就必须把dev和prod两个基础profile建好哪怕两个环境目前没有任何差异也要把空文件建出来摆在项目里。这样做一方面是从一开始就建立环境隔离的意识另一方面是等后面接配置中心或者上容器编排时不需要再回头大改代码。这个习惯帮我省了太多事。2. Profile文件命名与加载规则一套严谨的覆盖优先级Spring Boot的profile机制本质上是一套文件拆分加覆盖合并的规则。理解这套规则比死记几个配置项重要得多因为它决定了你的配置最终会以什么状态生效。2.1 三种文件名和各自的用途Spring Boot的配置文件遵循一套非常清晰的命名体系。在没有额外指定spring.config.name的情况下框架会默认加载application开头的配置文件并基于激活的profile自动寻找对应的环境文件application.yml主配置文件存放所有公共配置各环境共享的内容都放这里。application-dev.yml开发环境配置存放开发期特有的内容比如本机数据库地址、调试日志级别、关闭缓存等。application-prod.yml生产环境配置存放生产特有的内容比如数据库地址、密钥、消息队列地址、开启缓存等。除了ymlproperties也是完全支持的两种格式可以混用但我个人不太建议混用。一旦项目决定用yml就尽量全项目统一用yml因为properties里没有层级结构相同前缀的配置项得反复写前缀比如spring.datasource.urlxxx和spring.datasource.usernamexxx写着累看起来也费劲。YAML天然的缩进层级省掉了一半重复的前缀改起来也直观得多。2.2 加载顺序和覆盖规则当应用启动时如果激活的profile是devSpring Boot会同时加载application.yml和application-dev.yml。具体规则是主配置文件先加载然后环境配置文件覆盖主文件中的同名配置项。这个后加载覆盖先加载的顺序非常关键。也就是说application.yml里配置的数据库地址是localhost:3306application-dev.yml里配置的数据库地址是192.168.1.10:3306激活dev后生效的地址就是192.168.1.10:3306。这个设计初看有点反直觉但恰恰很巧妙。主配置文件负责提供一套默认值环境文件只需要写各环境有差异的部分不需要重复写所有配置。这跟你日常填表很像先填一张通用信息表然后各分点根据自己的情况补充修正通用表里没改动的部分保持原样。需要特别注意的一点是覆盖的单位是配置项不是整个文件。application-dev.yml里没有写的配置项会继续沿用application.yml里的值。所以主配置文件里最好只放各环境完全一致的公共内容比如应用名spring.application.name、HTTP端口如果统一就用它、编码格式等凡是环境间可能不同的内容即使当前恰好一致也建议优先放到环境配置文件里避免以后改环境配置时误伤了公共文件。3. 激活Profile的四种主流姿势从启动参数到环境变量配置文件拆好了接下来面临的问题就是怎么让应用知道当前该激活哪个profile这一步选错了姿势后面部署的时候会非常痛苦。下面这四种方式是我实际用下来比较可靠的按适用场景从小到大排序。3.1 在application.yml里配置默认值spring: profiles: active: dev这种方式最直接也是很多人入门时最先接触到的。在application.yml里写了spring.profiles.active: dev应用启动时就会激活dev。但这里有个明显的问题如果把dev写死在主配置文件里生产环境打包时也默认激活dev那不是又回到最初的老路了吗所以我的建议是这里适合填默认值但生产部署时一定要用启动参数或环境变量覆盖掉它让默认值只服务于本地开发。3.2 启动命令行参数这是我在测试和生产环境最推荐的方式没有之一。启动服务的时候直接加一个--spring.profiles.activeprodjava -jar app.jar --spring.profiles.activeprod也可以带上其他参数java -jar app.jar --spring.profiles.activeprod --spring.datasource.password${DB_PASSWORD}关键点在于命令行参数的优先级高于application.yml里的默认值。Spring Boot的外部化配置机制里命令行参数的优先级是最高的除非你用SpringApplication.setAddCommandLineProperties(false)主动关闭这个特性否则它一定能覆盖配置文件里的值。这也意味着你完全可以把application.yml里的默认值设置成dev只要部署的时候带上--spring.profiles.activeprod生产环境跑的就是生产配置不用改任何文件。3.3 环境变量在容器化部署场景下环境变量的方式更优雅。早期的docker部署大家经常把启动命令写死在Dockerfile里或者用脚本包一层现在用Kubernetes这类容器编排工具直接在部署清单里注入环境变量就行env: - name: SPRING_PROFILES_ACTIVE value: prodSpring Boot有一个宽松绑定Relaxed Binding的约定SPRING_PROFILES_ACTIVE会自动映射到spring.profiles.active不需要写额外的代码去做环境变量读取。这个特性在云原生部署场景里非常实用配置随环境变量走镜像永远不区分环境哪个环境需要什么配置由部署平台注入就行。3.4 打包时指定Profile还有一种常见做法是在Maven打包时指定profile这通常需要pom.xml里的配合profiles profile idprod/id properties activatedPropertiesprod/activatedProperties /properties /profile profile iddev/id properties activatedPropertiesdev/activatedProperties /properties /profile /profiles然后在application.yml里引用这个Maven属性spring: profiles: active: activatedProperties打包的时候执行mvn clean package -PprodMaven会把activatedProperties替换成prod这样打出来的jar默认激活的就是生产环境。这个方式的优点是配置文件里不写死环境缺点是maven打包时必须记得带-P参数一旦忘记默认值可能会带到线上。我个人的习惯是仅在交付给客户的离线安装包场景用这个方案自己维护的在线服务一律用命令行参数或环境变量。4. 从配置分离到代码解耦Profile注解与条件装配多环境配置做到这里文件的维度已经分开了。但有时候环境差异不只是数据库地址不同这么简单。有些Bean在开发环境需要注册生产环境却不该注册有些逻辑在测试环境要模拟调用生产环境必须走真实链路。这些就不是配置文件能完全解决的了需要在代码层面做环境感知。4.1 Profile注解控制Bean的注册Spring从3.1开始提供了Profile注解可以直接标注在Configuration类或Component上只有激活的profile匹配时这个Bean才会被注册。理论上Profile可以标注在任意带有Component或其派生注解的类上我亲测过Service、Repository等注解也都支持但要注意它标注在Configuration类上时是按整个配置类生效的。举个实际案例。我们有套商户系统开发阶段要对接第三方支付的沙箱环境生产要对接正式环境。两种环境的签名逻辑、回调地址都不一样但接口定义是一致的。这时候最简单的方式就是定义两个配置类Configuration Profile(dev) public class SandboxPayConfig { Bean public PayClient payClient() { return new SandboxPayClient(); } } Configuration Profile(prod) public class ProductionPayConfig { Bean public PayClient payClient() { return new ProductionPayClient(); } }开发环境启动Spring容器里注册的是SandboxPayClient生产环境启动注册的自动换成ProductionPayClient。调用方完全不需要感知当前跑在哪个环境只管注入PayClient接口就行。这种接口抽象加环境分装的思路在对接各类第三方服务时尤其好用——环境差异被隔离在配置层业务代码保持纯净。4.2 动态判断环境的第一种方式注入Environment如果只是想在代码里读取当前激活的profile最直接的方式是注入EnvironmentService public class OrderService { Autowired private Environment environment; public boolean isProduction() { return environment.acceptsProfiles(Profiles.of(prod)); } }environment.acceptsProfiles(Profiles.of(prod))从Spring 5.3开始是官方推荐写法旧版的environment.acceptsProfiles(prod)在Spring 6里已经被移除了用新写法可以少踩一个升级坑。不过说实话这种硬编码判断环境的写法我只建议在调试辅助功能里用比如打印当前环境标识之类的正经业务逻辑里频繁判断环境往往说明抽象没做好。4.3 动态判断环境的第二种方式${spring.profiles.active}占位符还有一类场景适合用占位符方式。比如有些中间件的管理后台地址需要根据环境动态拼接monitor: base-url: http://monitor-${spring.profiles.active}.internal.company.com这个表达式在dev环境会解析成http://monitor-dev.internal.company.com在prod环境就变成http://monitor-prod.internal.company.com。用Spring的${}占位符机制就可以做到。注意这里尽管spring.profiles.active是一个列表但占位符拼接场景下默认会取列表里的第一个元素多profile同时激活时可能有点小意外目前实际项目用这种方式时我基本只激活单个profile。5. 多Profile分组与多环境覆盖顺序spring.profiles.group的进阶玩法Spring Boot 2.4之后配置文件机制有一个比较大的调整引入了spring.profiles.group的概念。这个特性对于大型项目来说非常有用它让一组profile可以被一次激活而不是只能单个激活。5.1 用法示例假设你的项目有这样一个场景测试环境需要同时具备test、localdb、debug这几个特性但不一定每个环境都需要同时具备。传统做法是启动时写多个profilejava -jar app.jar --spring.profiles.activetest,localdb,debug写起来有点长而且容易漏。有了spring.profiles.group可以在主配置文件里定义组合关系spring: profiles: group: test-env: test, localdb, debug prod-env: prod, proddb, monitor然后启动时只需要激活test-env这一个profileSpring Boot会自动把test、localdb、debug三个profile一起激活。组合名称本身不是profile它相当于是多个profile的别名或聚合入口同时激活后各profile文件里的配置会按加载顺序合并后加载的覆盖先加载的。按照官方文档如果你用spring.profiles.group激活了一组profile原来的spring.profiles.active可以留着作为激活那个组的入口也可以直接用--spring.profiles.activetest-env来激活。我自己常用的组合是dev环境默认把localdb和debug绑定在一起避免每次启动都要喊一嗓子帮我加上debug参数。5.2 多Profile同时激活时的覆盖顺序既然可以同时激活多个profile那这些profile文件之间的优先级就值得认真对待了。官方文档给出的规则是越靠后声明的profile优先级越高。比如--spring.profiles.activedev,prod代表dev先加载prod后加载覆盖它。这个特性的意义在于可以为某个环境设置一个基础profile加一个覆盖profile。打个比方dev下面是常规开发配置dev-lite是精简版比如不连MQ那么同时激活它们时可以保证dev-lite里想覆盖的配置一定生效。还要提一下配置文件命名里的一个扩展语法application-{profile}.yml也支持用号串联多个片段比如application-dev.yml和application-devlocaldb.yml这种形式。被号连接的多段配置在同一个profile下也会做顺序合并适合做同一环境内部的层次拆分。不过这个特性我在实际项目中用得很少大多数场景用spring.profiles.group已经足够了前提是项目用的Spring Boot版本在2.4以上。6. 实践建议用一个真实项目的配置清单说话讲完理论我拿一个参考了多个国内开源商城项目的典型Spring Boot电商后端来做个完整的多环境拆解把上面这些知识点落进一套看得见摸得着的配置里。这套配置的整体目标是本地跑得舒服测试环境能完整联调生产环境安全稳定。6.1 主配置application.yml的设计spring: application: name: merchant-mall-api profiles: active: dev jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 servlet: multipart: max-file-size: 10MB max-request-size: 10MB mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.mall.entity configuration: map-underscore-to-camel-case: true logging: level: root: info主配置里只放应用名、时区、JSON格式、MyBatis通用规则和根日志级别。没有数据库连接、没有Redis地址、没有文件存储路径——这些全都按环境拆到子文件里。spring.profiles.active: dev作为默认值保证新手拉下来代码直接mvn spring-boot:run就能跑不用先去看文档配参数。6.2 开发环境application-dev.yml的设计spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/mall_dev?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root123456 data: redis: host: localhost port: 6379 database: 0 logging: level: com.example.mall.mapper: debug mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl开发环境有几个特征数据库和Redis都在本机密码简单直接写日志级别开debugMyBatis输出SQL日志方便排查问题log-impl用的是控制台输出不用额外配置日志文件。值得注意的一个细节是logging.level.com.example.mall.mapper: debug这一项。日常开发调试SQL时很多朋友会去改root级别为debug结果日志里刷满了框架自带的调试信息。正确做法是只对mapper包开debug只输出MyBatis的SQL执行日志干净又准确。调试完了回生产环境时这个配置本来就只存在于dev文件里天然不会污染线上。6.3 生产环境application-prod.yml的设计spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://prod-db.internal.mysql.rds.aliyuncs.com:3306/mall_prod?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: prod_app password: ${DB_PASSWORD} hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 data: redis: host: ${REDIS_HOST} port: ${REDIS_PORT} password: ${REDIS_PASSWORD} database: 2 lettuce: pool: max-active: 50 max-idle: 20 min-idle: 5 logging: level: root: info file: name: logs/mall-api.log生产环境有几个鲜明的设计取向。第一所有敏感信息数据库密码、Redis密码一律用${}占位符引用环境变量绝不直接写在配置文件里。第二连接池参数明确调优生产数据库的并发压力比开发环境大得多必须显式指定maximum-pool-size和minimum-idle。第三日志只保留root: info不再输出SQL日志避免生产环境打印过多无意义的SQL语句影响性能。这里想多说一句密码占位的问题。很多团队用${DB_PASSWORD}这种形式但把真实的密码硬编码在部署脚本里这其实没比写在配置文件里安全多少。更稳妥的做法是部署平台本身就做了密钥管理或者在启动脚本里从密钥服务拉取后以环境变量传递。安全方面哪怕多花半小时也值。6.4 测试环境关注UAT的中间层测试环境常常是配置拆分时最容易被忽视的一个环境但实际上它最容易出问题。我在UAT环境的配置里经常把这些单独列出来spring: datasource: url: jdbc:mysql://uat-db.internal.mysql.rds.aliyuncs.com:3306/mall_uat?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: uat_app password: ${UAT_DB_PASSWORD} data: redis: host: ${UAT_REDIS_HOST} port: ${UAT_REDIS_PORT} database: 1 # 测试环境不开debug但保留SQL日志方便测试人员提单时直接截图 logging: level: com.example.mall.mapper: debugUAT环境我会保留mapper的debug日志但不打印全部的框架debug信息这样测试人员在反馈问题时能直接带上SQL记录后端排查效率能提升一大截。同时UAT环境的数据库通常和开发是分开的所以连接地址独立设置。有些公司还有预发环境pre它在配置上往往和生产基本一致只是数据库地址不同多建一个application-pre.yml内容与prod几乎一致但占位符不同即可注意别复制粘贴时改了数据库名却忘了该改用户名。6.5 Docker与容器部署时的Profile传递最后看一下Docker部署场景下的配置传递。之前提到容器镜像要尽量与环境解耦所以在Dockerfile里不要写死环境而是通过运行时的环境变量灌进去docker run -d \ --name mall-api \ -p 8080:8080 \ -e SPRING_PROFILES_ACTIVEprod \ -e DB_PASSWORDxxxx \ -e REDIS_HOST100.10.10.5 \ -e REDIS_PORT6379 \ -e REDIS_PASSWORDyyy \ mall-api:1.0.0也就是镜像里永远只包含的是不带环境信息的jar包配置全部由运行时注入这样同一份镜像走到哪都能以相同方式部署只是环境变量不同。这种做法的好处是上线流程里几乎没有机会去改配置文件所有差异都在部署编排层透明可见。遇到需要紧急回滚的时候回滚的是同一个镜像只是按下旧的环境变量组合这个操作简单可靠很多。7. 踩坑记录多环境配置里的高频问题和排查链路配置这个东西写的时候总觉得简单出了问题往往又很隐蔽。我把这两年项目里遇到的多环境配置问题整理成了一份排查清单每一项都是我或者同事真实踩过的坑。7.1 最大的坑激活了profile但配置没生效表现启动日志里明明打印了The following 1 profile is active: prod但数据库还是连的localhost。这类问题我见过不下五次。原因往往是配置文件名拼写有误——application-prod.yaml可能写成了application-prod.yml或者多打了空格、大小写错了。还有一种可能在同一个目录下同时存在application.yml和application.yamlSpring Boot默认的加载顺序是properties优先于yml但你同时放了两个格式时行为会变得难以理解尽可能只保留一种后缀。排查方法很简单启动时加--debug参数看启动日志里到底加载了哪些配置文件。Spring Boot会明确列出所有加载的配置源如果有问题一眼就能看出来。7.2 默认profile的陷阱有些团队在application.yml里把spring.profiles.active写死为prod本地开发时又得靠IDE手动覆盖成dev一旦有人忘了改连着生产库跑本地服务。最轻的后果是开发库数据被误写严重的可能直接操作了生产数据。我给团队定的规矩就是默认值永远填dev生产部署靠启动参数或环境变量覆盖。就算有人忘了覆盖最坏的结果是本地连不上测试库而不是在生产库上捣乱。安全方向必须偏向保守。7.3 打包时Profile被错误写死Maven的-P参数和Spring profile是两套东西虽然名字都叫profile但完全没有关系。Maven的-Pprod只能让Maven选择pom里的构建配置除非你像前面那样做了activatedProperties的替换否则它不会影响Spring Boot的激活环境。我见过同事在Jenkins里加了-Pprod以为这样打出来的包就是生产环境结果部署上去跑的是dev。这里一定要区分清楚Maven profile是构建期的Spring profile是运行期的构建期做的事是把参数写进配置运行期才最终决定激活什么环境。7.4 测试代码里的Profile问题在编写SpringBootTest集成测试时也要注意profile的选择。测试里我一般会单独建一个testprofile或者直接在测试类上标注SpringBootTest ActiveProfiles(test) class OrderServiceTest { // test cases }application-test.yml里配置一套专用的测试数据库或直接使用H2内存库。如果不指定测试会默认加载application.yml里的dev配置测试数据就可能写进本地开发库。写测试时把这套原则做对能从源头上减少很多捞数据恢复的麻烦。7.5 新旧版本配置属性变化Spring Boot 2.4之后spring.profiles相关属性有过一次不兼容调整。之前用spring.profiles.include来同时激活多个profile的方式部分仍然保留但新版本更推荐spring.profiles.group和组合激活。如果你的项目从2.3往上升过级老配置会出来一堆警告甚至启动失败。我印象最深的是spring.profiles的源码注释里都提醒了新老写法的区别升级前务必检查一遍所有配置文件。7.6 日志配置也要跟随环境很多人配置多环境只关注了数据库、缓存这类核心组件忽略了日志文件。生产环境通常需要把日志输出到固定目录并按天滚动而开发环境希望直接打印到控制台。解决思路是让日志配置也感知profile在logback-spring.xml里使用springProfile nameprod标签springProfile nameprod appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender filelogs/mall-api.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePatternlogs/mall-api.%d{yyyy-MM-dd}.log/fileNamePattern maxHistory30/maxHistory /rollingPolicy /appender root levelinfo appender-ref refFILE/ /root /springProfile这样生产环境自动启用文件日志开发环境不配置这个块自然就只输出到控制台了。日志配置不进profile文件体系靠的是springProfile标签独立判断这块容易被人忽略但真到排查线上问题时有没有日志文件完全是两个世界。7.7 多环境参数校验差异还有一个我在做跨境电商商城对接时遇到的场景某些参数的校验规则在不同环境要求不一致。比如支付回调域名开发环境允许http://localhost生产环境必须是https域名。这个可以通过配置项加Value注入校验白名单实现# application-dev.yml payment: callback-white-list: http://localhost:8080,http://127.0.0.1:8080# application-prod.yml payment: callback-white-list: https://pay.example.com代码里读取这个配置做校验环境的差异统一收口到配置层业务代码不用做任何环境判断。这类设计理念贯穿始终——能用配置解决的差异不要写进代码逻辑里。8. 从本地到云端的进阶Profile与配置中心的分工协作当项目规模再往上走一步到了多实例部署、微服务化之后纯靠profile文件有时就不够灵活了。这时候常规做法是引入配置中心来处理动态变更。一个常见误区是认为有了配置中心就不需要profile了实际两者是互补关系各有分工。先说分工逻辑。profile负责解决环境差异问题——本地、测试、生产本来就该用不同的数据库、不同的缓存地址配置中心负责解决运行时动态变更问题——某个开关需要在不重新打包、不重启的情况下调整或者在多实例部署时保证所有实例配置一致。两者并不冲突。以一个常见的Spring Cloud Alibaba项目为例你仍然可以在application.yml里定义spring.profiles.active和一组本地profile文件然后在bootstrap.yml里配置Nacos或其他注册和配置中心的地址把真正需要动态调整的配置项放到配置中心管理。启动时本地profile文件先落地配置中心里的配置随后覆盖。这样既保证了环境差异在启动阶段就正确又给运行时调整留了口子。实际操作中我建议按这个原则划分环境差异大的基础设施连接信息数据库、Redis、MQ优先放本地profile因为这类地址基本不会在运行期动态变化放配置中心反而增加读取成本。业务开关、限流阈值、活动配置等需要随时调整的参数放配置中心。敏感密钥信息无论放哪边都必须用占位符加外部注入严禁明文存储。这样配置中心里可以放一份适用于所有环境的默认业务配置而环境差异的维护继续走profile体系两边各管各的。等扩展到了多套集群甚至可以用配置中心的命名空间再细分环境但profile分组依然作为本地兜底存在。9. 实际维护中的心得与常用小技巧文章写到这里核心内容基本讲完了。最后分享几个我自己加班加点踩坑总结出来的小习惯不算体系但每条都能减少日常痛苦。第一个习惯是每次拉新代码启动前先看启动日志的前几行。Spring Boot启动时一定会打印当前激活了哪个profile格式大概是The following 1 profile is active: dev。如果这里显示的不是你预期中的环境立即停下来排查别等数据库连接报错才回头看。这一个习惯避免了我至少十次待遇问题。第二个习惯是把spring.profiles.active的默认值在提交前刻意检查一遍。我见过多个项目因为某次调试把默认值改成了prod然后提交结果团队里其他人在本机一启动直接连生产库。我在团队里提倡的做法是写一个简单的启动类校验逻辑或者至少在提交模板里加上一条提醒运行环境非生产却连了生产地址时打印醒目的警告日志。第三个技巧是针对IDEA用户的。在IDEA的Run Configuration里Spring Boot应用的启动项有一个Active profiles输入框可以设置当前启动用的profile。这样不用改任何文件就能切换环境配合application-dev.yml和application-uat.yml本地联调和测试环境排障都方便得很。这个框在很多人那里默认是空的所以启动时走的是配置文件里的默认值。建议开发机统一在这里填入dev把默认值留给更紧急的场景兜底。最后再提一句。多环境配置说到底是一个团队协作规范问题而不是单纯的代码问题。配置文件里该用占位符就立刻用该拆文件当天就拆不要觉得这个环境应该不会变就塞进公共配置里。我见过太多项目开发的时候图省事等出问题的时候发现原来每个环境之间的边界早就在一次次临时改一下里模糊掉了。边界清晰才是这套机制最大的价值。