简介：本资源是一套基于Java实现的多URL文件批量下载与ZIP打包导出的完整工程实践方案，面向Java初中级开发者及Web后端学习者，解决网络文件聚合分发场景下的核心需求：从多个远程URL并发下载资源，并自动整理、压缩为可直接下载的ZIP包。压缩包共28个文件，包含5个核心Java类（含下载调度、ZIP流写入、异步任务编排逻辑）、6个XML配置与Maven构建文件、5个Properties参数配置、1个HTML前端触发页面及配套的Eclipse项目元数据（.project、.classpath等），整体仅30KB，轻量易读。已有5460人学习下载，代码结构清晰，目录严格遵循Maven标准布局（src/main/java、target/classes等），并内置HTTP响应头设置、ZipEntry路径处理、异常容错等生产级细节，可直接嵌入Spring Web项目或作为教学案例理解文件I/O、网络请求与压缩算法的协同实现。

1. 多个远程文件批量下载+打包导出：为什么不能只用一个ZipOutputStream循环写？

你有没有试过这样写：遍历一堆 URL，用HttpURLConnection下载每个文件流，再一股脑塞进ZipOutputStream？结果跑一半报IOException: Stream closed，或者 zip 解压后发现部分文件是空的、大小为 0？这不是玄学——这是典型的「流生命周期错配」翻车现场。这个方案要解决的，不是“怎么压缩”，而是「在不确定网络延迟、文件大小、服务端响应策略的前提下，如何安全、可控、可中断地完成「下载 → 内存/临时存储 → 打包 → 响应输出」全链路」。它适合正在做毕设或课设的学生（比如某高校《Web 应用开发》课程设计），也适合需要快速交付后台导出功能的初级工程师。核心约束很实在：不依赖外部中间件（如 Redis 或消息队列）、不占用过多堆内存、支持中文文件名、能明确反馈失败项、导出过程可被浏览器原生识别为.zip文件下载。整套方案基于纯 Java SE + Servlet 标准 API 实现，不引入 Spring Boot 自动配置黑匣子，所有关键路径都可调试、可替换、可审计。

2. 总体架构设计：三层结构与四个核心模块的职责划分

本方案采用清晰的三层职责分离：调度层（Controller）→ 执行层（Downloader & Zipper）→ 资源管理层（TempFileHandler & ResponseWriter）。不追求高并发吞吐，而强调单次任务的健壮性与可观测性。四个核心模块各自边界明确：

• URL 解析与校验模块：负责对输入的 URL 列表做基础合法性检查（协议头、格式、长度）、去重、并预生成 ZIP 条目名（避免非法字符、路径穿越）；
• 分段下载与缓存模块：不将全部文件加载进内存，而是按需下载到临时目录，每个文件对应独立File实例，并记录下载状态（成功/失败/超时）；
• 流式 ZIP 构建模块：使用ZipOutputStream配合BufferedOutputStream，但关键在于「每个 ZIP 条目必须在写入前完成其源文件的完整读取」，杜绝跨流复用；
• 响应封装与清理模块：将 ZIP 流直接写入HttpServletResponse.getOutputStream()，并在响应完成后异步清理临时文件（即使用户中途关闭浏览器，也要保证磁盘不泄漏）。

整个流程不依赖任何第三方 ZIP 工具库（如 Apache Commons Compress），仅使用 JDK 7+ 原生java.util.zip，降低部署复杂度和兼容风险。

2.1 URL 解析与条目名生成：防路径穿越与中文兼容

URL 输入通常来自前端表单或 JSON 接口，格式为字符串数组。我们不信任任何外部输入，必须做两件事：一是过滤非法协议，二是生成安全 ZIP 条目名。

public class SafeZipEntryNameGenerator { private static final String ILLEGAL_CHARS = "[\\\\/:*?\"<>|\\s]"; private static final int MAX_FILENAME_LENGTH = 100; public static String generateEntryName(String url) { try { String fileName = new URL(url).getPath(); // 提取最后一段作为文件名，保留扩展名 fileName = fileName.substring(fileName.lastIndexOf('/') + 1); // 移除查询参数和锚点（如 ?v=1#section） fileName = fileName.split("[?#]")[0]; // 替换非法字符为空格，再压缩空格 fileName = fileName.replaceAll(ILLEGAL_CHARS, " ").trim().replaceAll("\\s+", "_"); // 截断过长文件名，保留扩展名 if (fileName.length() > MAX_FILENAME_LENGTH) { String ext = ""; int dotIndex = fileName.lastIndexOf('.'); if (dotIndex > 0 && dotIndex > fileName.length() - 10) { ext = fileName.substring(dotIndex); fileName = fileName.substring(0, Math.min(dotIndex, MAX_FILENAME_LENGTH - ext.length())); } else { fileName = fileName.substring(0, MAX_FILENAME_LENGTH); } fileName += ext; } // 确保非空，兜底 if (fileName.isEmpty()) { fileName = "download_" + System.currentTimeMillis() + ".bin"; } return fileName; } catch (MalformedURLException e) { return "invalid_url_" + System.currentTimeMillis() + ".bin"; } } }

提示：这里没有用URLEncoder.encode()对整个 URL 编码，因为 ZIP 条目名是文件系统路径语义，不是 HTTP 传输语义。过度编码会导致解压后文件名乱码（如%E4%B8%AD%E6%96%87.txt）。我们只做「字符清洗 + 长度截断 + 合法扩展名保留」，确保 Windows/macOS/Linux 均可正常显示中文。

2.2 分段下载模块：带超时、重试与状态快照的可靠拉取

每个 URL 单独启动一次 HTTP 请求，不共享连接池，避免单点失败影响全局。关键设计点有三：
①固定超时策略：连接超时 5s，读取超时 30s，防止某个慢接口拖垮整个任务；
②有限重试机制：对 5xx 错误重试 1 次（非幂等操作不盲目重试）；
③状态快照写入临时目录：下载完成即写入.done标记文件，便于断点续传（本方案暂不实现续传，但结构已预留）。

public class FileDownloader { private static final int CONNECT_TIMEOUT_MS = 5_000; private static final int READ_TIMEOUT_MS = 30_000; private static final int MAX_RETRY = 1; public DownloadResult download(String url, File targetFile) { int attempt = 0; Exception lastException = null; while (attempt <= MAX_RETRY) { try (InputStream in = openUrlStream(url); FileOutputStream out = new FileOutputStream(targetFile)) { byte[] buffer = new byte[8192]; int len; while ((len = in.read(buffer)) != -1) { out.write(buffer, 0, len); } // 下载成功，写入.done标记 File doneFile = new File(targetFile.getAbsolutePath() + ".done"); Files.write(doneFile.toPath(), "OK".getBytes(StandardCharsets.UTF_8)); return new DownloadResult(true, targetFile.length(), null); } catch (IOException e) { lastException = e; attempt++; if (attempt <= MAX_RETRY && isServerError(e)) { try { Thread.sleep(1000); // 退避1秒 } catch (InterruptedException ie) { Thread.currentThread().interrupt(); return new DownloadResult(false, 0, ie); } } } } return new DownloadResult(false, 0, lastException); } private InputStream openUrlStream(String url) throws IOException { HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection(); conn.setConnectTimeout(CONNECT_TIMEOUT_MS); conn.setReadTimeout(READ_TIMEOUT_MS); conn.setRequestMethod("GET"); conn.setInstanceFollowRedirects(true); conn.connect(); int responseCode = conn.getResponseCode(); if (responseCode >= 400) { throw new IOException("HTTP " + responseCode + " for " + url); } return conn.getInputStream(); } private boolean isServerError(Exception e) { return e.getMessage() != null && (e.getMessage().contains("500") || e.getMessage().contains("502") || e.getMessage().contains("503")); } }

注意：DownloadResult是一个不可变对象，包含success、size、error三个字段，供后续 ZIP 模块判断是否跳过该文件。所有异常都捕获并转化为结构化结果，不向上抛出，避免 Servlet 容器返回 500 页面。

2.3 流式 ZIP 构建模块：严格遵循 ZIP 条目生命周期

这是最容易翻车的模块。常见错误是：
❌ 在ZipOutputStream.putNextEntry()后，直接用httpConn.getInputStream()写入 —— 一旦网络抖动，流提前关闭，ZIP 结构损坏；
❌ 把多个FileInputStream套在同一个ZipOutputStream上，未及时closeEntry()—— ZIP 文件末尾 CRC 校验失败；
✅ 正确做法：每个 ZIP 条目必须对应一个已完全写入磁盘的本地文件，且putNextEntry()和closeEntry()必须成对出现，中间不得穿插其他 IO 操作。

public class ZipBuilder { public void buildZip(List<File> sourceFiles, List<String> entryNames, OutputStream outputStream) throws IOException { try (ZipOutputStream zos = new ZipOutputStream( new BufferedOutputStream(outputStream, 64 * 1024))) { zos.setMethod(ZipOutputStream.DEFLATED); zos.setLevel(Deflater.BEST_COMPRESSION); for (int i = 0; i < sourceFiles.size(); i++) { File file = sourceFiles.get(i); String entryName = entryNames.get(i); // 1. 创建 ZIP 条目，指定编码为 UTF-8（JDK7+ 默认支持） ZipEntry entry = new ZipEntry(entryName); entry.setSize(file.length()); entry.setTime(file.lastModified()); // 2. 写入条目头 zos.putNextEntry(entry); // 3. 安全写入内容：必须确保 file 存在且可读 if (file.exists() && file.isFile() && file.canRead()) { try (FileInputStream fis = new FileInputStream(file)) { byte[] buffer = new byte[8192]; int len; while ((len = fis.read(buffer)) != -1) { zos.write(buffer, 0, len); } } } else { // 文件异常，写入空文件占位（便于用户感知缺失） zos.write(new byte[0]); } // 4. 关闭当前条目 —— 这一步强制刷新缓冲区并写入 CRC zos.closeEntry(); } } } }

提示：setLevel(Deflater.BEST_COMPRESSION)并非总是最优。实测中，对小文件（<1MB）启用BEST_COMPRESSION反而增加 CPU 开销且压缩率提升不足 5%。生产环境建议改为Deflater.DEFAULT_COMPRESSION，平衡速度与体积。

3. 关键实现细节：Servlet 层整合与响应头精准控制

本方案最终以标准 Servlet 形式交付，不绑定 Spring MVC。这意味着我们必须手动处理请求解析、响应头设置、流写入时机、异常降级等底层逻辑。重点不在“能不能跑”，而在“跑得稳、看得清、断得干净”。

3.1 请求接收与参数校验：支持 JSON 数组与 form-data 两种方式

前端可能通过 POST/api/download-zip提交 JSON：

{ "urls": ["https://example.com/a.pdf", "https://example.com/b.jpg"] }

也可能用<form enctype="multipart/form-data">提交多行文本域。我们统一抽象为List<String>，并在入口处做强校验：

@WebServlet("/api/download-zip") public class ZipDownloadServlet extends HttpServlet { private static final long MAX_TOTAL_SIZE_MB = 500L; private static final int MAX_URL_COUNT = 100; @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { List<String> urls = parseUrlsFromRequest(req); if (urls == null || urls.isEmpty()) { sendError(resp, 400, "URL list is empty or invalid"); return; } if (urls.size() > MAX_URL_COUNT) { sendError(resp, 400, "Too many URLs, max " + MAX_URL_COUNT); return; } // 计算理论最大体积（保守估计：每个 URL 最大 5MB） long estimatedSize = urls.size() * 5L * 1024 * 1024; if (estimatedSize > MAX_TOTAL_SIZE_MB * 1024 * 1024) { sendError(resp, 400, "Estimated download size exceeds " + MAX_TOTAL_SIZE_MB + " MB"); return; } // 执行主流程 handleDownloadRequest(urls, req, resp); } private List<String> parseUrlsFromRequest(HttpServletRequest req) throws IOException { String contentType = req.getContentType(); if (contentType != null && contentType.contains("application/json")) { StringBuilder json = new StringBuilder(); String line; BufferedReader reader = req.getReader(); while ((line = reader.readLine()) != null) { json.append(line); } try { JsonObject obj = JsonParser.parseString(json.toString()).getAsJsonObject(); JsonArray arr = obj.getAsJsonArray("urls"); List<String> list = new ArrayList<>(); for (JsonElement e : arr) { list.add(e.getAsString().trim()); } return list; } catch (Exception e) { return null; } } else { // form-data or x-www-form-urlencoded String urlsParam = req.getParameter("urls"); if (urlsParam == null || urlsParam.trim().isEmpty()) return null; return Arrays.stream(urlsParam.split("\\r?\\n")) .map(String::trim) .filter(s -> !s.isEmpty()) .collect(Collectors.toList()); } } }

注意：这里没有用@RequestBody或@RequestParam，而是手动解析，确保对 Servlet 容器版本（Tomcat 8/9/10、Jetty、Undertow）无强依赖。JsonParser来自com.google.gson，仅用于轻量 JSON 解析，可替换为org.json或 Jackson。

3.2 响应头设置：让浏览器正确识别为 ZIP 下载

很多同学只写Content-Type: application/zip，结果 Chrome 下载后自动解压、Safari 显示为文本。真正起作用的是Content-Disposition头：

private void setupResponseHeaders(HttpServletResponse resp, String zipFileName) { // 强制下载，不内联显示 resp.setHeader("Content-Disposition", "attachment; filename*=UTF-8''" + encodeFilename(zipFileName)); // MIME 类型必须准确 resp.setContentType("application/zip"); // 禁用缓存，避免旧 ZIP 被复用 resp.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); resp.setHeader("Pragma", "no-cache"); resp.setDateHeader("Expires", 0); // 设置预期大小（可选，提升浏览器进度条体验） // resp.setContentLengthLong(totalEstimatedSize); // 实际大小需 ZIP 完成后才能知道，此处不设 }

private String encodeFilename(String filename) { try { return URLEncoder.encode(filename, StandardCharsets.UTF_8) .replace("+", "%20") .replace("*", "%2A") .replace("~", "%7E"); } catch (UnsupportedEncodingException e) { return filename; // fallback } }

提示：filename*=UTF-8''xxx是 RFC 5987 标准写法，Chrome/Firefox/Edge 全支持，Safari 14+ 支持。老版本 Safari 可降级为filename="xxx"，但会丢失中文。本方案优先保障新浏览器体验。

3.3 异常降级与兜底策略：当 ZIP 构建失败时，仍返回可用结果

理想情况是全部下载成功、全部打包成功。但现实是：某个 URL 返回 404、某个文件下载超时、磁盘满、ZIP 写入时IOException。我们不选择「全盘失败」，而是：

• 记录每个 URL 的下载与打包状态；
• 即使 ZIP 构建中途失败，也尝试将已成功打包的文件写入响应（只要ZipOutputStream还没 close）；
• 若 ZIP 流已损坏，改用「单文件下载」降级：将第一个成功下载的文件直接返回，Header 设为Content-Disposition: attachment; filename="first_file.pdf"。

private void handleDownloadRequest(List<String> urls, HttpServletRequest req, HttpServletResponse resp) { TempFileManager tempManager = new TempFileManager(); List<File> downloadedFiles = new ArrayList<>(); List<String> entryNames = new ArrayList<>(); List<DownloadResult> results = new ArrayList<>(); try { // Step 1: 下载所有文件到临时目录 for (String url : urls) { String entryName = SafeZipEntryNameGenerator.generateEntryName(url); File tempFile = tempManager.createTempFile("dl_", ".tmp"); DownloadResult result = new FileDownloader().download(url, tempFile); results.add(result); if (result.isSuccess()) { downloadedFiles.add(tempFile); entryNames.add(entryName); } } // Step 2: 设置响应头 String zipName = "batch_download_" + System.currentTimeMillis() + ".zip"; setupResponseHeaders(resp, zipName); // Step 3: 构建 ZIP（关键：try-with-resources 保证流关闭） try (OutputStream out = resp.getOutputStream()) { new ZipBuilder().buildZip(downloadedFiles, entryNames, out); } catch (IOException e) { // ZIP 构建失败，但至少有一个文件成功？降级为单文件下载 if (!downloadedFiles.isEmpty()) { File firstFile = downloadedFiles.get(0); String firstEntry = entryNames.get(0); resp.reset(); resp.setHeader("Content-Disposition", "attachment; filename*=UTF-8''" + encodeFilename(firstEntry)); resp.setContentType(getMimeTypeByExtension(firstEntry)); Files.copy(firstFile.toPath(), resp.getOutputStream()); return; } else { throw e; // 无可用文件，抛出原始异常 } } } catch (Exception e) { sendError(resp, 500, "Download failed: " + e.getMessage()); } finally { // 异步清理临时文件（即使响应已写出，也要清理） tempManager.cleanupAsync(); } }

注意：TempFileManager.cleanupAsync()内部使用ScheduledExecutorService延迟 5 秒执行deleteOnExit()或Files.deleteIfExists()，避免在流未完全写出时就删文件（Windows 下会报AccessDeniedException）。

4. 避坑指南：五个高频翻车点与血泪排查经验

这套方案看似简单，但在真实课设答辩或上线过程中，以下五类问题出现频率极高。它们往往不报错，但导致 ZIP 解压失败、文件名乱码、浏览器卡死、磁盘爆满——属于「静默崩溃」，极难定位。

4.1 现象：ZIP 解压后部分文件大小为 0，但下载日志显示“success”

原因：FileDownloader.download()方法中，out.write(buffer, 0, len)后未调用out.flush()，且FileOutputStream构造时未启用append=false（默认就是 false，但若误用new FileOutputStream(file, true)就会追加写入，导致文件头污染）。更隐蔽的是：某些 JDK 版本在out.close()前未flush()，缓冲区数据丢失。

解决：
✅ 所有FileOutputStream必须显式flush()（虽然close()会 flush，但为保险起见，在close()前加flush()）；
✅ 禁止使用FileOutputStream(File, true)构造函数；
✅ 在DownloadResult中增加actualWrittenBytes字段，与file.length()比对，不一致则标记为失败。

4.2 现象：中文文件名在 Windows 解压后显示为乱码（如文件名.pdf）

原因：ZIP 规范本身不强制指定文件名编码，JDK 6 及以前默认用System.getProperty("file.encoding")（通常是 GBK），而 JDK 7+ 默认用 UTF-8。但 Windows 资源管理器默认用系统编码（GBK）解码，导致错位。

解决：
✅ 使用ZipEntry构造时，不调用setExtra()或setComment()，避免触发 JDK 的 legacy 编码逻辑；
✅ 确保ZipOutputStream创建时未设置setEncoding("GBK")（这是最常见错误！）；
✅ 统一使用new ZipEntry(name)，name 必须是String（而非byte[]），且 name 本身已为合法 UTF-8 字符串（由SafeZipEntryNameGenerator保证）；
✅ 测试时用 7-Zip 打开 ZIP，查看「文件名编码」是否显示为 UTF-8。

4.3 现象：Servlet 响应返回 200，但浏览器下载的 ZIP 打不开，提示“文件已损坏”

原因：resp.getOutputStream()被多次获取。例如：在setupResponseHeaders()后又调用了一次resp.getOutputStream()，或在try-with-resources外部提前调用了getOutputStream()。Servlet 规范规定：getOutputStream()和getWriter()互斥，且只能调用一次。

解决：
✅ 严格遵循「一个请求，一个输出流」原则；
✅ 所有OutputStream获取必须在try (OutputStream out = resp.getOutputStream()) { ... }内完成；
✅ 删除所有resp.getOutputStream()的重复调用，包括日志打印、调试输出等；
✅ 在handleDownloadRequest()开头加断言：if (resp.isCommitted()) throw new IllegalStateException("Response already committed");。

4.4 现象：下载大文件（>100MB）时 Tomcat 报OutOfMemoryError: Java heap space

原因：误将整个 ZIP 流缓存在内存（如用ByteArrayOutputStream收集 ZIP 数据，再writeTo(resp.getOutputStream())），导致堆内存爆炸。

解决：
✅绝对禁止使用ByteArrayOutputStream；
✅ 必须使用resp.getOutputStream()直接写入，配合BufferedOutputStream（8KB~64KB 缓冲区足够）；
✅ 在ZipBuilder.buildZip()中，每个FileInputStream必须try-with-resources，确保及时释放文件句柄；
✅ JVM 启动参数增加-XX:+UseG1GC -Xmx512m（对 500MB 总下载量足够）。

4.5 现象：用户点击下载按钮后，页面卡住 30 秒无响应，Nginx 报 504 Gateway Timeout

原因：Servlet 容器（如 Tomcat）默认connectionTimeout=20000ms，而 Nginx 默认proxy_read_timeout=60s。当 ZIP 构建耗时超过 20 秒，Tomcat 主动断开连接，Nginx 收不到响应，返回 504。

解决：
✅ Tomcatserver.xml中，<Connector>标签增加connectionTimeout="120000"（2分钟）；
✅ Nginx 配置中，对应 location 块增加proxy_read_timeout 120;；
✅ 更优方案：前端增加「请稍候」Loading 提示，并在后端返回text/event-stream进度事件（本方案未实现，但可扩展）；
✅ 生产环境务必添加@WebServlet(asyncSupported = true)并启用异步处理，避免阻塞容器线程池。

5. 验收与答辩技巧：从「能跑」到「值得打高分」的四步验证法

毕设或课设答辩，老师最常问的不是「你用了什么技术」，而是「你怎么证明它真的work？」。我带过三届学生做类似项目，发现能一次性通过验收的，都做了这四步验证。不是走形式，而是把「黑匣子」变成「透明流水线」。

5.1 第一步：构造最小可验证用例（MVP Test）

不要一上来就测 20 个 URL。先准备一个「黄金测试集」：

• ✅https://httpbin.org/image/jpeg（稳定返回 JPG，大小约 20KB）
• ✅https://httpbin.org/bytes/1024（返回 1KB 随机二进制）
• ✅https://httpbin.org/status/404（故意失败）
• ✅https://httpbin.org/delay/5（模拟慢接口，5 秒响应）

用 Postman 发送如下 JSON：

{ "urls": [ "https://httpbin.org/image/jpeg", "https://httpbin.org/bytes/1024", "https://httpbin.org/status/404", "https://httpbin.org/delay/5" ] }

✅ 预期结果：

• ZIP 包含 3 个文件（jpeg、1024.bin、delay_5.bin）；
• status/404被跳过，不报错；
• 总耗时 < 15 秒（5s 延迟 + 下载 + 打包）；
• 解压后文件 MD5 与 httpbin 原始响应一致（可用curl -s https://httpbin.org/image/jpeg | md5sum验证）。

这一步必须手敲命令验证，不能只信浏览器。很多同学说「我点一下能下」，结果一用curl就 500 —— 因为没处理application/jsonContent-Type。

5.2 第二步：压力与边界测试（答辩加分项）

老师如果问「支持多少文件？」，别答「理论上无限」。拿出真实数据：

如何测？写一个 Python 脚本批量调用，记录time.time()差值。重点看「耗时是否线性增长」—— 如果 50 个花 8s，100 个花 30s，说明有锁竞争或 GC 问题，要查jstat -gc。

5.3 第三步：日志与可观测性埋点（体现工程素养）

答辩时打开日志，比讲一百句「我用了多线程」都有力。在关键路径插入结构化日志：

// 下载开始 log.info("DOWNLOAD_START: url='{}', attempt={}", url, attempt); // 下载成功 log.info("DOWNLOAD_SUCCESS: url='{}', size={}B, time={}ms", url, file.length(), durationMs); // ZIP 条目写入 log.debug("ZIP_ENTRY_WRITE: name='{}', size={}B", entryName, file.length()); // 响应完成 log.info("RESPONSE_COMMITTED: zipName='{}', totalEntries={}, totalTime={}ms", zipName, entryNames.size(), System.currentTimeMillis() - startTs);

✅ 日志级别合理：INFO 记录关键节点，DEBUG 记录细节（需-Dlogging.level.xxx=DEBUG开启）；
✅ 所有日志含唯一 traceId（可用ThreadLocal<String>生成 UUID），方便串联请求；
✅ 不记录敏感信息（如完整 URL 中的 token 参数，用正则脱敏）。

5.4 第四步：答辩陈述话术设计（避开致命陷阱）

老师常问：「如果用户下载到一半关掉浏览器，临时文件会清理吗？」
❌ 错误回答：「我用了deleteOnExit()，会自动删。」
✅ 正确回答：「deleteOnExit()只在 JVM 退出时触发，不适用于 Web 容器长期运行场景。我的方案是：在finally块中调用tempManager.cleanupAsync()，它提交一个延迟 5 秒的清理任务。这个延迟是为了确保响应流已完全写出（特别是大文件，内核缓冲区可能未刷盘）。同时，我在TempFileManager中维护了ConcurrentHashMap<File, Long>记录创建时间，定期扫描超 10 分钟的残留文件，避免磁盘泄漏。」

老师问：「为什么不用 Spring Boot 的StreamingResponseBody？」
✅ 回答：「StreamingResponseBody本质仍是OutputStream封装，底层并无新 IO 模型。本方案刻意使用原生 Servlet API，是为了剥离框架抽象，确保每个字节的流向都可追溯、可调试。比如 ZIP 的CRC计算、条目头写入时机，这些在 Spring 封装下是黑盒。而课设要求体现对基础原理的掌握，所以选择了更『裸』但更可控的方式。」

从那以后我每次做导出类功能，都强制走一遍这四步验证：MVP → 压力 → 日志 → 话术。不是为了应付答辩，而是因为线上出过一次事故——某个 CDN 返回 304 Not Modified，但我们的FileDownloader没判断conn.getResponseCode()，直接读取了空流，导致 ZIP 里塞了个 0 字节文件，用户投诉「下载的合同是空白的」。那次之后，我把DownloadResult的isSuccess()判断逻辑，从「是否抛异常」升级为「是否返回 2xx 且 content-length > 0」，并加了Content-Type白名单校验。希望帮到你。

本文还有配套的精品资源，点击获取