Spring Batch处理含CSV的TGZ/Zip文件：编辑后生成新压缩包咨询

核心结论 #

可以直接读取TGZ/Zip文件而不解压整个归档，通过Java流式处理API结合Apache Commons Compress库，仅对目标文件进行内存/临时流级别的处理，完全无需将整个归档解压到磁盘，完美适配存储空间不足的场景。

核心处理思路 #

流式遍历原TGZ中的每个条目：

• 对需要编辑的CSV文件：流式读取内容、逐行编辑，再写入新TGZ
• 对无需编辑的文件/文件夹：直接将原条目流复制到新TGZ，保持原结构与元数据
  全程仅在内存或极小临时流中处理单个条目，磁盘占用极低。

Spring Batch组件实现方案 #

1. 自定义ItemReader #

• 依赖Apache Commons Compress库，通过GzipCompressorInputStream + TarArchiveInputStream流式遍历原TGZ的所有条目
• 按规则过滤目标文件：比如匹配指定日期的文件夹路径、特定CSV文件名
• 对目标CSV条目：将条目输入流包装为Reader，传递给内置的FlatFileItemReader逐行读取CSV内容；处理完毕后需跳过当前条目的剩余流，避免干扰下一个条目
• 对非目标条目：封装为“原样复制”的标记对象，直接传递给Writer处理

2. 自定义ItemProcessor #

• 与普通Spring Batch的Processor逻辑一致：接收CSV行数据（比如Map或自定义DTO），执行编辑逻辑（修改字段、过滤行等）
• 无需处理压缩相关逻辑，专注于业务规则

3. 自定义ItemWriter #

• 初始化TarArchiveOutputStream + GzipCompressorOutputStream，指向新TGZ的输出路径
• 处理两种类型的输入：
  • 原样复制的条目：从原TGZ输入流直接复制到新TGZ输出流，同时保留原条目元数据（权限、修改时间等）
  • 编辑后的CSV内容：创建与原路径一致的TarArchiveEntry，将编辑后的行写入该条目对应的输出流
• 注意先写入文件夹条目，再写入对应文件夹下的文件，保证新TGZ的结构正确性

关键依赖 #

在Maven/Gradle中引入Apache Commons Compress库（处理TGZ的Tar+Gzip双层压缩）：

<!-- Maven -->
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-compress</artifactId>
    <version>1.26.0</version>
</dependency>

构建优化建议 #

• 内存控制：处理大CSV时，严格使用逐行流式处理，禁止将整个文件读入内存；若单条CSV过大，可使用有限大小的临时文件缓存，处理后立即删除
• 事务与容错：因流式处理TGZ的事务回滚成本较高，建议按日期文件夹拆分Step，每个Step处理一个日期下的文件；添加条目级异常捕获，单个文件处理失败时记录日志并跳过，避免整个任务中断
• 元数据一致性：复制非编辑条目时，通过TarArchiveEntry的setMode()、setModTime()等方法保留原文件的权限、修改时间等元数据
• 测试验证：先用小体积测试TGZ验证流程正确性（结构、编辑结果、归档完整性），再测试大文件场景下的内存占用与稳定性

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