本文介绍一种基于 Spring @ConditionalOnProperty 的专业实践，通过接口抽象与条件化 Bean 注册，使同一服务既能执行真实 CRUD 操作，也能在 readOnlyAndLog=true 时仅模拟执行并输出操作计划，实现零侵入、高可维护的双模态行为切换。
本文介绍一种基于 spring `@conditionalonproperty` 的专业实践，通过接口抽象与条件化 bean 注册，使同一服务既能执行真实 crud 操作，也能在 `readonlyandlog=true` 时仅模拟执行并输出操作计划，实现零侵入、高可维护的双模态行为切换。
在微服务或数据同步类场景中，常需支持“预演模式”（dry-run）：即不修改数据库，仅分析差异并输出将要执行的 CRUD 行为。本方案以学科资源同步为例，展示如何在不重复编写核心比对逻辑的前提下，灵活切换执行模式。
核心设计思路：面向接口 + 条件化 Bean
我们首先定义统一的行为契约：
public interface SubjectHandler {
void handleSubject(Subject subject, Set<String> allJsonNames, Set<String> dbNames);
}该接口接收当前 JSON 中的单个 Subject、全部 JSON 主键集合（allJsonNames）和数据库中现存主键集合（dbNames），由其实现类决定是执行变更还是仅记录日志。
接着提供两个正交实现：
- DatabaseSubjectHandler：执行真实数据库操作（INSERT/UPDATE/DELETE）；
- ReadOnlySubjectHandler：仅根据比对结果生成日志语句，完全跳过持久层调用。
关键在于：Spring 容器应自动选择且仅注册其中一个 Bean，依据配置属性动态决策：
@Configuration
public class SubjectHandlerConfig {
@Bean
@ConditionalOnProperty(name = "readOnlyAndLog", havingValue = "true", matchIfMissing = false)
public SubjectHandler readOnlySubjectHandler() {
return new ReadOnlySubjectHandler();
}
@Bean
@ConditionalOnProperty(name = "readOnlyAndLog", havingValue = "false", matchIfMissing = true)
public SubjectHandler databaseSubjectHandler() {
return new DatabaseSubjectHandler();
}
}✅ matchIfMissing = true 表示默认启用数据库写入模式；false 则默认进入只读日志模式，符合生产安全优先惯例。
服务层整合：复用比对逻辑，解耦执行策略
业务服务（如 SubjectSyncService）不关心具体执行方式，仅依赖 SubjectHandler 接口：
@Service
public class SubjectSyncService {
private final SubjectHandler subjectHandler;
private final SubjectRepository subjectRepository;
public SubjectSyncService(SubjectHandler subjectHandler, SubjectRepository subjectRepository) {
this.subjectHandler = subjectHandler;
this.subjectRepository = subjectRepository;
}
public void syncSubjects(List<Subject> jsonSubjects) {
// 1. 加载当前 DB 中所有 subject name
Set<String> dbNames = subjectRepository.findAllNames();
// 2. 提取 JSON 中所有 name
Set<String> jsonNames = jsonSubjects.stream()
.map(Subject::getName)
.collect(Collectors.toSet());
// 3. 遍历 JSON 数据，委托 handler 处理每个 subject
for (Subject subject : jsonSubjects) {
subjectHandler.handleSubject(subject, jsonNames, dbNames);
}
// 4. 删除 JSON 中未出现但 DB 中存在的 subject（仅在 DatabaseHandler 中生效）
dbNames.removeAll(jsonNames);
for (String nameToDelete : dbNames) {
subjectHandler.handleSubject(new Subject(nameToDelete), jsonNames, dbNames);
}
}
}注意：第 4 步的“删除未匹配项”逻辑也交由 handleSubject 统一处理——ReadOnlySubjectHandler 会打印 "SubjectX will be deleted"，而 DatabaseSubjectHandler 则调用 subjectRepository.deleteByName(...)。核心差异逻辑被彻底收口到实现类内部，服务层保持纯净。
注意事项与最佳实践
- 避免在 Handler 中做数据库查询：dbNames 和 jsonNames 应由服务层一次性加载并传入，确保只读模式下无任何 JDBC 调用；
-
日志级别建议设为 INFO 或 DEBUG：便于运维人员通过日志快速验证同步意图，例如：
INFO SubjectSyncService : New-subject will be created INFO SubjectSyncService : Already-Existing-Subject is already defined in the DB INFO SubjectSyncService : Subject3 will be deleted
- 扩展性考虑：若未来需增加“事务回滚预演”或“SQL 语句生成”模式，只需新增 SubjectHandler 实现类并添加对应 @ConditionalOnProperty，无需修改服务代码；
- 配置校验建议：配合 @ConfigurationProperties 对 readOnlyAndLog 做类型安全绑定，并在启动时校验其布尔值合法性，防止因字符串误配导致行为异常。
这种设计严格遵循单一职责与开闭原则：业务逻辑（比对规则）稳定不变，执行策略（写库 or 日志）可插拔替换，真正实现“一套代码，两种语义”。
