配置覆盖源于资源合并、加载顺序与键名重复，应通过模块化路径隔离、命名前缀约束、显式导入及类型安全绑定解决。
配置覆盖问题不是配置文件本身“主动覆盖”，而是构建和运行时资源合并、加载顺序、键名重复共同作用的结果。关键在于把配置当作有边界的模块资产，而不是全局共享的扁平文本。
用模块专属路径隔离配置资源
避免所有模块都往 src/main/resources/application.properties 写配置。应按模块划分物理路径：
- 用户模块 →
src/main/resources/config/user/ - 订单模块 →
src/main/resources/config/order/ - 支付模块 →
src/main/resources/config/payment/
再配合 Maven 的 resources 插件显式指定输出目录，或 Spring Boot 的 spring.config.location 指向各模块配置路径。这样就不会因默认合并规则导致后打包的模块覆盖前者的 app.name 这类同名 key。
配置项命名强制带模块前缀
即使键写在同一个文件里，也要靠命名约定防冲突：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- ❌
timeout=3000（谁的超时？） - ✅
user.service.timeout-ms=3000 - ✅
order.api.retry.max-attempts=3
可结合 Checkstyle 或自定义 SonarQube 规则，在 CI 中扫描 application.* 文件，拦截不含模块前缀的简单键名（如 cache.ttl），强制开发者明确归属。
禁用隐式资源合并，改用显式导入
Maven 默认会把所有 resources 目录下的同名文件按声明顺序合并。这不是必须行为——可在 pom.xml 中关闭：
- 移除
<includes><include>**/*.properties</include></includes>这类宽泛配置 - 改为逐个模块声明：
src/main/resources/config/user - Spring Boot 启动时通过
--spring.config.location=classpath:/config/user/,classpath:/config/order/显式加载，顺序可控
把配置从字符串升级为类型安全对象
避免直接读取 String timeout = env.getProperty("timeout") 这种易错方式：
- 每个模块定义自己的配置类，如
UserProperties、OrderProperties - 用
@ConfigurationProperties(prefix = "user.service")绑定，字段名即配置键后缀 - Spring Boot 2.2+ 支持
@ConstructorBinding实现不可变配置，天然杜绝运行时修改
这样不仅规避了 key 冲突，还获得编译期校验、IDE 自动补全和文档生成能力。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
