Spring Batch中将业务逻辑放在Processor配空Writer是否符合最佳实践

结论 #

你这种写法虽然能正常运行，但不属于Spring Batch的最佳实践，也完全没必要特意使用空实现的Writer把全部业务逻辑塞到Processor中。

核心问题说明 #

1. 违背Chunk模型的职责设计约定 #

Spring Batch的面向Chunk的处理流程本身做了明确的职责拆分：

• ItemReader：仅负责批量读取数据源数据
• ItemProcessor：仅负责单条数据的转换、过滤、轻量级业务校验，设计上就不承载最终业务落地的职责
• ItemWriter：负责批量处理/持久化经过Processor处理后的完整Chunk数据集

把业务落地逻辑全部放在Processor中，不符合框架的设计约定，后续维护人员排查业务落地逻辑时，会不符合常规的排查路径，提升维护成本。

2. 存在事务管理失效风险 #

Spring Batch默认会为每个Chunk包裹统一事务，当Chunk内任意一条数据处理失败时，整个Chunk的所有操作都会自动回滚。如果你把数据库修改、外部接口调用这类业务操作写在Processor中，这些操作如果没有主动接入Spring Batch的事务管理，就会出现部分数据执行成功、部分执行失败的脏数据问题，和Chunk的事务设计逻辑相悖。

3. 浪费批量处理的性能优势 #

ItemProcessor是单条串行处理数据的，而ItemWriter是一次接收整个Chunk大小的数据集的。如果你的业务逻辑支持批量操作（比如批量插入数据库、批量调用外部批量接口），放在Writer中实现的性能会远高于Processor单条执行，数据量越大性能差距越明显。

适用场景说明 #

如果你的项目是临时工具类项目、数据量极小、不需要考虑后续维护和事务一致性，这种写法可以临时使用，但正规生产项目绝对不推荐。

优化建议 #

把你myCustomStuff方法中属于业务落地的逻辑迁移到自定义ItemWriter中实现即可，不需要保留空实现的BlankWriter。如果有单条数据的前置校验、转换逻辑可以保留在Processor中，最终落地逻辑全部放到Writer里，既符合框架设计规范，也能享受框架自带的事务、重试、跳过等原生能力。

内容的提问来源于stack exchange，提问作者Ajay Kumar