MinIO 进阶：文件下载、批量获取与打包压缩全攻略

在文件服务器的日常开发中，文件下载远不止"点一下下载"那么简单。随着业务复杂度的提升，开发者往往需要面对：如何降低服务器带宽压力？如何实现几十个文件的批量导出？如何避免大文件压缩时的内存溢出（OOM）？

本篇将带你解锁 MinIO 文件下载的三种主流姿势，从基础到进阶，覆盖生产环境的各种核心场景。

---

1. 普通下载：单文件的两种路径

单文件下载是最基础的场景，但根据业务需求，通常有两种完全不同的实现方案。

姿势 A：预签名 URL（Presigned URL）

核心逻辑： 后端请求 MinIO 生成一个有时效性的加密链接，前端拿到后直接发起 GET 请求。

• 优点：文件下载流量直接经过 MinIO，不占用后端服务器带宽。
• 缺点：无法进行业务层面的权限细粒度控制（一旦 URL 发出，失效前谁都能下）。
• 适用场景：公共资源下载、对后端带宽敏感的高并发场景。

姿势 B：后端流式转发

核心逻辑： 后端调用 getObject 获取 InputStream，通过 Response 输出流传给前端。

• 优点：安全性最高。可以在转发前进行权限校验、下载计数、审计日志记录。
• 缺点：双倍带宽消耗（MinIO -> 后端 -> 前端），大文件时容易给服务器网卡带来压力。

---

2. 批量下载：并发获取与分发

当用户需要一次性获取多个文件（例如图片墙预览）时，如果前端循环发送几十个请求，会造成浏览器连接数阻塞。

技术核心：Java 线程池并发处理

我们可以利用 CompletableFuture 并发生成预签名链接，显著缩短响应时间。

代码示例：

// 假设 fileKeys 是需要下载的文件列表
List<CompletableFuture<String>> futures = fileKeys.stream()
    .map(key -> CompletableFuture.supplyAsync(() -> {
        try {
            return minioClient.getPresignedObjectUrl(
                GetPresignedObjectUrlArgs.builder()
                    .method(Method.GET)
                    .bucket("my-bucket")
                    .object(key)
                    .expiry(1, TimeUnit.HOURS)
                    .build());
        } catch (Exception e) {
            throw new RuntimeException("生成下载链接失败", e);
        }
    }, executor)) // 使用自定义线程池
    .collect(Collectors.toList());

// 等待全部完成并收集结果
List<String> downloadUrls = futures.stream()
    .map(CompletableFuture::join)
    .collect(Collectors.toList());

---

3. 多文件打包导出下载（核心进阶）

这是最考验功底的场景：用户选中多个文件，点击"打包下载"，后端生成一个 .zip 压缩包。

避坑指南：拒绝"落地"临时文件

很多初学者会先下载所有文件到服务器磁盘，压缩后再删除。这种做法在文件较多时会引发 磁盘 I/O 爆表 和 磁盘空间溢出。

优化方案：内存流式压缩（Streaming Zip）

利用 ZipOutputStream 结合 MinIO 的流式读取，实现一边读、一边压、一边下。

核心实现代码：

@GetMapping("/download/batch-zip")
public void downloadZip(@RequestParam List<String> fileNames, HttpServletResponse response) {
    // 1. 设置响应头，告知浏览器这是一个文件流
    response.setContentType("application/zip");
    response.setHeader("Content-Disposition", "attachment; filename=\"cloud_files.zip\"");

    try (ZipOutputStream zos = new ZipOutputStream(response.getOutputStream())) {
        for (String name : fileNames) {
            // 2. 从 MinIO 获取输入流
            try (InputStream is = minioClient.getObject(
                    GetObjectArgs.builder()
                        .bucket("my-bucket")
                        .object(name)
                        .build())) {
                
                // 3. 创建 ZipEntry 并写入流
                ZipEntry entry = new ZipEntry(name);
                zos.putNextEntry(entry);
                
                byte[] buffer = new byte[8192];
                int len;
                while ((len = is.read(buffer)) > 0) {
                    zos.write(buffer, 0, len);
                }
                zos.closeEntry();
            }
        }
        zos.finish();
    } catch (Exception e) {
        log.error("打包下载失败", e);
    }
}

---

4. 方案对比与生产总结

为了方便大家选型，我整理了下表：

下载姿势	带宽压力	开发难度	安全性	适用场景
预签名 URL	极低	★☆☆	中	开放资源、大流量
流式转发	高	★★☆	高	敏感数据、权限审计
批量链接	低	★★☆	中	页面展示、多点分发
打包压缩	中(CPU/内存)	★★★★	高	资料打包、离线导出

💡 生产环境小贴士：

1. 文件名乱码 ：在设置 Content-Disposition 时，针对中文文件名，一定要进行 URLEncoder.encode(fileName, "UTF-8") 处理。
2. 资源释放 ：MinIO 的 getObject 返回的是长连接流，必须在使用完毕后关闭，否则会导致 MinIO 连接池耗尽，系统直接瘫痪。
3. 大文件限额：如果打包文件总大小超过 1GB，建议改为"异步打包"，完成后通过站内信或邮件通知用户下载，避免前端请求超时和后端内存溢出。

---