本文介绍一种基于 Spring @ConditionalOnProperty 的优雅方案，通过接口抽象与条件化 Bean 注册，在同一服务中复用核心逻辑，实现“仅日志预演”与“真实执行”两种模式的无缝切换。

本文介绍一种基于 spring `@conditionalonproperty` 的优雅方案，通过接口抽象与条件化 bean 注册，在同一 service 中复用核心逻辑，实现“仅日志预演”与“真实执行”两种模式的无缝切换。

在现代 Spring 应用开发中，常遇到一类典型需求：同一套业务决策逻辑（如比对 JSON 配置与数据库状态、识别新增/删除项），需支持两种运行模式——真实执行 CRUD 与 只预演、仅记录将要执行的操作（即 dry-run 模式）。硬编码 if (readOnlyAndLog) { log(...) } else { save/delete(...) } 不仅破坏单一职责，还导致测试困难、逻辑耦合、扩展性差。

最佳实践是面向接口设计 + 条件化 Bean 注入。核心思路是：将“执行动作”的职责从主服务中剥离，定义统一行为契约（接口），再由 Spring 根据配置自动注入对应实现。

✅ 步骤一：定义行为契约接口

public interface SubjectHandler {
    void handleSubject(Subject subject, OperationType operation);

    enum OperationType {
        CREATE, UPDATE, DELETE, EXISTS_IN_DB, MISSING_IN_JSON
    }
}

该接口封装了对单个 Subject 的所有可能操作语义，便于统一日志格式与后续扩展。

✅ 步骤二：提供两种实现类

1. 日志预演实现（dry-run 模式）

@Component
@ConditionalOnProperty(name = "app.readOnlyAndLog", havingValue = "true", matchIfMissing = false)
public class ReadOnlySubjectHandler implements SubjectHandler {

    private static final Logger log = LoggerFactory.getLogger(ReadOnlySubjectHandler.class);

    @Override
    public void handleSubject(Subject subject, OperationType operation) {
        switch (operation) {
            case CREATE -> log.info("{} will be created", subject.getName());
            case UPDATE -> log.info("{} will be updated", subject.getName());
            case DELETE -> log.info("{} will be deleted", subject.getName());
            case EXISTS_IN_DB -> log.info("{} is already defined in the DB", subject.getName());
            case MISSING_IN_JSON -> log.warn("{} exists in DB but is missing from config", subject.getName());
        }
    }
}

2. 真实执行实现（生产模式）

@Component
@ConditionalOnProperty(name = "app.readOnlyAndLog", havingValue = "false", matchIfMissing = true)
public class DatabaseSubjectHandler implements SubjectHandler {

    private final SubjectRepository repository;

    public DatabaseSubjectHandler(SubjectRepository repository) {
        this.repository = repository;
    }

    @Override
    public void handleSubject(Subject subject, OperationType operation) {
        switch (operation) {
            case CREATE -> repository.save(subject);
            case UPDATE -> repository.save(subject);
            case DELETE -> repository.deleteByName(subject.getName());
            case EXISTS_IN_DB -> {} // no-op, just a check result
            case MISSING_IN_JSON -> repository.deleteByName(subject.getName());
        }
    }
}

? 关键点：@ConditionalOnProperty 的 matchIfMissing = true 表示当配置未显式设置时，默认启用数据库执行模式，保障生产环境安全；而 havingValue = "true" 明确匹配布尔字符串值（注意 Spring Boot 2.4+ 对 true/false 字符串解析更严格，推荐使用 Boolean.parseBoolean() 或 @Value("${app.readOnlyAndLog:false}") 做兜底）。

✅ 步骤三：主服务注入并复用决策逻辑

@Service
public class SubjectSyncService {

    private final SubjectHandler subjectHandler;
    private final SubjectRepository repository;

    public SubjectSyncService(SubjectHandler subjectHandler, SubjectRepository repository) {
        this.subjectHandler = subjectHandler;
        this.repository = repository;
    }

    @Transactional
    public void syncSubjectsFromJson(Resource jsonResource) throws IOException {
        JsonNode rootNode = new ObjectMapper().readTree(jsonResource.getInputStream());
        List<Subject> configSubjects = parseSubjects(rootNode);

        // Step 1: 获取当前 DB 中所有 subject（按 name 建索引）
        Map<String, Subject> dbMap = repository.findAll().stream()
                .collect(Collectors.toMap(Subject::getName, Function.identity()));

        // Step 2: 遍历配置项 —— 决策创建或更新
        for (Subject configSub : configSubjects) {
            if (dbMap.containsKey(configSub.getName())) {
                subjectHandler.handleSubject(configSub, SubjectHandler.OperationType.UPDATE);
                // 可选：实际更新字段（若需要）
            } else {
                subjectHandler.handleSubject(configSub, SubjectHandler.OperationType.CREATE);
            }
        }

        // Step 3: 找出 DB 中存在但配置中缺失的项 —— 决策删除
        dbMap.keySet().stream()
                .filter(dbName -> configSubjects.stream().noneMatch(s -> s.getName().equals(dbName)))
                .forEach(missingName -> {
                    Subject missingSubject = dbMap.get(missingName);
                    subjectHandler.handleSubject(missingSubject, SubjectHandler.OperationType.DELETE);
                });
    }

    private List<Subject> parseSubjects(JsonNode rootNode) {
        return StreamSupport.stream(
                rootNode.path("subjects").spliterator(), false)
                .map(this::mapToSubject)
                .toList();
    }

    private Subject mapToSubject(JsonNode node) {
        return new Subject(
            node.path("name").asText(),
            node.path("description").asText(),
            node.path("price").asInt()
        );
    }
}

该服务完全不关心“是否真实执行”，它只负责识别差异、做出决策、委托处理——真正的执行策略由 Spring 在启动时根据 app.readOnlyAndLog 配置动态绑定，实现了关注点彻底分离。

⚠️ 注意事项与进阶建议

• 配置命名规范：建议使用 app.readOnlyAndLog 而非裸名 readOnlyAndLog，避免与 Spring Boot 内部属性冲突；
• 日志级别选择：预演模式推荐使用 INFO 级别（便于运维查看），而非 DEBUG，确保关键预演信息可被生产日志系统捕获；
• 增强可观测性：可在 SubjectSyncService 中添加 @Timed（Micrometer）或自定义指标，统计预演/执行耗时、操作数量等；
• 扩展性预留：未来若需支持“生成 SQL 脚本”模式，只需新增 SqlScriptSubjectHandler 并添加对应 @ConditionalOnProperty 即可，主服务零修改；
• 测试友好性：单元测试时可通过 @MockBean SubjectHandler 精准验证不同场景下的调用行为，无需启动整个容器。

通过这一设计，你不仅满足了“开关控制执行模式”的原始需求，更构建了一个高内聚、低耦合、易测试、可演进的服务架构。真正的业务价值，永远藏在清晰的抽象与克制的条件分支之中。