在报表导出、数据同步等场景中，系统往往需要一次性生成大量XML文件。如果让用户逐个点击下载，体验非常糟糕，也浪费服务器带宽。更常见的做法是在服务端把这些XML文件打包成一个Zip压缩包，浏览器一次请求就能拿到全部内容。Java标准库已经自带了压缩能力，配合Servlet的输出流就能轻松实现，甚至不需要引入第三方依赖。下面从核心API、完整代码示例到常见的坑，逐一展开说明。
一、Java压缩Zip的核心类与基本原理
JDK从1.1开始就在java.util.zip包中提供了压缩相关的类，最常用的三个是ZipOutputStream、ZipEntry和InputStream。ZipOutputStream代表压缩包本身的输出流，所有写入它的数据都会被压缩；ZipEntry代表压缩包内的一个文件条目，条目名就是用户解压后看到的文件路径和文件名。
整体流程可以概括为四步：创建ZipOutputStream并绑定目标输出流，调用putNextEntry声明一个新条目，把XML内容写入该条目，最后调用closeEntry结束当前条目。重复第二到第四步即可写入多个文件，全部写完后关闭流，压缩包就完成了。整个过程是流式的，也就是说目标输出流完全可以是Servlet的response.getOutputStream()，数据边压缩边发送给浏览器，不需要在服务器磁盘上生成临时文件，这对高并发场景特别友好。
需要注意写入顺序：putNextEntry必须写在内容之前，closeEntry必须写在内容之后，同一个条目写完后才能开始下一个条目。如果忘了调用closeEntry就继续putNextEntry，新版本的JDK会自动关闭上一个条目，但老版本可能产生损坏的压缩包，所以规范写法是显式成对调用。
import java.io.OutputStream;
import java.nio.charset.StandardCharsets;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;
public class XmlZipUtil {
/**
* 把多个XML内容写入同一个Zip输出流
* @param zos 压缩输出流
* @param fileName 压缩包内的文件名
* @param xmlContent XML字符串内容
*/
public static void addXmlToZip(ZipOutputStream zos,
String fileName,
String xmlContent) throws Exception {
// 声明一个新的条目，条目名就是解压后的文件名
zos.putNextEntry(new ZipEntry(fileName));
// 将XML内容按UTF-8编码写入
zos.write(xmlContent.getBytes(StandardCharsets.UTF_8));
// 结束当前条目
zos.closeEntry();
}
public static void zipToStream(OutputStream out) throws Exception {
try (ZipOutputStream zos = new ZipOutputStream(out)) {
addXmlToZip(zos, "order_20240101.xml", "<order><id>1001</id></order>");
addXmlToZip(zos, "order_20240102.xml", "<order><id>1002</id></order>");
}
}
}二、结合Spring MVC实现浏览器端下载
有了压缩工具方法，接下来就是把它接入Web层。关键点在于正确设置响应头：Content-Type要设置成application/zip（有些资料写octet-stream也能用，但zip是更准确的MIME类型），Content-Disposition用来告诉浏览器这是一个附件以及默认文件名。文件名如果包含中文，必须按RFC规范进行URL编码，否则不同浏览器会出现乱码或文件名丢失。
以Spring Boot为例，Controller方法直接注入HttpServletResponse，拿到输出流后交给工具类写入即可。整个过程中不要调用response.getWriter()，因为getWriter和getOutputStream在同一个响应中互斥，混用会抛出IllegalStateException。下面给出一个模拟从业务层取数据并批量打包的完整示例：
@RestController
@RequestMapping("/export")
public class XmlExportController {
@GetMapping("/orders/zip")
public void downloadOrderZip(HttpServletResponse response) throws Exception {
// 模拟业务数据，实际项目中从数据库查询
Map<String, String> xmlMap = new LinkedHashMap<>();
xmlMap.put("order_1001.xml", "<order><id>1001</id></order>");
xmlMap.put("order_1002.xml", "<order><id>1002</id></order>");
// 设置响应头，文件名做URL编码防止中文乱码
String zipName = URLEncoder.encode("订单数据.zip", StandardCharsets.UTF_8.name())
.replaceAll("\\+", "%20");
response.setContentType("application/zip");
response.setHeader("Content-Disposition",
"attachment; filename*=UTF-8''" + zipName);
try (ZipOutputStream zos = new ZipOutputStream(response.getOutputStream())) {
for (Map.Entry<String, String> entry : xmlMap.entrySet()) {
zos.putNextEntry(new ZipEntry(entry.getKey()));
zos.write(entry.getValue().getBytes(StandardCharsets.UTF_8));
zos.closeEntry();
}
zos.finish();
}
}
}传统Servlet项目写法基本一致，同样是在doGet或doPost中先设置响应头，再从response.getOutputStream()获取流。如果项目仍在用JSP，务必保证在获取输出流之前没有任何内容被输出到响应缓冲区，否则同样会抛异常。打包完成后不需要手动flush，ZipOutputStream的close方法会自动完成收尾。
三、实战中容易踩的坑与进阶优化
第一是文件名重复问题。Zip格式允许压缩包内存在同名条目，写入时不会报错，但用户解压时会被操作系统提示覆盖，导致部分文件丢失。批量导出时如果文件名由日期或单号生成，一定要做去重处理，比如检测到重名就追加序号，生成order_1001(1).xml这样的名字。
第二是中文文件名乱码。JDK自带的ZipOutputStream默认使用UTF-8编码条目名，主流解压工具都能正常识别。但如果我们希望显式控制，可以在构造时传入new Charset("GBK")等编码，兼容一些老旧的Windows解压环境。如果使用Apache Commons Compress库，其ZipArchiveOutputStream还支持设置Unicode扩展字段，兼容性更好。
// 指定条目名编码为GBK，兼容老版本WinRAR等解压工具
ZipOutputStream zos = new ZipOutputStream(out, Charset.forName("GBK"));第三是内存占用。上面示例为了演示方便把XML内容以字符串形式放在Map里，数据量大时建议改成流式读取：每查一批数据就生成一个XML并立即写入ZipEntry，写完释放引用，而不是先在内存中攒齐所有文件。查询也可以用游标或分页方式，把单次请求的内存峰值控制住。如果是磁盘上已有的XML文件需要打包，则配合FileInputStream和缓冲区逐段拷贝，避免一次性读入大文件。
// 从磁盘文件流式写入Zip，避免大文件占用内存
try (ZipOutputStream zos = new ZipOutputStream(out);
FileInputStream fis = new FileInputStream("D:\\data\\big.xml")) {
zos.putNextEntry(new ZipEntry("big.xml"));
byte[] buffer = new byte[8192];
int len;
while ((len = fis.read(buffer)) > 0) {
zos.write(buffer, 0, len);
}
zos.closeEntry();
}第四是异常与用户体验。一旦响应头已经提交，服务端再抛异常时浏览器只会收到一个下载了一半的损坏文件，所以业务校验和数据准备应尽量在打开输出流之前完成。数据量为零时可以直接返回错误提示而不是空压缩包。此外，Zip格式本身不支持对压缩内容高强度加密，如有安全要求，建议先在业务层加密XML内容再打包，或改用7z等支持加密的格式并引入相应工具库。
总结一下，Java实现XML打包压缩下载并不复杂：核心是ZipOutputStream配合Servlet输出流，重点在于响应头设置、文件名编码、条目去重和流式处理这四个细节。把这些处理好，就能在几乎零依赖的情况下提供稳定可靠的批量下载功能。数据规模再往上走时，可以考虑异步生成压缩包加对象存储的方案，把打包过程从请求线程中剥离出来，进一步提升系统的承载能力。