关键在于建立配置项校验闭环：明确生产专属配置清单并固化为文档或CI检查项；通过@PostConstruct启动校验确保环境一致性；application.yml仅存共用默认值，prod特有配置严格限定在application-prod.yml；构建阶段自动扫描并告警缺失或占位符未注入项。
关键不是“多写几遍”，而是建立配置项的校验闭环——让遗漏无法静默发生。
明确生产环境专属配置清单
先定义哪些属性必须只出现在 prod 环境，且绝不能在 dev/test 中出现或生效。例如：
- 数据库连接池最大活跃数（如
spring.datasource.hikari.maximum-pool-size=50） - 敏感端点关闭（
management.endpoints.web.exposure.include=health,info） - 日志滚动策略（
logging.logback.rollingpolicy.max-history=90） - 缓存过期时间（
spring.cache.redis.time-to-live=3600000） - HTTPS强制重定向（
server.tomcat.redirect-context-root=true）
把这份清单固化为团队文档或 CI 检查项，每次新增生产特性时同步更新。
用 profile 条件 + 启动校验双重兜底
仅靠文件分离不够，需主动验证。在启动类中加入环境一致性断言：
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
@PostConstruct
public void validateProdConfig() {
if ("prod".equals(environment.getActiveProfiles()[0])) {
String dbUrl = environment.getProperty("spring.datasource.url", "");
if (!dbUrl.contains("prod-db") && !dbUrl.contains("prod.")) {
throw new IllegalStateException("PROD config missing: spring.datasource.url does not point to production DB");
}
if (environment.getProperty("logging.level.com.example") != null &&
environment.getProperty("logging.level.com.example").equals("debug")) {
throw new IllegalStateException("PROD must NOT have debug log level enabled");
}
}
}
这类检查能在应用启动瞬间暴露配置缺失，而不是等上线后报错。
禁止在 application.yml 中写 prod 特有值
主配置文件 application.yml 只放所有环境共用且安全的默认值，比如：
- 应用名（
spring.application.name） - 基础包扫描路径（
spring.main.banner-mode） - 通用 Jackson 配置（
spring.jackson.date-format）
任何带环境强依赖的字段（如数据库地址、密钥占位符、端口、监控开关）一律只允许出现在 application-prod.yml 中。这样能从源头避免“误把 dev 值当 prod 提交”。
构建阶段自动注入缺失项并告警
利用 Maven 的 maven-resources-plugin 在打包时扫描 application-prod.yml，比对预设清单：
- 若发现必配项为空或缺失，构建失败并输出具体字段名
- 若某项存在但值为占位符（如
${DB_PASSWORD}），检查对应环境变量是否已声明（可通过mvn verify -Pprod触发） - 配合 CI 脚本，在 prod 构建流水线中强制运行
grep -q "maximum-pool-size" target/classes/application-prod.yml类似校验
让遗漏在代码合并前就被拦截，而不是等到部署时才发现。
