1. 大文件传输的真实痛点与核心思路

做过文件服务的人多半都经历过这样的场景：用户上传一个几百兆甚至几个G的视频，进度条走到99%突然网络抖动，页面一刷新，一切归零，用户骂骂咧咧地重新点上传。或者后台要同步一批日志归档文件，传到一半连接被中间设备掐断，第二天发现只传了半个文件，还得从头再来。这类问题的本质，其实都指向同一个技术命题——HTTP协议下如何可靠地传输大文件，并且在中断之后能够接着传，而不是重头传。

HTTP本身是一个无状态的应用层协议，它天生不负责维护"传到哪里了"这种上下文。但这不代表它做不到断点续传，恰恰相反，HTTP/1.1规范里早就为这件事预留了完整的机制，核心就是两个东西：Range请求头和Content-Range响应头，配合206 Partial Content状态码。理解这套机制，你就能在任意语言、任意框架里手搓出一套可靠的大文件传输方案，而不是被某个现成的库绑死。

这篇文章面向的是真正要落地文件服务的开发者——可能是做网盘、做视频点播后台、做数据同步工具，也可能只是想让自家后台的文件上传别那么脆。我会从整体设计思路讲起，把分片、校验、并发、续传状态管理这些环节拆开揉碎，再给出一套可以直接抄作业的实现路径，最后把我踩过的坑和排查经验整理成速查表。全文不依赖任何特定框架，思路通用，你用什么语言都能套。

先说结论性的判断：大文件传输的关键不在于"传得快"，而在于"传得稳、可恢复、可校验"。很多人一上来就想着并发、多线程、加速，结果基础的分片和校验没做好，传得越快错得越离谱。我们先把地基打牢。

2. 断点续传的协议基础拆解

2.1 Range与Content-Range到底怎么配合

断点续传的协议层核心，是客户端告诉服务端"我要文件的第几字节到第几字节"，服务端回应"这是你要的那一段"。这个交互靠两个头字段完成。

客户端发起请求时带上Range头，格式是Range: bytes=start-end，比如Range: bytes=0-1048575表示要前1MB。服务端如果支持，就返回206 Partial Content状态码，并在响应头里带上Content-Range: bytes 0-1048575/10485760，斜杠后面是文件总大小。如果服务端不支持Range，它会忽略这个头，直接返回200 OK和整个文件——这时候客户端要能识别出来，否则会以为拿到了分片，实际拿到的是全量，逻辑就乱了。

这里有个容易被忽略的细节：Range的end是闭区间，bytes=0-1023是1024个字节，不是1023个。我见过有人按左闭右开算，结果每个分片少一个字节，最后拼出来的文件校验永远不过。这个坑很隐蔽，因为文件大小看着差不多，只有做哈希校验才会暴露。

还有一个边界情况：如果请求的范围超出了文件实际大小，规范要求返回416 Range Not Satisfiable，并在Content-Range里带上bytes */总大小。客户端收到416就应该知道，要么是自己算错了偏移，要么是文件在传输过程中被改小了，需要重新拉取元信息。

2.2 为什么分片大小不能拍脑袋定

分片大小是个需要权衡的参数，不是越大越好也不是越小越好。分片太大，单次请求耗时长，一旦中断损失的进度多，重传成本高；分片太小，请求数量暴涨，每个请求都有头和握手开销，整体吞吐反而下降，服务端的连接压力也大。

我的经验值是：内网环境用4MB到8MB，公网环境用1MB到4MB。这个区间是实测下来比较平衡的。公网之所以要小一点，是因为公网链路不稳定，小分片能让单次失败的影响范围可控，重传代价低。内网链路稳定，大分片能减少请求次数，提升吞吐。

你可以用一个简单的公式估算：假设平均单次请求的固定开销（建连、认证、头解析）约等于传输T字节数据的时间，那么分片大小取到让固定开销占比低于10%就比较划算。实际中不用算这么细，按上面的经验区间起步，再根据监控里的重传率和吞吐调整就行。

2.3 校验机制：别等传完才发现文件坏了

断点续传只保证"字节接得上"，不保证"内容是对的"。网络传输可能因为各种原因导致字节错位或损坏，所以必须有校验。校验分两个层次：

• 分片级校验：每个分片传完后，客户端和服务端各自算一次该分片的哈希（常用MD5或SHA-256），比对一致才认为这个分片有效。这样能快速定位坏片，只重传坏的那一片。
• 整体级校验：所有分片拼完后，对完整文件算一次哈希，和源文件的哈希比对。这是最后一道防线，确保拼出来的文件字节级正确。

分片级校验用MD5就够了，速度快；整体级校验如果对安全性有要求可以用SHA-256。注意，分片哈希要在分片数据落盘后立刻算，别等所有分片传完再回头算，那样内存和IO压力都大。

3. 一套可落地的大文件传输方案设计

3.1 整体流程：从元信息协商到分片合并

一套完整的方案，流程大致分五步，我把它拆成清晰的阶段，方便你对照实现。

第一步是元信息协商。客户端先向服务端查询目标文件的信息：文件是否存在、总大小多少、是否已经有一部分分片传过了。服务端返回一个文件标识（比如文件哈希或业务ID）、总大小、以及已接收的分片列表。这一步决定了后续是从头传还是续传。

第二步是分片规划。客户端根据总大小和选定的分片大小，算出总分片数和每个分片的字节范围。如果服务端返回了已接收的分片列表，客户端就跳过这些分片，只传缺失的。

第三步是分片上传。客户端逐个（或并发）上传分片，每个分片带上自己的序号和字节范围。服务端收到后先落盘到临时区，算分片哈希，和客户端声明的比对，一致就记录该分片已完成。

第四步是合并与整体校验。所有分片到齐后，服务端按序号顺序合并成完整文件，算整体哈希，和客户端提供的源文件哈希比对。一致则标记文件可用，不一致则触发重传或报错。

第五步是清理与确认。合并成功后清理临时分片，返回最终的文件访问地址给客户端。

这个流程里，元信息协商和分片规划是断点续传的关键。只要服务端能准确记录"哪些分片已经收到且校验通过"，客户端就能在任意时刻中断后重新协商，接着传。

3.2 服务端如何记录续传状态

续传状态记录是很多人做不好的地方。常见做法有两种：文件系统标记和数据库记录。

文件系统标记的思路是：每个分片落盘时用一个特定命名，比如{fileId}.part{index}，合并时扫描这个目录下有哪些part文件，就知道哪些分片到了。这种方案简单，不依赖额外存储，但并发场景下要注意原子性——两个请求同时写同一个part文件会冲突，需要用文件锁或者先写临时名再rename。

数据库记录更可控：建一张分片表，字段包括文件ID、分片序号、分片哈希、状态、落盘路径。每次分片上传成功就插一条或更新状态。查询续传进度时直接查这张表。这种方案的好处是状态清晰、可审计、支持多机部署（只要数据库共享），缺点是引入了数据库依赖，写入频繁时要注意性能。

我的建议是：单机小规模用文件系统标记，多机或需要精细管理的用数据库。如果走数据库，分片状态更新最好用"插入或忽略"的幂等写法，避免重复上传同一分片时主键冲突报错。

3.3 并发上传与顺序合并的平衡

并发上传能显著提升吞吐，尤其是高延迟链路下，多个分片同时在传能充分利用带宽。但并发带来两个问题：一是服务端要能处理同一文件的多个分片同时到达，二是合并时必须严格按序号顺序，不能乱。

解决第一个问题，服务端的每个分片写入要独立，互不干扰，用不同的临时文件或不同的数据库行。解决第二个问题，合并阶段单独做，等所有分片状态都是"已完成"后再触发，合并时按序号从小到大依次读取拼接。合并本身可以流式做，读一个分片写一段，不用把整个文件读进内存。

并发数不是越多越好。我实测下来，并发数控制在4到8之间比较稳。再高的话，客户端和服务端的连接数、内存占用都会上去，而且很多网络环境对单连接的限速不明显，但对总连接数有限制，开太多反而互相挤。你可以从4开始，观察吞吐和错误率再调。

4. 核心环节的实操实现

4.1 客户端分片与Range请求构造

客户端这一侧，核心是把文件切成片，并为每片构造正确的请求。下面用一段伪代码说明逻辑，语言无关，你翻译成自己用的语言即可。

def plan_chunks(total_size, chunk_size): chunks = [] start = 0 index = 0 while start < total_size: end = min(start + chunk_size - 1, total_size - 1) chunks.append({ "index": index, "start": start, "end": end, "size": end - start + 1 }) start = end + 1 index += 1 return chunks

注意end的计算用了min(start + chunk_size - 1, total_size - 1)，这样最后一片不会超出文件末尾。size是end - start + 1，闭区间长度。

构造请求时，把Range头设成bytes={start}-{end}，请求体放这一片的字节数据。如果是上传场景，通常用POST或PUT，把分片作为body；如果是下载场景，用GET带Range头。

这里有个实操细节：上传分片时，除了Range，还要在自定义头或表单字段里带上分片序号和分片哈希。序号用于服务端排序合并，哈希用于校验。别只依赖Range来推断序号，因为Range可能因为重试而重复，序号才是唯一标识。

4.2 服务端接收分片的落盘与校验

服务端收到分片后，动作顺序很关键。我推荐的顺序是：先校验分片哈希，再落盘，最后更新状态。

为什么先校验再落盘？因为如果哈希不对，这片数据就是坏的，落盘纯属浪费IO，还污染了临时区。先校验能尽早丢弃坏片，让客户端重传。

落盘时，写到以文件ID和分片序号命名的临时文件，比如/tmp/uploads/{fileId}/{index}.part。写完立刻fsync，确保数据真正落到磁盘，避免断电丢数据。这一步很多人省掉，结果机器一重启，状态记录说分片在，实际文件是空的。

状态更新要幂等。用数据库的话，可以INSERT ... ON CONFLICT DO NOTHING或者先查后插。用文件系统的话，落盘用临时名再rename成正式名，rename是原子操作，能避免半写状态被误认为完成。

4.3 合并阶段的顺序拼接与整体校验

合并是所有分片到齐后触发的。触发条件可以是"最后一个缺失分片上传成功"这个事件，也可以是一个独立的合并任务轮询检查。

合并逻辑本身不复杂：按序号从小到大，依次读取每个part文件，追加写入最终文件。用流式读写，每次读一块写一块，内存占用恒定。

def merge_chunks(file_id, total_chunks, final_path): with open(final_path, "wb") as out: for i in range(total_chunks): part_path = f"/tmp/uploads/{file_id}/{i}.part" with open(part_path, "rb") as part: while True: buf = part.read(1024 * 1024) if not buf: break out.write(buf) return final_path

合并完成后算整体哈希，和客户端提供的源哈希比对。一致就删掉临时分片目录，把最终文件移到正式存储位置；不一致就保留现场，记录日志，通知客户端重传或排查。

注意：合并期间要防止新的分片写入同一文件，否则会拼进错误数据。用一个"合并中"的状态锁住该文件，新分片请求直接拒绝或排队。

4.4 断点续传的协商接口设计

续传协商接口是整个方案的门面，设计好坏直接影响客户端体验。我建议这个接口返回结构化的进度信息，至少包含：

客户端拿到这个结构，就能算出还缺哪些分片，只传缺失的。uploadedChunks用列表而不是位图，是因为列表更直观，客户端处理也简单；如果分片数特别多（比如上万），可以用位图压缩传输，但一般场景列表够用。

这个接口要支持幂等查询，客户端可以在任意时刻调用，不会改变服务端状态。查询时如果发现文件已经合并完成，直接返回done和访问地址，客户端就不用再传了。

5. 常见问题与排查技巧实录

5.1 分片对不齐导致的文件损坏

这是最高频的问题。表现是：所有分片都显示上传成功，合并也完成了，但整体哈希对不上，文件打不开或者内容错乱。

排查思路：先确认分片边界计算是否正确。重点看最后一片的end是不是totalSize - 1，以及每片的size是不是end - start + 1。我遇到过有人把size算成end - start，每片少一字节，10片就少10字节，文件尾部直接截断。

另一个常见原因是并发上传时，服务端把分片写到了错误的序号。比如两个请求同时到达，服务端用了一个共享的计数器来分配序号，结果序号错乱。解决办法是序号由客户端在请求里明确带上，服务端只认客户端给的序号，不自己分配。

5.2 续传时状态与实际不符

表现是：协商接口说某分片已完成，但合并时发现那个part文件不存在或大小为0。

根因通常是状态更新和落盘的顺序问题。如果先更新状态再落盘，落盘失败时状态就成了脏数据。正确顺序永远是先落盘并fsync，再更新状态。如果用了缓存，还要注意缓存和持久存储的一致性，别让缓存里的旧状态覆盖了新状态。

还有一种情况是临时文件被清理任务误删。如果有一个定时任务清理/tmp下的旧文件，可能把还没合并的分片删了。解决办法是给分片目录设置合理的保留期，或者把分片放在专门的持久目录而不是系统临时目录。

5.3 大文件传输中的内存与连接问题

传大文件时，如果实现不当，很容易把内存吃满。典型错误是把整个分片读进内存再处理。一个4MB的分片读进内存问题不大，但如果并发8个，就是32MB，再加上框架本身的开销，小内存机器就扛不住了。

正确做法是流式处理：读一块、校验一块、写一块，内存占用和分片大小无关，只和缓冲区大小有关。缓冲区1MB足够，再大收益不明显。

连接方面，要注意HTTP的长连接复用。如果每个分片都新建连接，握手开销会拖慢整体速度。用连接池复用连接，能显著提升吞吐。但也要注意，某些中间设备会对长连接做超时断开，所以要有重连机制，断了的连接要能自动重建并继续传。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是忽略了Content-Length和实际body长度的一致性。有一次客户端声明分片大小1MB，但实际body只发了900KB（因为读文件时提前到了EOF），服务端按1MB去读，读到了脏数据。后来加了校验：服务端收到分片后，先比对实际收到的字节数和声明的size，不一致直接拒绝。

第二个坑是哈希算法不统一。客户端用MD5，服务端用SHA-1，算出来的值当然对不上。这种问题排查起来很费劲，因为两边都觉得自己没错。后来我们在协议里明确写死哈希算法，双方都按同一个来。

第三个坑是并发合并。两个合并任务同时触发，把同一批分片拼了两遍，最终文件大小翻倍。解决办法是合并操作加分布式锁，或者用状态机保证一个文件同时只有一个合并任务在跑。

6. 性能调优与扩展思路

6.1 分片大小与并发数的动态调整

固定分片大小和并发数在简单场景够用，但如果你的服务要面对各种网络环境，动态调整会更稳。思路是：客户端先探测一下当前链路的带宽和延迟，据此选一个初始分片大小和并发数，传输过程中根据成功率和吞吐再微调。

比如，如果发现分片失败率上升，说明链路不稳，就减小分片大小、降低并发，让单次失败的影响更小；如果吞吐远低于带宽上限，说明并发不够，就适当增加并发。这套自适应逻辑不复杂，但能明显提升弱网下的体验。

6.2 秒传与去重：基于内容哈希的优化

如果同一个文件被多个用户上传，或者用户重复上传同一个文件，每次都完整传一遍太浪费。可以在协商阶段让客户端先算文件的整体哈希，发给服务端查询。如果服务端已经有这个哈希对应的文件，直接返回"已存在"，客户端秒传完成，一个字节都不用传。

这就是所谓的"秒传"。实现要点是服务端维护一张哈希到文件的索引表。注意哈希要算完整文件的，不是分片的，否则无法判断整体是否已存在。哈希碰撞的概率对MD5来说极低，如果担心安全可以用SHA-256。

6.3 从单机到分布式的演进路径

单机方案跑通后，如果文件量和并发上来了，就要考虑分布式。演进路径大致是：

• 存储层从本地磁盘换成对象存储，分片直接传到对象存储的临时区，合并用对象存储的拼接能力。
• 状态层从本地文件或单库换成共享数据库或分布式缓存，保证多机都能查到续传状态。
• 合并任务从进程内触发换成独立的任务队列，避免合并拖垮上传服务。

这个演进不用一步到位，按需推进。很多场景单机加对象存储就够用了，不必上复杂的分布式协调。

6.4 安全与权限的边界

大文件传输接口是攻击面，必须做权限控制。每个分片请求都要校验用户对目标文件是否有写权限，不能只靠文件ID就放行。文件ID最好用不可预测的随机串，避免被遍历。

另外要限制单文件大小和总分片数，防止有人用超大文件或海量小分片把服务端资源耗尽。限流也要做，按用户或IP限制上传速率和并发数。这些是基础防护，别等出事才补。

7. 我个人的实操体会

这套方案我在几个不同规模的项目里都用过，从单机小工具到多机文件服务，核心逻辑没变过，变的是存储和状态管理的实现。最大的体会是：断点续传的难点从来不在协议本身，而在状态的一致性和边界情况的处理。协议就那几个头字段，半小时能看懂，但要让它在各种异常下都正确工作，需要把落盘顺序、幂等、锁、校验这些工程细节都抠到位。

另一个体会是，别过早追求并发和性能。先把串行版本跑通，确保分片、校验、合并、续传每一步都正确，再逐步加并发。我见过太多人一上来就搞多线程，结果bug藏在并发时序里，排查成本极高。串行版本是并发版本的地基，地基不稳，楼越高越危险。

最后分享一个小技巧：在开发和测试阶段，把分片大小设得特别小，比如64KB，这样一个小文件就能产生几十个分片，能快速暴露分片边界、序号、合并顺序这些逻辑问题。等逻辑验证无误了，再把分片大小调回正常值。这个办法帮我省了很多调试时间，推荐你也试试。