Spring Batch 6.1.0-M2 已经发布。M2 表示这是 6.1 版本线上的第二个里程碑版本，更适合用于兼容性验证、提前发现迁移问题和向项目提交反馈，而不是未经评估直接替换生产环境中的稳定版本。
目前给出的信息只有版本发布消息，没有具体功能清单。因此，与其猜测新增了哪些 API，不如先建立一套可重复的验证流程：确认依赖能否解析、项目能否编译、批处理元数据是否兼容，以及失败重启、跳过和重试等关键语义是否符合预期。
先确认依赖，而不是立刻升级整个应用
批处理框架通常位于业务逻辑、数据库和调度系统的交界处。即使一次升级没有修改业务代码，也可能受到以下因素影响：
- Spring Framework、数据库驱动及日志组件的传递依赖变化；
- 已废弃 API 被进一步收紧或移除；
- Job、Step、Reader、Writer 的构建方式发生编译期变化；
- Job Repository 使用的元数据表结构或 SQL 方言发生变化；
- 失败重启、事务回滚、跳过和重试行为出现边界差异；
- 指标名称、日志字段或追踪信息影响现有监控规则。
因此，第一步应当是建立一个独立分支，并通过依赖树确认实际进入应用的版本：
./mvnw -q dependency:tree \
-Dincludes=org.springframework.batch,org.springframework,org.springframework.retry
Gradle 项目可以检查运行时依赖：
./gradlew dependencies --configuration runtimeClasspath
不要只检查 spring-batch-core。应用最终运行的是一组相互关联的依赖，直接覆盖单个 JAR 的版本可能绕过框架或平台提供的版本对齐机制。
用最小工程确认 6.1.0-M2 可以被解析
下面是一个只负责加载 Spring Batch 核心类并打印实现版本的冒烟工程。它不代表正式应用的推荐依赖组合，仅用于确认仓库、JDK 和构建工具能够解析该里程碑版本。
示例假设本机已经安装 JDK 17 和 Maven 3.9；如果你的目标平台要求更高版本，请同步修改 maven.compiler.release。
mkdir -p batch-610m2-smoke/src/main/java/example
cd batch-610m2-smoke
cat > pom.xml <<'EOF'
<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>example</groupId>
<artifactId>batch-610m2-smoke</artifactId>
<version>1.0.0</version>
<properties>
<maven.compiler.release>17</maven.compiler.release>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<repositories>
<repository>
<id>spring-milestones</id>
<url>https://repo.spring.io/milestone</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>org.springframework.batch</groupId>
<artifactId>spring-batch-core</artifactId>
<version>6.1.0-M2</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.13.0</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>3.5.0</version>
</plugin>
</plugins>
</build>
</project>
EOF
cat > src/main/java/example/VersionCheck.java <<'EOF'
package example;
import org.springframework.batch.core.Job;
public class VersionCheck {
public static void main(String[] args) {
Package batchPackage = Job.class.getPackage();
String version = batchPackage.getImplementationVersion();
String location = Job.class.getProtectionDomain()
.getCodeSource()
.getLocation()
.toString();
System.out.println("Spring Batch implementation version: " + version);
System.out.println("Loaded from: " + location);
}
}
EOF
mvn -q clean compile exec:java -Dexec.mainClass=example.VersionCheck
mvn -q dependency:tree -Dincludes=org.springframework.batch,org.springframework
如果版本字段因制品清单配置而显示为 null，第二行的 JAR 路径仍可用于确认实际加载的文件。若企业环境使用 Nexus 或 Artifactory，应将里程碑仓库配置在内部代理中，而不是要求每位开发者单独修改 Maven 设置。
真正需要回归的是批处理语义
成功编译只证明 API 和依赖基本可用，不能证明作业行为保持不变。针对已有项目，可以挑选一个具有代表性的 Job，至少覆盖以下场景：
- 正常完成：输入数量、输出数量和提交次数与稳定版本一致。
- 处理中断：在固定记录处主动抛出异常，确认事务回滚边界。
- 失败重启：使用相同 Job 参数重启，确认不会重复处理已提交的数据。
- 不可重启场景：确认框架拒绝重复启动的方式符合应用预期。
- 跳过与重试：分别制造可恢复异常和不可恢复异常，检查计数及退出状态。
- 并发执行：如果使用分区、异步处理或远程执行，检查线程安全和消息重复投递。
数据库是升级中最需要谨慎处理的部分。不要因为依赖升级成功就自动在共享数据库执行新的初始化脚本。应先比较当前元数据表与新版本附带脚本的差异，再在数据库副本上完成以下验证：
# 示例：在测试环境分别导出升级前后的元数据表定义。
# 请按实际数据库替换命令、连接参数和表名。
pg_dump --schema-only --table='batch_*' "$BATCH_DB_URL" > batch-schema-before.sql
# 应用经过审核的迁移脚本后再次导出
pg_dump --schema-only --table='batch_*' "$BATCH_DB_URL" > batch-schema-after.sql
diff -u batch-schema-before.sql batch-schema-after.sql || true
这里的重点不是让应用自动建表，而是把结构变化变成可审查、可回滚的数据库变更。
适合 M2 的采用方式
里程碑版本最有价值的使用场景，是提前验证下一条版本线是否会破坏现有系统。可以把 6.1.0-M2 放入独立 CI 任务，与当前稳定版本并行运行同一组集成测试，并分别保存依赖树、Job 执行记录和性能数据。
采用前可以逐项确认：
- 使用独立分支或版本矩阵，不覆盖生产依赖锁文件；
- 阅读正式发布说明和迁移文档后，再判断 API 与数据库影响；
- 使用生产数据的脱敏副本测试重启与幂等性；
- 对吞吐量、提交间隔、数据库连接数和内存占用做基线对比；
- 为批处理元数据迁移准备备份和回滚脚本；
- 只有在候选版本或正式版本发布后，再重新评估生产升级窗口。
对于库作者、平台团队和维护大型批处理系统的团队，尽早试用 M2 能把兼容性问题暴露在正式发布之前。对于普通业务系统，更稳妥的策略仍然是：现在验证、记录差异、反馈问题，生产环境继续使用已经通过组织内部验证的稳定版本。