本文讲解 Spring Batch 中基于步骤执行结果（如 FAILED 或 COMPLETE）动态控制作业流向的正确写法，重点解决因 on("*").fail() 和 from().on("*") 顺序误用导致作业状态与预期不符的问题。
本文讲解 spring batch 中基于步骤执行结果（如 failed 或 complete）动态控制作业流向的正确写法，重点解决因 `on("*").fail()` 和 `from().on("*")` 顺序误用导致作业状态与预期不符的问题。
在 Spring Batch 的 Job 构建中，流程控制（Flow Control）依赖于 SimpleFlow 的状态驱动机制——每个 Step 执行后会返回一个 ExitStatus（如 COMPLETED、FAILED、STOPPED 等），而 .on("pattern") 正是匹配该 ExitStatus.getExitCode() 的字符串模式（支持通配符 * 和 Ant 风格表达式）。但关键前提是：必须明确区分“单次执行路径”与“多分支并行路径”，且 .from() 的调用需严格遵循构建时序逻辑。
你原始代码的核心问题在于：
- 第一个 .on("FAILED").to(writerTasklet()).on("*").fail() 是合法分支；
- 但紧接着的 .from(fileCollectTasklet()) 重复声明了同一 Step 的起点，而 Spring Batch 不允许对同一个 Step 实例多次调用 .from() 作为独立入口（这会导致构建异常或行为未定义）；
- 更重要的是，.on("*") 应覆盖除 FAILED 外的所有状态（如 COMPLETED、EXECUTING 等），但若未显式排除 FAILED，则可能与前一分支冲突，造成状态匹配歧义。
✅ 正确做法是：只声明一次 fileCollectTasklet() 为起始 Step，再通过两个互斥的 .on(...) 分支覆盖全部退出状态：
@Bean
public Job testJob() {
return jobBuilderFactory.get("test_job")
.incrementer(new RunIdIncrementer())
.preventRestart()
.start(fileCollectTasklet())
// 分支1：fileCollectTasklet 失败 → 执行 writerTasklet → 强制作业失败
.on("FAILED")
.to(writerTasklet())
.on("*") // writerTasklet 任意结果都不影响最终状态
.fail() // 立即终止作业，状态为 FAILED
// 分支2：fileCollectTasklet 非失败（如 COMPLETED）→ 执行 writerTasklet → 正常结束作业
.on("*") // 匹配所有其他退出码（等价于 "COMPLETED, STOPPED, EXECUTING..."）
.to(writerTasklet())
.on("*") // 同样忽略 writerTasklet 结果
.end() // 作业以 EXIT_CODE=COMPLETED 结束
.end();
}
? 注意事项：
- on("*") 是通配匹配，必须放在 on("FAILED") 之后，否则它会提前捕获所有状态，使 FAILED 分支永不触发；
- writerTasklet() 在两个分支中均被调用，但其返回的 ExitStatus 不会覆盖外层 .fail() 或 .end() 的决策——这是 Spring Batch Flow 的设计保证；
- 若需在 writerTasklet() 中记录失败原因，建议在其内部抛出 RuntimeException 并配置 skipPolicy，而非依赖其退出码控制主流程；
- 建议为每个 Step 显式设置 ExitStatus（例如在 Tasklet.execute() 中 return RepeatStatus.FINISHED.andExitStatus(ExitStatus.FAILED)），提升可读性与调试效率。
总结：Spring Batch 的流程控制本质是状态机编排，而非简单条件判断。务必遵循“单起点、多分支、有序匹配”原则，并善用 on("PATTERN").to(Step) + on("*").action() 组合实现健壮的错误处理与终态管理。
