Java后端大文件分块上传实战：从原理到断点续传与性能优化

在JAVA web应用里折腾超大附件上传，几乎是每个后端工程师都绕不过去的坎。视频文件、日志包、设计稿压缩包、数据库备份文件，动不动就是几个G起步。你要是直接用传统的multipart/form-data方式一次性提交，轻则后端内存飙到Red线，重则请求超时直接断连，最后前端报个“网络异常”，用户一脸懵，你还得背锅。解决这个问题的主流方案就是分块上传，也叫分片上传、chunked upload，核心思路很简单：把大文件切成若干小块，逐块上传，最后在后端合并。这篇文章我会从设计思路讲到Java后端的具体实现，再把断点续传、并发控制、资源清理这些坑一个个掰开揉碎，希望能给正在做类似需求的你一些直接能落地的参考。

1. 为什么超大附件必须分块上传

1.1 传统单文件上传的两个硬伤

先聊聊为什么不能直接传大文件。常规的web上传流程里，浏览器把整个文件放进HTTP请求体，后端通过Servlet或Spring MVC的MultipartFile接收。问题在于，这个过程中文件内容通常是先被读到服务端内存或临时目录里的。JVM的堆内存默认一般来说也就几个G，你给Tomcat、Spring Boot容器一分配，实际能留给上传缓冲的更少。如果文件是2个G，一次上传很可能直接触发java.lang.OutOfMemoryError: insufficient memory，这也就是开发时经常看到的那类内存溢出异常。

还有一个硬伤是网络稳定性。大文件传输耗时久，期间只要Wi-Fi闪断、手机切网、服务器重启，整个上传就前功尽弃。用户得从头再来，体验极其糟糕。分块上传恰好能同时解决这两个问题：每块数据量小，内存压力低；上传过程被切分成多个小请求，失败后只需要重传失败的块，不需要重新传整个文件。

1.2 分块上传能解决什么问题

分块上传的核心价值，是让“上传”这件事从一次性大事务变成可重试、可恢复的小批次操作。从用户视角看，上传大文件时能看到进度条稳步前进，断网了重新连上还能接着传，不会因为等待太久而焦虑。从服务端视角看，每一块的数据量可控，请求占用时间短，Tomcat的工作线程不会被长时间占用，整体并发能力也更好。

而且在做文件秒传和断点续传的时候，分块上传几乎是最省事的实现载体。比如我们会在文件上传前先算一个全局MD5，服务端如果发现这个MD5对应的文件已经存在，直接返回“秒传”成功，根本不需要真的传内容。分块机制也会顺带支持块级别的MD5校验，块损坏了就重传那一块，不需要整体重传。

1.3 适用场景与阈值建议

也不是所有场景都非要分块。如果一个文件只有几十兆，老老实实用一次性普通上传就够了，引入分块反而增加复杂度。我一般建议是：单个文件超过200MB，或者你对断点续传有明确要求时，才考虑走分块上传。具体阈值要根据业务来定，比如某些网盘产品把阈值定在128MB，有些定在512MB。我们团队在做一个内部素材平台时，定的规则是小于100MB走普通上传，大于等于100MB自动切换分块上传，实测下来效果比较稳。

除了文件大小，还要考虑用户的使用场景。如果用户大概率是在办公室固定网络下上传，网络很稳定，那么分块上传的必要性没那么迫切；如果用户分布在移动网络、跨地域、弱网环境，那分块加断点续传就是刚需。

2. 分块上传的整体设计思路

2.1 一个可靠分块方案的五个关键环节

一个完整的可落地分块上传方案，绝不是单纯把文件切几份就算完事。我之前见过不少实践，前端切块后一个劲往上发，后端收到就写磁盘，到最后合并时才发现块丢了或者顺序乱了。一个可靠方案至少包含五个环节：创建上传任务、逐块上传、校验块完整性、合并文件、清理临时数据。

创建上传任务时，前端先把文件名、文件大小、分块大小、总块数以及文件唯一标识（一般用MD5或SHA256）发给后端，后端生成一个uploadId（或者叫taskId），把元信息保存下来。逐块上传时，前端带上uploadId、块索引和块数据，后端收到块之后先落盘，并记录当前块的状态。全部块传完后，前端调用一个“完成上传”接口，后端校验所有块是否齐全、大小是否符合预期，然后按顺序合并，合并后再做一次整体校验。校验通过后，把临时块文件清理掉，返回最终文件访问地址。

2.2 前端分块策略：固定分块大小还是动态分块

这件事很多文章会忽略，但恰恰很影响体验。固定分块大小最简单，比如每块5MB或10MB，代码好写，逻辑也直观。但固定分块在弱网环境下有个问题：某个块传输速度很慢，或者某个块反复失败，你就得整块重传。动态分块可以根据网络情况动态调整块大小，比如网速好时用大块，网速差时自动降为小块，但它需要前端有网络检测逻辑，复杂度高不少。

我的建议是，第一版就老老实实用固定分块。对绝大多数业务来说，10MB一个块是比较均衡的选择。分块太小，比如1MB，会导致请求数量过多，网络握手和HTTP头开销占比变大；分块太大，比如50MB，又失去了分块的意义，弱网下某个块失败的成本太高。另外要留意浏览器和服务器对单个请求体大小的限制，通常10MB不会触发Nginx的client_max_body_size默认限制，但如果你改了Nginx配置，也要同步确认。

2.3 后端如何设计上传接口

后端接口设计，我推荐按“三个接口+一个辅助接口”拆分。

• POST /upload/init：用于初始化上传任务，前端把文件摘要信息传过来，后端返回uploadId。
• POST /upload/chunk：用于上传单个分块。请求体里包含uploadId、chunkIndex、chunkData（二进制内容）以及其他校验参数。
• POST /upload/complete：用于合并文件。前端在全部块上传完毕后调用，后端执行合并和校验。
• GET /upload/status：可选，用于前端获取已上传的分块列表，支持断点续传。

有些设计方案会把“合并”放在一个异步任务里，complete接口只负责通知后端“块都传完了”，然后立刻返回“合并中”，真正的合并操作丢到消息队列或线程池里做。对大文件来说，合并是一个消耗CPU和磁盘IO的过程，同步执行会让前端等待太久，用户体验不好。不过实现异步合并且要处理好状态轮询，我建议第一版做同步合并，文件大到GB级别时再改成异步。下面具体实现部分我按同步合并讲，更直观，也更容易调试。

3. 核心实现：Java后端处理分块上传

3.1 环境与依赖准备

这里我以Spring Boot 2.x作为基础，JDK 1.8以上就够了。项目里除了spring-boot-starter-web，建议加一个hutool工具包或者commons-io，方便做文件操作。Hutool的IoUtil和FileUtil用起来比较顺手，省去写大量IO样板代码。Maven依赖大致如下：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>cn.hutool</groupId>
    <artifactId>hutool-all</artifactId>
    <version>5.8.25</version>
</dependency>

存储结构上，建议在某个工作目录下按uploadId建子目录。例如：

code复制/upload_tmp/{uploadId}/
    /chunks/
        0.tmp
        1.tmp
        2.tmp
    metadata.json

metadata.json保存文件元信息：原始文件名、文件总大小、分块大小、总块数、全局MD5等。所有分块都放在chunks下，用块索引作为文件名。这样合并时只需要按序读取0.tmp、1.tmp、2.tmp写到一个目标文件即可，不依赖数据库也能保证顺序。

3.2 初始化上传：创建上传任务

初始化接口的入参主要包括：filename、totalSize、chunkSize、totalChunks、identifier（全局MD5）。后端要做的事情是：

1. 校验参数合法，比如chunkSize大于0且totalChunks大于0。
2. 生成一个唯一的uploadId，推荐用UUID.randomUUID().toString().replace("-", "")，也可以结合时间戳加随机数。
3. 在临时目录下创建该uploadId对应的目录。
4. 把元信息写入metadata.json。

一个简单的Controller示例：

java复制@PostMapping("/upload/init")
public Result initUpload(@RequestBody UploadInitRequest req) {
    if (req.getTotalSize() <= 0 || req.getChunkSize() <= 0) {
        return Result.error("参数非法");
    }
    String uploadId = UUID.randomUUID().toString().replace("-", "");
    Path taskDir = Paths.get(workDir, uploadId);
    Path chunkDir = taskDir.resolve("chunks");
    try {
        Files.createDirectories(chunkDir);
        UploadMeta meta = new UploadMeta(uploadId, req.getFilename(),
                req.getTotalSize(), req.getChunkSize(), req.getTotalChunks(),
                req.getIdentifier(), System.currentTimeMillis());
        FileUtil.writeUtf8String(JSONUtil.toJsonPrettyStr(meta),
                taskDir.resolve("metadata.json").toFile());
        return Result.ok(uploadId);
    } catch (IOException e) {
        log.error("init upload error", e);
        return Result.error("初始化失败");
    }
}

这里有个容易忽略的点：metadata.json必须实时落盘，不能只存在内存里。否则服务重启后临时目录还在，但元信息丢了，后续没法合并。用文件存储比用数据库更简单可靠，也便于和临时块文件保持一致的生命周期。

3.3 分块上传处理：接收并临时存储

分块上传接口接收的是multipart文件，同时携带uploadId和chunkIndex。Spring MVC里可以用@RequestParam接收表单字段，@RequestParam("chunkData") MultipartFile chunkData接收文件。前端在生成FormData时需要把块数据放到chunkData字段上。

伪代码如下：

java复制@PostMapping("/upload/chunk")
public Result uploadChunk(@RequestParam("uploadId") String uploadId,
                          @RequestParam("chunkIndex") Integer chunkIndex,
                          @RequestParam("chunkData") MultipartFile chunkData) {
    Path chunkDir = Paths.get(workDir, uploadId, "chunks");
    if (Files.notExists(chunkDir)) {
        return Result.error("上传任务不存在");
    }
    if (chunkData.isEmpty()) {
        return Result.error("分块数据为空");
    }
    try {
        Path chunkFile = chunkDir.resolve(chunkIndex + ".tmp");
        chunkData.transferTo(chunkFile.toFile());
        return Result.ok();
    } catch (IOException e) {
        log.error("upload chunk error, uploadId={}, chunkIndex={}", uploadId, chunkIndex, e);
        return Result.error("分块上传失败");
    }
}

这段逻辑看起来简单，但细节藏在名字里：chunkIndex必须作为文件名，合并时才不会乱；uploadId是区分不同任务的命名空间，避免不同用户上传的文件互相覆盖；transferTo是Spring封装的方法，底层会先把上传内容写到临时文件中再做移动，比getInputStream手动读再写要高效。

实际生产环境我建议再加一层校验：限制单块大小，防止恶意请求塞入超大块。比如设定为分块大小的1.2倍或固定10MB+1MB余量。如果前端传来的块超过这个值，直接拒绝。同时要校验chunkIndex是否在0到totalChunks-1之间，避免非法路径遍历风险，像chunkIndex=-1或者超范围值直接返回错误。虽然这里的文件名是简单数字，但万一哪天改了拼接逻辑，路径穿越就来了。

3.4 完成上传：校验与合并文件

当前端所有块都传输完毕后，调用/upload/complete接口。后端核心工作有两块：校验所有块是否齐全；按顺序写入最终目标文件。

最简单也最稳妥的做法是用FileChannel进行管道传输，避免用FileInputStream一个个读再写，那样会有大量上下文切换。示例代码：

java复制@PostMapping("/upload/complete")
public Result completeUpload(@RequestParam("uploadId") String uploadId) throws IOException {
    Path taskDir = Paths.get(workDir, uploadId);
    Path chunkDir = taskDir.resolve("chunks");
    UploadMeta meta = readMeta(taskDir);
    // 校验块数
    for (int i = 0; i < meta.getTotalChunks(); i++) {
        Path chunkFile = chunkDir.resolve(i + ".tmp");
        if (Files.notExists(chunkFile) || Files.size(chunkFile) != expectedChunkSize(meta, i)) {
            return Result.error("第" + i + "块不完整，请重新上传");
        }
    }
    // 目标文件
    Path target = Paths.get(saveDir, uploadId + "_" + meta.getFilename());
    try (FileChannel out = FileChannel.open(target, StandardOpenOption.CREATE_NEW, StandardOpenOption.WRITE)) {
        for (int i = 0; i < meta.getTotalChunks(); i++) {
            try (FileChannel in = FileChannel.open(chunkDir.resolve(i + ".tmp"), StandardOpenOption.READ)) {
                long size = in.size();
                long written = 0;
                while (written < size) {
                    written += in.transferTo(written, size - written, out);
                }
            }
        }
    }
    // 合并后清理临时目录
    FileUtil.del(taskDir.toFile());
    return Result.ok("/files/" + target.getFileName());
}

这段代码有几个点需要说明。expectedChunkSize函数要区分“普通块”与“最后一块”：前面所有块的大小都等于chunkSize，只有最后一块可能小于chunkSize，因为文件总大小不一定刚好是分块大小的整数倍。具体计算方法：

java复制private long expectedChunkSize(UploadMeta meta, int index) {
    if (index < meta.getTotalChunks() - 1) {
        return meta.getChunkSize();
    }
    long lastSize = meta.getTotalSize() % meta.getChunkSize();
    return lastSize == 0 ? meta.getChunkSize() : lastSize;
}

合并时用transferTo循环写入，是因为FileChannel.transferTo在底层可能传输部分字节，不能假设一次调用就传完所有数据，所以写了个while循环确保块完全写入目标文件。CREATE_NEW参数可以防止目标文件已存在时被覆盖，如果合并过程中发现同名文件已存在，应该给用户返回“文件已存在”的提示，或者使用文件生成规则避免冲突。

3.5 关键技术细节：临时存储结构、块元数据、命名冲突

第一版的临时目录按uploadId隔离，基本可以解决并发冲突，但还存在一个隐藏问题：同一个用户重复上传同一个文件时，会创建两个uploadId，也就有两份分块，如果用户上传一半放弃，临时目录会越积越多。解决方案是定时清理：比如凌晨执行一个定时任务，把创建时间超过24小时的临时目录删除。同时可以提供一个“取消上传”接口，前端主动放弃时通知后端清理。

块元数据方面，除了metadata.json之外，还可以维护一个chunk-status.json，记录每个块的校验值。这个文件在断点续传时会用到，后面详细展开。

命名冲突这部分，最简单的策略是最终保存文件名带上uploadId前缀，确保每个上传任务生成的文件名全局唯一。如果你希望保留原始文件名供用户下载，可以把原始文件名保存在数据库字段里，展示时用原始名，物理文件名用系统生成的唯一名，两者解耦，避免中文名、特殊字符问题。

4. 断点续传与并发控制

4.1 断点续传的核心逻辑：秒传、续传、重传

断点续传的本质是“我告诉服务端已经传了哪些块，服务端只让我重新传缺失的块”。前端在初始化上传时，会把文件MD5（identifier）发给服务端。服务端拿到identifier后，先查一查有没有记录表明这个文件已经完整上传过。如果有，直接返回uploadId和“finished=true”标记，前端可以跳过所有上传步骤直接进入完成态，这就是秒传。

如果未完成，则根据identifier查询是否存在未完成的临时任务。如果存在，返回之前的uploadId，并附带上已经上传成功的块索引列表。前端据此把列表中缺少的块挑出来重新上传。这里我建议接口设计成：

java复制@GetMapping("/upload/status")
public Result getUploadStatus(@RequestParam("identifier") String identifier) {
    // 根据identifier查找临时任务和块状态
    UploadTask task = taskRepository.findUnfinished(identifier);
    if (task == null) {
        return Result.ok(new StatusVO(null, Collections.emptyList()));
    }
    List<Integer> uploadedChunks = findUploadedChunks(task.getUploadId(), task.getTotalChunks());
    return Result.ok(new StatusVO(task.getUploadId(), uploadedChunks));
}

前端在页面加载后、开始上传之前，先调用这个接口，根据返回的uploadId决定继续之前的上传，还是创建新任务。

4.2 并发上传环境下如何避免数据错乱

分块上传天然支持多个分块并发上传，前端可以一次发3个或5个HTTP请求分别传不同的块，速度会明显提升。但并发也要求服务端具备“无序写入、按序合并”的能力。也就是说，后端接收块的时候，不依赖块索引顺序，谁先到就先写谁的文件。合并阶段再按索引顺序读取。所以前面实现中用chunkIndex.tmp作为文件名的设计，天然支持无序写入。

另一个容易踩的坑是多个请求同时上传同一个块。比如前端因为超时重试，导致同一个chunkIndex的块被提交两次。如果后端只是简单的transferTo写同一路径，后写入的块会覆盖先写入的块。如果两次内容一致，那没问题；如果不一致，文件可能损坏。更稳的写法是：在写入分块之前，检查该块是否已存在且大小正确，如果已存在就直接返回成功，不重复覆盖。同时也可以对块做MD5校验，但由于全文件MD5是在前端计算的，块级别校验要单独算块MD5，增加了一点复杂度。我建议在服务端配置允许保留块级MD5字段的版本中，至少把“该块已存在则跳过”这个逻辑加上。

4.3 校验机制：MD5/SHA256与块索引校验

上传文件的一致性校验，可以从两个维度做。维度一：块级校验。每个块上传时携带该块的MD5，服务端写入后重新计算一次，与用户提交的MD5比对，不一致则返回错误，前端重传该块。维度二：文件级校验。全部块合并后，计算合并文件的MD5，与前端初始化时提交的全文件MD5比对。如果一致，说明整个上传链路没有丢数据；不一致，则说明某个块的内容有问题，此时需要返回错误并提示用户重新上传部分块。

文件级MD5的计算在大文件上比较耗时，比如1G的文件算一次MD5，可能耗时几百毫秒到数秒。所以一般放在合并后的异步任务里做，或者在前端显示“服务端校验中”的等待页面，给用户一个预期。想提升MD5计算性能，可以使用MessageDigest配合DigestInputStream，复用缓冲区，不要一个字节一个字节读。比如：

java复制MessageDigest md5 = MessageDigest.getInstance("MD5");
try (InputStream is = new DigestInputStream(Files.newInputStream(file), md5)) {
    byte[] buffer = new byte[8192];
    while (is.read(buffer) != -1) {
        // 直接读空即可，DigestInputStream内部会更新摘要
    }
}
byte[] digest = md5.digest();

这里提醒一个坑：使用DigestInputStream时，要确保循环读完全部数据，不能只读一部分就停下来，否则摘要不完整。我自己遇到过开发为了图省事只调了一次read就取摘要，最后校验总是失败。

5. 性能优化与资源管理

5.1 磁盘IO与临时文件清理

分块上传的后端瓶颈通常不在CPU或内存，而在磁盘IO。首先是临时文件的写入频率：每个分块都要写一次磁盘，如果分块大小很小、块数非常多，磁盘会被频繁写入。建议分块大小不要小于2MB，除非业务有特殊要求。其次是合并时的IO：把多个临时文件写入目标文件，本质上是一次串行复制过程，期间会产生大量磁盘读写。如果目标目录和临时目录在同一个磁盘分区，COPY速度会快一些；如果跨盘复制，速度还会受到更大影响。

临时文件清理必须有兜底策略。因为无论代码写得再严谨，总会出现用户传了一半关掉浏览器、服务端崩溃等异常场景。一个非常实用的做法是：创建临时目录时在元信息里记录创建时间，然后写一个@Scheduled定时任务，每60分钟扫描一次工作目录，删除超过24小时无人更新的任务目录。同时文件上传过程中，每次成功写入一个分块时，更新目录的lastModified时间，这样可以防止长时间断点续传任务被误删。这里要特别注意，断点续传的时间窗口不要设得太短，否则用户休息一晚第二天接着传，临时文件已经被清理了，体验会很难受。我一般建议保留48小时。

5.2 并发压力下的队列与线程池

虽然每个分块请求都很小，但大量并发分块上传请求同时到达时，会占用Tomcat的工作线程。如果Tomcat默认线程池是200，而某次上传任务一次性发来50个并发分块，那其他普通业务请求就可能被阻塞。所以在上传场景里，需要评估整体并发量，必要时给上传接口单独配置一个线程池执行器，或者用专门的Servlet线程池隔离上传流量。

但在大部分应用场景下，不需要一上来就引入消息队列。简单的做法是在Nginx层面对/upload/chunk接口设置合理的并发连接数限制，后端通过Spring Boot的server.tomcat.max-threads调整线程上限。或者把上传流量切到独立的域名和独立的Tomcat实例，彻底与业务隔离。如果团队规模不大，先不引入中间件，等单机确实扛不住再演进到对象存储加异步合并。

5.3 内存与大文件监控

分块上传降低了JVM堆内存的压力，但也不是完全没风险。原因在于Spring MVC接收MultipartFile时，如果文件块不大，默认会先存到内存，超过阈值才转存磁盘。Spring Boot的spring.servlet.multipart.max-file-size与max-request-size要设置得当。例如分块10MB，建议把max-file-size设为10MB，max-request-size设为10MB多一点。如果这两个参数设置得很大，比如2GB，那分块上传的内存优势就白费了。

监控方面，建议给JVM添加堆内存和GC日志的监控，额外对临时目录的磁盘占用做监控。临时文件累积到几十个G但没有清理，会直接把磁盘打满，这是生产环境非常常见的事故。可以在Actuator里暴露一个自定义指标，定时统计工作目录的大小，超过阈值就告警。

6. 常见问题与排查实录

6.1 问题速查表

这里整理了一些我在实际开发和联调过程中反复遇到过的典型问题，按现象、可能原因、解决方案列成表格，方便你快速定位。

6.2 实操心得：我在生产环境中踩过的坑

第一个坑是分块大小和Nginx配置不一致。当时我们前端把分块大小改成20MB，但Nginx的client_max_body_size还是默认1MB，导致所有分块请求都返回了413。排查了很久才发现是Nginx挡在前面，不是后端代码的问题。后来我们定了一个规矩：所有涉及上传的环境变更，都必须同时检查Nginx、Spring Boot、网关三层的body大小限制。

第二个坑是合并文件时用了FileUtil.writeFromStream之类的API，底层是逐个字节复制，速度很慢。一个2GB的文件合并耗时长达五六分钟，前端直接超时。后来换成了FileChannel.transferTo，同样的文件合并压到了几十秒左右，效果立竿见影。如果你的文件更大，还可以考虑多线程并行读取多个块合并写入，但对SSD以外的存储设备，收益有限，我一般不是特别推荐。

第三个坑是忽略了last-modified时间。我们最早做定时清理时，简单判断目录创建时间超过24小时就删。结果一个用户上传大文件，传到一半临时去开会，隔了几个小时回来自动续传，发现任务已经没了，只能从头传。后来改成每次接收分块时更新元信息文件的lastModified，清理逻辑也改成“超过48小时未更新”才算过期，才彻底解决这个问题。

第四个坑是前端重试上传同一个块时，后端返回了成功，但事实上块文件还没完全写完。这在网络良好的情况下不常见，但在高并发压力下可能发生：因为transferTo并不保证一次性写完，如果代码里没有while循环等待传输完成，返回成功的时间点可能过早。所以务必要在写完分块后做一次文件大小校验，确认写入长度等于前端声明的块大小，再返回成功。

还有一个小技巧：如果你们用Redis做分布式缓存，可以把“已上传的块索引集合”放在Redis的Set中，这样查询已上传块的性能比扫描文件目录好很多。同时把元信息对象也放进Redis，减少对磁盘的读取。没有Redis的情况下，文件系统扫描几百个块也不会很慢，优先保证简单可靠即可。

7. 后续还可以怎么扩展

如果你把基础版分块上传跑通了，接下来可以往两个方向扩展。一个是将上传组件对接云存储，比如OSS、COS或S3，把分块上传的后端从自建文件存储改成对象存储的分片上传接口，这样服务端只负责生成凭证和回调校验，既减轻了本地磁盘压力，也获得了对象存储自带的高可用能力。另一个是引入异步合并与事件机制，合并完成后发送Webhook通知业务系统，或者写入消息队列触发后续处理，比如视频转码、病毒扫描、压缩包解压等。

这些扩展本质上都是围绕“上传流程”演进，但基础的分块上传设计思路是不变的。我更建议先把本地存储版本做扎实，把上传任务状态机、校验机制、清理策略都梳理清楚，再考虑上云，这样不管切换到什么存储底座，核心流程都能快速适配。

在我个人的实际项目经验里，分块上传最容易被低估的一点，不是技术实现本身，而是对全链路的细节把握：前端切片策略、网络异常重试、后端临时文件生命周期管理、合并后的完整性校验，每一个环节都决定最终体验。如果你正准备在JAVA web应用里实现超大附件上传，先别急着堆代码，花半天时间把任务状态流转和异常边界想清楚，后面维护成本会小很多。最后分享一个习惯：每次上线前，用1GB左右的测试文件真的跑一遍断网续传、并发分块、合并校验，能提前暴露九成以上的问题。