Java中使用try-with-resources配合ZipOutputStream压缩下载时，必须显式调用closeEntry()并按内→外顺序声明嵌套流，否则ZIP文件易损坏；还需正确设置响应头、禁用自动缓冲，并在异常时双重保障closeEntry()执行。
Java 中使用 try-with-resources 配合 ZipOutputStream 实现压缩打包下载时，若资源未正确关闭或流顺序出错，极易导致 ZIP 文件损坏（如解压失败、CRC 校验错误、文件缺失）。关键在于确保所有嵌套流按反向顺序自动关闭，且 ZipEntry 必须显式关闭（调用 closeEntry()），否则压缩数据不完整。
必须显式调用 closeEntry()，不能只依赖 try-with-resources
ZipOutputStream 的每个 ZipEntry 相当于一个逻辑“文件块”，写入内容后必须调用 zos.closeEntry() 才会刷新缓冲区、写入 CRC 和大小等元数据。仅靠 try-with-resources 关闭外层流，无法自动完成这一步——它只关闭流本身，不感知 entry 生命周期。
- 遗漏
closeEntry()→ ZIP 文件可打开但解压时报“CRC failed”或“invalid compressed data” - 应在每次写完一个 entry 内容后立即调用，即使发生异常也要保证执行（建议放在 finally 或 try-with-resources 的子块中）
- 示例正确写法：zos.putNextEntry(entry); ... 写入数据 ... ; zos.closeEntry();
嵌套流需严格按“内→外”顺序声明，避免提前关闭
ZIP 下载通常涉及多层包装：原始输出流（如 ServletOutputStream 或 ByteArrayOutputStream）→ BufferedOutputStream → ZipOutputStream。try-with-resources 按声明逆序关闭，因此必须从最内层开始写：
- ✅ 正确顺序：
try (ZipOutputStream zos = new ZipOutputStream(new BufferedOutputStream(response.getOutputStream()))) - ❌ 错误顺序：
try (BufferedOutputStream bos = new BufferedOutputStream(...); ZipOutputStream zos = new ZipOutputStream(bos))→bos先关闭，zos后续操作失效 - 若用
ByteArrayOutputStream做缓冲，也应将其置于最内层，最后再写入响应流
捕获异常后禁止吞掉 closeEntry()，需双重保障
写入某个 entry 时若抛出 IOException（如磁盘满、网络中断），当前 entry 数据可能已部分写入。此时必须主动调用 closeEntry()，否则后续 entry 会污染 ZIP 结构，导致整个包损坏。
立即学习“Java免费学习笔记（深入）”；
- 推荐在每个 entry 写入块加独立 try-catch，并在 catch 中调用
closeEntry() - 也可用“finally”包裹
closeEntry()，确保无论成功失败都执行 - 注意：
closeEntry()自身也可能抛IOException，应合并处理或记录日志，但不可忽略
响应头与缓冲区需匹配，防止截断
Web 下载场景下，ZIP 文件损坏常被误认为是代码问题，实则源于 HTTP 层配置不当：
- 务必设置
Content-Disposition: attachment; filename="xxx.zip"和Content-Type: application/zip - 禁用 response 流的自动缓冲（如 Spring Boot 的
response.flushBuffer()或 Tomcat 的bufferSize设置过小），否则末尾数据可能未写出 - 若用
ByteArrayOutputStream先生成 ZIP，则最终写入前需调用baos.toByteArray()，而非baos.toString()（会乱码）
