Spring Batch 同时提供了 6.0.5 和 6.1.0-M1。两个版本虽然属于同一次发布消息，却面向不同场景：6.0.5 是 6.0 版本线上的维护版本，适合现有项目评估升级；6.1.0-M1 是 6.1 的首个里程碑版本，更适合提前验证兼容性，而不是直接替换生产环境依赖。
由于发布摘要没有列出具体修复、API 变化或依赖基线，下面不会推断不存在于摘要中的功能。实际升级前，仍需结合完整发布说明、变更记录和项目测试结果作出判断。
两条版本线解决不同问题
6.0.5 的版本号表明它延续 Spring Batch 6.0 系列。对于已经运行在 6.0.x 上的批处理系统，这类升级通常是更自然的评估对象：团队可以把注意力集中在回归测试、依赖收敛和运行指标变化上。
6.1.0-M1 中的 M1 表示 Milestone 1，也就是 6.1 开发周期中的早期里程碑。里程碑版本的价值在于尽早暴露问题，例如：
- 自定义
ItemReader、ItemProcessor和ItemWriter是否仍能正常编译与运行； - 作业仓库、事务管理器和数据库驱动的组合是否兼容；
- Spring Framework、Spring Boot 或其他基础依赖是否出现版本约束冲突；
- 作业重启、失败恢复、分区和并发执行行为是否符合预期。
这不意味着 6.1.0-M1 不可用，而是它承担的是验证任务。生产升级和前瞻验证应当分成两条流水线，避免把探索性依赖直接带入正式发布。
用 Maven 建立可切换的验证项目
可以这样实践：建立一个最小 Maven 项目，把 Spring Batch 版本集中到属性中。以下示例只用于解析依赖和检查类路径，不假设 Spring Boot 版本，也不替你的项目决定数据库、事务或调度配置。
将下面内容保存为 pom.xml，运行前只需要确认本机已经安装 JDK 和 Maven：
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>spring-batch-version-check</artifactId>
<version>1.0.0</version>
<properties>
<maven.compiler.release>17</maven.compiler.release>
<spring.batch.version>6.0.5</spring.batch.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.batch</groupId>
<artifactId>spring-batch-core</artifactId>
<version>${spring.batch.version}</version>
</dependency>
</dependencies>
</project>
这里的 Java 版本仅是验证项目的示例设置，不代表发布摘要声明的最低版本。应当根据 Spring Batch 6 的正式系统要求和团队运行环境调整。
先解析 6.0.5，并查看实际进入类路径的 Spring 组件：
mvn -U dependency:tree \
-Dincludes=org.springframework.batch:*,org.springframework:*
随后无需修改文件，直接通过命令行切换到 6.1.0-M1：
mvn -U dependency:tree \
-Dspring.batch.version=6.1.0-M1 \
-Dincludes=org.springframework.batch:*,org.springframework:*
如果里程碑构件不能从团队的仓库代理解析，不要立刻在所有项目中添加新的公共仓库。先检查企业 Nexus 或 Artifactory 的代理策略，再根据官方发布说明确认构件所在仓库。仓库配置属于供应链边界，应由平台团队统一维护。
把依赖检查推进到真实作业
依赖能够下载，只证明坐标可解析，不能证明批处理作业可升级。可以在现有项目的独立分支中分别执行两轮测试：
# 验证维护版本
./mvnw -U clean verify -Dspring-batch.version=6.0.5
# 验证里程碑版本；建议放在非阻塞的实验性 CI 任务中
./mvnw -U clean verify -Dspring-batch.version=6.1.0-M1
上述命令假设项目已经通过 ${spring-batch.version} 管理版本；如果版本由 Spring Boot BOM 管理，直接覆盖单个依赖可能破坏整套依赖约束。这种情况下，应先检查 Boot 所管理的版本，并通过单独的实验模块或明确的 BOM 配置开展测试。
批处理回归测试不能只看“进程退出码为 0”。建议至少记录以下结果：
- 同一组输入产生的输出条数、校验和与拒绝记录是否一致；
JobInstance、JobExecution和StepExecution元数据是否符合预期；- 人为制造失败后，作业是否能从正确位置重启；
- chunk 边界处的事务提交和回滚是否保持一致；
- 峰值内存、吞吐量、数据库连接数和锁等待是否发生明显变化；
- 自定义扩展点是否存在编译警告、弃用提示或运行时异常。
采用建议
已经使用 Spring Batch 6.0.x 的团队，可以优先为 6.0.5 创建升级分支，阅读完整变更记录后运行作业级回归测试。不要因为补丁版本看起来变化较小，就跳过数据库元数据、重启语义和性能验证。
对于 6.1.0-M1，更合适的做法是建立定期执行但不阻塞生产发布的兼容性任务。它可以帮助团队提前发现 API、依赖和运行环境问题，但不应在缺少正式评估的情况下进入生产版本锁文件。
最终选择可以归结为三个问题：当前系统是否需要留在 6.0 维护线、团队是否有能力持续验证里程碑版本，以及升级结果是否经过真实作业数据与失败恢复场景的证明。版本号给出方向，测试结果才决定能否上线。