Java大文件分片传输与合并：原理、实现与生产环境优化

1. 项目概述：为什么大文件传输需要分片？

在开发后台服务或者处理数据导入导出时，我们经常会遇到一个头疼的问题：如何安全、高效地传输一个几百兆甚至几十个G的大文件？直接通过HTTP流式上传？服务器内存可能瞬间撑爆。用FTP？集成和管理又太麻烦。这个问题在我处理一个分布式日志收集系统时变得尤为突出，当时需要将生产服务器上每日产生的数GB日志文件同步到中央分析服务器，传统的单次传输方式不是超时就是内存溢出，搞得人焦头烂额。

“Java针对大文件的分片传输与合并”这个方案，就是为了解决这个核心痛点。它本质上是一种“化整为零，聚零为整”的策略。想象一下搬一块巨大的石板，一个人扛不动，那就把它切割成许多小块，分给多个人搬运，到了目的地再重新拼接起来。分片传输也是同样的道理：在发送端，将一个大文件按固定大小（例如10MB）切割成多个独立的“分片”；然后，这些分片可以并行或顺序地上传到服务器；最后，在服务器端，再按照正确的顺序将这些分片重新合并，还原成原始文件。

这样做的好处是显而易见的。首先，它极大地降低了对单次请求内存的占用，每个分片都可以在可控的内存范围内处理。其次，它提升了传输的健壮性，即使某个分片传输失败，也只需要重传这个分片，而不必从头再来，这对于不稳定的网络环境至关重要。最后，它为并行上传和断点续传提供了可能，能充分利用带宽，显著提升大文件的传输效率。无论是构建网盘系统、视频处理平台，还是实现大数据文件交换，这套技术方案都是非常核心且实用的基础能力。

2. 核心设计思路与架构选型

在动手写代码之前，我们需要把整个流程的设计思路理清楚。一个健壮的分片上传合并系统，不能只考虑“切了传，传了合”这个理想路径，更要考虑各种异常情况和生产环境的需求。

2.1 整体流程拆解

整个流程可以清晰地划分为客户端（上传方）和服务端（接收方）两个角色，以及上传前、上传中、上传后三个阶段。

上传前（客户端）：

1. 文件指纹计算：在分片之前，先计算整个源文件的唯一标识（如MD5或SHA-256）。这个指纹有两个关键作用：一是用于服务端最终合并后的文件完整性校验，二是可以作为整个上传任务的唯一ID，避免重复上传。
2. 分片策略制定：确定分片大小。这里有个权衡：分片太小，会产生大量网络请求，增加开销；分片太大，则失去了分片的意义，内存和重传优势不明显。通常，1MB到10MB是一个比较常见的范围。我们可以根据文件大小动态调整，比如文件大于100MB时采用5MB分片。
3. 分片元信息生成：生成一个清单，记录文件总大小、总分片数、每个分片的序号、偏移量、大小以及该分片自身的哈希值（可选）。这个清单本身也会作为一个小的元数据文件上传，或者由客户端在初始化上传时提交给服务端。

上传中（客户端与服务端交互）：

1. 任务初始化：客户端将文件指纹、文件名、总分片数等信息发送给服务端，服务端检查该文件是否已存在（秒传），或是否存在未完成的上传任务（断点续传），并返回一个本次上传的uploadId。
2. 分片上传：客户端循环遍历所有分片，对于每个分片，读取其数据块，计算分片哈希，然后调用上传接口。请求中需要包含uploadId和分片序号chunkIndex。为了提高速度，可以使用线程池进行并发上传，但要注意控制并发数，避免压垮服务端或客户端自身。
3. 分片校验与重传：服务端接收到分片后，应立即计算其哈希值，与客户端传来的分片哈希进行比对。如果一致，则将该分片序号标记为“已接收”并持久化存储（如数据库或Redis）；如果不一致，则返回错误，客户端需要重传该分片。

上传后（服务端）：

1. 合并请求：当客户端确认所有分片均已上传成功后，向服务端发送一个“合并文件”的请求，携带uploadId。
2. 分片合并：服务端根据uploadId找到所有已存储的分片文件，按照序号顺序进行读取和拼接。这里的关键是顺序IO操作，避免随机读写带来的性能损耗。
3. 完整性校验：合并完成后，计算整个合并后文件的哈希值，与最初客户端提交的文件指纹进行比对。只有完全一致，才认为上传成功，将合并后的文件移动到最终存储位置，并清理临时分片文件。

2.2 技术栈选型考量

为什么用Java？因为Java在后台服务开发中生态成熟，NIO（Files、Path、FileChannel）提供了高效的文件操作能力，线程池模型完善，非常适合构建这种高可靠性的服务端逻辑。

• 网络框架：对于服务端，Spring Boot是不二之选，它能快速搭建RESTful API，方便处理上传请求。如果追求极致性能，可以考虑Netty，但Spring Boot+Servlet容器（如Tomcat）对于大多数场景已经足够，且开发效率更高。
• 分片存储：分片在合并前需要临时存储。不建议直接放在服务器的内存或临时目录，因为服务可能重启。更可靠的做法是：
  • 本地磁盘：为每个uploadId创建一个临时目录存放分片。简单直接，但要考虑磁盘空间和分布式部署时的文件共享问题。
  • 对象存储：如果系统本身就是云原生架构，直接将每个分片上传到云服务商的对象存储（如S3、OSS、COS），合并时再触发一个服务端任务去操作，这是最优雅和可扩展的方式。
  • 数据库（大对象）：不推荐。数据库擅长存结构化数据，频繁写入和读取大二进制对象会严重拖累性能。
• 状态管理：需要记录每个uploadId对应的上传进度。用内存Map？服务重启就全丢了。因此需要持久化：
  • 关系型数据库：创建一张upload_task表，字段包括upload_id,file_hash,total_chunks,status,uploaded_chunks_index（可存储为JSON数组或bitmap格式）。这是最清晰、查询最方便的方式。
  • Redis：使用Hash结构存储任务信息，用Set结构存储已上传的分片序号。性能极高，适合高并发场景，但需要处理数据持久化策略，防止Redis宕机数据丢失。
• 前端配合：前端可以使用成熟的库如axios配合File API的slice方法进行文件切割和并发上传，并做好进度条展示。

注意：分片大小的黄金法则：分片大小不是固定的。需要权衡网络MTU（最大传输单元，通常1500字节左右）、服务器请求处理能力、以及后端存储系统的性能。一个实用的经验是，对于内网高速环境，可以设置较大的分片（如10-20MB）以减少请求数；对于公网不稳定环境，设置较小的分片（如1-5MB）以提升重传效率和成功率。同时，要确保分片大小是服务器和客户端缓冲区大小的整数倍，以减少不必要的内存拷贝。

3. 核心实现细节与代码解析

理论讲完了，我们进入实战环节。我会用一个基于Spring Boot的服务端和简单Java客户端的例子，把关键代码掰开揉碎讲清楚。这里我们假设使用本地磁盘暂存分片，用数据库管理任务状态。

3.1 服务端：接收与存储分片

首先，定义分片上传的请求体。这里我们使用MultipartFile接收文件流，同时传递元数据。

@Data public class ChunkUploadRequest { // 上传任务唯一ID private String uploadId; // 当前分片序号（从0或1开始） private Integer chunkIndex; // 总分片数 private Integer totalChunks; // 整个文件的MD5（可选，用于最终校验） private String fileHash; // 文件名 private String filename; // 当前分片的大小 private Long chunkSize; // 当前分片的MD5（用于即时校验） private String chunkHash; }

对应的控制器（Controller）如下。关键点在于，我们不是直接保存上传的文件，而是将其保存到一个以uploadId命名的临时目录下，分片文件以索引号命名。

@RestController @RequestMapping("/api/upload") @Slf4j public class FileUploadController { @Autowired private FileStorageService storageService; @Autowired private UploadTaskService taskService; @PostMapping("/chunk") public ResponseEntity<?> uploadChunk(@RequestParam("file") MultipartFile file, ChunkUploadRequest request) { // 1. 参数基础校验 if (file.isEmpty() || request.getChunkIndex() == null || request.getUploadId() == null) { return ResponseEntity.badRequest().body("参数缺失"); } // 2. 校验上传任务是否存在且未完成（可从数据库查询） UploadTask task = taskService.getTask(request.getUploadId()); if (task == null || task.getStatus().equals(UploadStatus.COMPLETED)) { return ResponseEntity.badRequest().body("无效的上传任务"); } try { // 3. 计算接收到的分片的哈希值 String receivedChunkHash = DigestUtils.md5DigestAsHex(file.getInputStream()); // 与客户端传递的chunkHash比对，确保数据传输无误 if (!receivedChunkHash.equals(request.getChunkHash())) { log.warn("分片哈希校验失败，uploadId: {}, chunkIndex: {}", request.getUploadId(), request.getChunkIndex()); return ResponseEntity.status(HttpStatus.CONFLICT).body("分片校验失败，请重新上传"); } // 4. 保存分片到临时目录 Path chunkPath = storageService.saveChunk(file, request.getUploadId(), request.getChunkIndex()); log.info("分片保存成功: {}", chunkPath); // 5. 更新任务状态，标记该分片已上传成功（例如，在数据库记录中更新一个已上传索引的集合） taskService.updateChunkStatus(request.getUploadId(), request.getChunkIndex(), true); // 6. 检查是否所有分片都已上传完成 if (taskService.isAllChunksUploaded(request.getUploadId(), request.getTotalChunks())) { taskService.updateTaskStatus(request.getUploadId(), UploadStatus.READY_TO_MERGE); return ResponseEntity.ok().body(Map.of("message", "分片上传成功，所有分片已就绪，可触发合并")); } return ResponseEntity.ok().body(Map.of("message", "分片上传成功")); } catch (IOException e) { log.error("处理分片上传时发生IO异常", e); return ResponseEntity.internalServerError().body("服务器处理文件失败"); } catch (Exception e) { log.error("处理分片上传时发生未知异常", e); return ResponseEntity.internalServerError().body("服务器内部错误"); } } }

FileStorageService的saveChunk方法是核心，它负责将分片写入到正确的临时位置。

@Service public class FileStorageService { @Value("${app.upload.temp-dir:/tmp/uploads}") private String tempUploadDir; public Path saveChunk(MultipartFile file, String uploadId, Integer chunkIndex) throws IOException { // 构建临时目录路径，例如：/tmp/uploads/{uploadId}/ Path tempDir = Paths.get(tempUploadDir, uploadId); // 如果目录不存在，则创建（包含所有不存在的父目录） Files.createDirectories(tempDir); // 分片文件名，例如：chunk-001.part, chunk-002.part String chunkFilename = String.format("chunk-%03d.part", chunkIndex); Path chunkFilePath = tempDir.resolve(chunkFilename); // 将MultipartFile的内容传输到目标文件 // Files.copy 是Java NIO的高效方法 Files.copy(file.getInputStream(), chunkFilePath, StandardCopyOption.REPLACE_EXISTING); return chunkFilePath; } }

3.2 服务端：分片合并与校验

当所有分片上传完毕后，客户端会调用合并接口。合并操作是IO密集型任务，务必将其设置为异步操作，避免长时间阻塞HTTP线程。

@PostMapping("/merge") public ResponseEntity<?> mergeChunks(@RequestBody MergeRequest request) { String uploadId = request.getUploadId(); UploadTask task = taskService.getTask(uploadId); if (task == null || !task.getStatus().equals(UploadStatus.READY_TO_MERGE)) { return ResponseEntity.badRequest().body("无法合并：任务不存在或状态非法"); } // 异步执行合并任务 CompletableFuture.runAsync(() -> { try { storageService.mergeChunks(uploadId, task.getFilename(), task.getFileHash()); taskService.updateTaskStatus(uploadId, UploadStatus.COMPLETED); log.info("文件合并成功: uploadId={}, filename={}", uploadId, task.getFilename()); } catch (Exception e) { log.error("文件合并失败: uploadId={}", uploadId, e); taskService.updateTaskStatus(uploadId, UploadStatus.FAILED); // 这里可以增加重试机制或告警 } }, taskExecutor); // taskExecutor是一个自定义的线程池 return ResponseEntity.accepted().body(Map.of("message", "合并请求已接受，正在后台处理")); }

真正的合并逻辑在storageService.mergeChunks中。这里使用FileChannel进行合并，因为它能提供更高效的零拷贝或直接缓冲区操作，尤其适合大文件。

public void mergeChunks(String uploadId, String finalFilename, String expectedFileHash) throws IOException { Path tempDir = Paths.get(tempUploadDir, uploadId); Path finalFilePath = Paths.get(finalStorageDir, finalFilename); // 最终存储目录 // 1. 获取所有分片文件，并按序号排序 List<Path> chunkFiles; try (Stream<Path> stream = Files.list(tempDir)) { chunkFiles = stream .filter(path -> path.getFileName().toString().endsWith(".part")) .sorted((p1, p2) -> { // 从文件名中提取序号进行比较排序 int idx1 = extractIndex(p1.getFileName().toString()); int idx2 = extractIndex(p2.getFileName().toString()); return Integer.compare(idx1, idx2); }) .collect(Collectors.toList()); } if (chunkFiles.isEmpty()) { throw new IOException("未找到任何分片文件"); } // 2. 创建最终文件 Files.createDirectories(finalFilePath.getParent()); try (FileChannel destChannel = FileChannel.open(finalFilePath, StandardOpenOption.CREATE, StandardOpenOption.WRITE, StandardOpenOption.TRUNCATE_EXISTING)) { // 3. 顺序读取每个分片，并写入最终文件 for (Path chunkFile : chunkFiles) { try (FileChannel srcChannel = FileChannel.open(chunkFile, StandardOpenOption.READ)) { long transferred = 0L; long size = srcChannel.size(); // 使用transferTo进行高效的文件通道间传输，可能一次无法传输完 while (transferred < size) { transferred += srcChannel.transferTo(transferred, size - transferred, destChannel); } } log.debug("已合并分片: {}", chunkFile.getFileName()); } } // 4. 合并后校验文件完整性 try (InputStream is = Files.newInputStream(finalFilePath)) { String actualFileHash = DigestUtils.md5DigestAsHex(is); if (!actualFileHash.equals(expectedFileHash)) { // 校验失败，删除已合并的错误文件 Files.deleteIfExists(finalFilePath); throw new IOException(String.format("文件完整性校验失败！期望哈希: %s, 实际哈希: %s", expectedFileHash, actualFileHash)); } } // 5. 清理临时分片文件 cleanupTempDir(tempDir); log.info("文件合并与校验完成: {}", finalFilePath); } private int extractIndex(String filename) { // 简单实现，从 "chunk-001.part" 中提取 001 String num = filename.replace("chunk-", "").replace(".part", ""); return Integer.parseInt(num); } private void cleanupTempDir(Path dir) throws IOException { try (Stream<Path> walk = Files.walk(dir)) { walk.sorted(Comparator.reverseOrder()) .map(Path::toFile) .forEach(File::delete); } }

3.3 客户端：文件分片与上传

客户端负责将本地大文件分片，并协调上传过程。这里展示一个简化的Java客户端核心逻辑。

public class BigFileUploader { private final String serverUrl; private final ExecutorService executorService; public BigFileUploader(String serverUrl) { this.serverUrl = serverUrl; this.executorService = Executors.newFixedThreadPool(4); // 控制并发数 } public void upload(Path filePath, String targetFilename) throws Exception { // 1. 计算文件整体哈希和分片信息 String fileHash = calculateFileHash(filePath); long chunkSize = 5 * 1024 * 1024; // 5MB long fileSize = Files.size(filePath); int totalChunks = (int) Math.ceil((double) fileSize / chunkSize); // 2. 初始化上传任务（调用服务端接口，获取uploadId） String uploadId = initUploadOnServer(fileHash, targetFilename, totalChunks, fileSize); // 3. 准备分片上传任务列表 List<Future<?>> futures = new ArrayList<>(); for (int chunkIndex = 0; chunkIndex < totalChunks; chunkIndex++) { final int idx = chunkIndex; Future<?> future = executorService.submit(() -> { try { uploadSingleChunk(filePath, uploadId, idx, totalChunks, fileHash, chunkSize, fileSize); } catch (Exception e) { // 处理单个分片上传失败，这里可以实现重试逻辑 System.err.printf("分片 %d 上传失败: %s%n", idx, e.getMessage()); throw new RuntimeException(e); } }); futures.add(future); } // 4. 等待所有分片上传完成 for (Future<?> future : futures) { future.get(); // 会阻塞直到该分片任务完成（或异常） } // 5. 所有分片上传成功后，触发合并 triggerMergeOnServer(uploadId); System.out.println("文件上传流程已触发合并，请等待服务端处理。"); } private void uploadSingleChunk(Path filePath, String uploadId, int chunkIndex, int totalChunks, String fileHash, long chunkSize, long fileSize) throws IOException { // 计算当前分片的起始偏移量和实际大小（最后一个分片可能不满） long offset = chunkIndex * chunkSize; long actualChunkSize = Math.min(chunkSize, fileSize - offset); // 读取分片数据到字节数组 byte[] buffer; try (RandomAccessFile raf = new RandomAccessFile(filePath.toFile(), "r")) { raf.seek(offset); buffer = new byte[(int) actualChunkSize]; raf.readFully(buffer); } // 计算分片哈希 String chunkHash = DigestUtils.md5DigestAsHex(new ByteArrayInputStream(buffer)); // 构建 multipart/form-data 请求 HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.MULTIPART_FORM_DATA); MultiValueMap<String, Object> body = new LinkedMultiValueMap<>(); body.add("file", new ByteArrayResource(buffer) { @Override public String getFilename() { return "chunk"; } }); // 添加元数据 body.add("uploadId", uploadId); body.add("chunkIndex", chunkIndex); body.add("totalChunks", totalChunks); body.add("fileHash", fileHash); body.add("chunkHash", chunkHash); body.add("filename", filePath.getFileName().toString()); body.add("chunkSize", actualChunkSize); HttpEntity<MultiValueMap<String, Object>> requestEntity = new HttpEntity<>(body, headers); RestTemplate restTemplate = new RestTemplate(); // 调用服务端上传接口 ResponseEntity<String> response = restTemplate.postForEntity(serverUrl + "/api/upload/chunk", requestEntity, String.class); if (!response.getStatusCode().is2xxSuccessful()) { throw new IOException("上传失败，HTTP状态码: " + response.getStatusCode()); } System.out.printf("分片 %d/%d 上传成功.%n", chunkIndex + 1, totalChunks); } // 初始化上传和触发合并的方法实现略，主要是调用对应的服务端REST接口 private String initUploadOnServer(...) { ... } private void triggerMergeOnServer(...) { ... } }

4. 生产环境进阶考量与优化

把基础功能跑通只是第一步，要上线到生产环境，还需要考虑更多。

4.1 断点续传与幂等性设计

这是提升用户体验和系统健壮性的关键。核心在于服务端要能准确记录每个uploadId下，哪些分片已经上传成功。

• 实现：在UploadTask实体中，增加一个字段记录已上传的分片索引，例如uploadedChunks（可以是一个JSON数组[0, 1, 3, 4]，或者一个位图BitSet）。客户端在上传某个分片前，可以先查询一下该分片是否已上传（查询接口/api/upload/progress?uploadId=xxx）。如果已上传，则跳过，实现“秒传”分片的效果。
• 幂等性：上传分片的接口必须是幂等的。即客户端因网络超时等原因重传同一个分片时，服务端不能因为收到重复数据而出错。我们的实现已经具备这个特性：首先用chunkHash校验内容，内容相同则视为重复请求，直接返回成功并更新状态（如果之前没记录的话）；其次，保存文件时使用REPLACE_EXISTING选项，覆盖写即可。

4.2 并发控制与资源限制

无限制的并发上传会打爆服务器。

• 服务端限流：在Controller或网关层，对/api/upload/chunk接口进行限流。可以使用Guava的RateLimiter或Spring Cloud Gateway、Sentinel等工具，限制单个IP或全局的上传请求频率。
• 客户端控速：客户端不应一次性发起所有分片的上传请求。我们的示例使用了固定大小的线程池（如4个线程），这就是一种简单的并发控制。更高级的可以动态调整并发数，或实现一个带背压的上传队列。
• 资源清理：必须有一个后台定时任务，定期扫描临时目录和数据库中的上传任务记录，清理那些超过一定时间（如24小时）仍处于“未完成”或“待合并”状态的“僵尸任务”，释放磁盘和数据库空间。

4.3 分布式部署与存储一致性

当服务端是多实例部署时，问题变得复杂。

• 问题1：分片文件存储在哪？如果每个实例都将分片存在自己的本地磁盘，那么合并请求必须路由到存储了所有分片的那个实例，这很难做到。解决方案是使用共享存储，如NFS、Ceph，或者直接使用云对象存储。这样任何实例都能访问到所有分片。
• 问题2：上传状态如何同步？数据库记录是集中式的，没问题。但如果用了Redis，要确保Redis是高可用集群，避免单点故障导致状态丢失。
• 合并任务调度：合并操作是耗时的，最好由一个独立的、单实例的“合并服务”或通过分布式锁（如Redis Lock、ZooKeeper）来确保同一时间只有一个实例在处理某个uploadId的合并请求，防止重复合并。

4.4 安全与校验强化

• 分片哈希校验：我们已经在接口层面做了分片哈希校验，这是防止网络传输错误和数据篡改的第一道防线。
• 最终文件哈希校验：合并后的整体文件哈希校验是最终的安全屏障，必不可少。
• 恶意请求防护：要防止恶意用户上传海量小分片耗尽磁盘inode，或上传非法文件。可以在初始化上传时，对文件总大小、分片数量设置上限。在保存分片前，可以对文件内容进行简单的魔数检查（如图片、视频的头部字节）。

5. 常见问题排查与性能调优实录

在实际部署和运行中，你肯定会遇到下面这些问题。这里记录了我踩过的一些坑和解决办法。

5.1 问题一：合并文件时内存溢出（OOM）

• 现象：在合并几十GB的大文件时，服务进程突然崩溃，日志显示java.lang.OutOfMemoryError: Java heap space。
• 根因：最初的合并代码，是先将每个分片读入一个ByteArrayOutputStream，最后一次性写入。对于大文件，这会在内存中产生一个巨大的字节数组。
• 解决方案：必须使用流式合并。就像我们上面代码中使用FileChannel.transferTo()那样，它利用了操作系统的“零拷贝”技术，数据直接在磁盘缓冲区之间传输，无需经过Java堆内存。如果不能用NIO，用普通的BufferedInputStream和BufferedOutputStream，配合固定大小的缓冲区（如8KB）循环读写，也能有效避免OOM。

5.2 问题二：高并发上传时磁盘IO成为瓶颈

• 现象：上传接口响应变慢，服务器监控显示磁盘使用率持续100%，iowait很高。
• 根因：大量分片同时写入同一个机械硬盘，磁头频繁寻道，导致IOPS跟不上。
• 解决方案：
  1. 使用SSD：对于上传临时目录，优先使用SSD磁盘，其随机读写性能远胜于机械硬盘。
  2. 目录散列：不要把所有分片都放在/tmp/uploads/{uploadId}下。可以根据uploadId的哈希值，创建多层子目录（如/tmp/uploads/a1/b2/{uploadId}），将文件分散到不同的目录中，减轻单个目录的inode压力和某些文件系统的性能限制。
  3. 异步写入：如果性能要求极高，可以考虑引入一个消息队列。上传接口接收到分片后，不直接写磁盘，而是将分片数据（或存储路径）发送到队列。由一组独立的消费者进程异步地将数据写入持久化存储。这样可以将HTTP请求的响应时间与慢速的IO操作解耦。

5.3 问题三：网络不稳定导致分片上传频繁失败

• 现象：客户端日志显示大量上传超时或连接重置，特别是对于公网用户。
• 根因：网络抖动、防火墙策略、运营商限制都可能导致单次TCP连接不稳定。分片太大时，一次上传耗时过长，失败概率增加。
• 解决方案：
  1. 动态调整分片大小：客户端可以根据前几个分片的上传成功率、平均速度，动态调整后续分片的大小。例如，连续失败则减小分片大小。
  2. 指数退避重试：客户端上传失败后，不要立即重试。实现一个带指数退避的重试机制（如等待1秒、2秒、4秒...再重试），避免在网络临时故障时加剧服务端压力。
  3. 更小的分片：在公网环境下，将分片大小降至1MB甚至512KB，可以显著提升单次请求的成功率。虽然请求数变多，但每个请求更“轻”，更容易成功。

5.4 问题四：合并后文件损坏

• 现象：客户端提示上传成功，但下载合并后的文件，用专业软件（如压缩包、视频播放器）打开时报错，或文件哈希校验不通过。
• 根因：
  1. 分片顺序错乱：合并时没有按正确的索引顺序读取分片文件。我们的排序逻辑依赖于文件名解析，如果文件名格式不统一（如chunk-1.part,chunk-10.part按字符串排序会出问题），就会导致顺序错误。
  2. 分片数据被截断或污染：网络传输中数据包丢失，或服务端保存分片时发生异常，导致分片文件大小不对或内容错误。虽然我们有分片哈希校验，但如果校验逻辑本身有bug，或者保存文件过程中发生异常，也可能导致脏数据被误认为正确。
• 排查与解决：
  1. 强化排序逻辑：不要依赖简单的字符串排序。在分片元信息中明确记录序号，合并时严格按此序号处理。可以在数据库记录分片信息，或让分片文件名包含固定位数的序号（如%04d）。
  2. 双重校验：在合并每一个分片时，再次计算其哈希，与客户端最初上传时传来的chunkHash（应持久化在服务端）进行比对。确保合并所用的源数据是绝对正确的。
  3. 记录详细日志：在合并过程中，记录每个分片的预期大小、实际大小、哈希值。一旦合并失败，这些日志是定位问题分片的关键。

5.5 简易问题排查速查表

这套分片上传与合并的方案，从设计到实现，再到生产环境的打磨，几乎涵盖了文件传输场景下所有核心的技术要点。它不是一个炫技的框架，而是一个解决实际工程问题的扎实方案。理解并掌握它，不仅能让你轻松应对大文件传输的需求，更能深刻体会到如何设计一个高可靠、高可用的后端服务。在具体实施时，请务必根据你的业务规模、基础设施和团队技术栈，对上述方案进行适当的裁剪和增强。