机械制造网页大文件传输实战：分片上传、断点续传与下载加速

做机械制造的网页系统，绕不开一个特别头疼的问题：大文件上传下载。设计部门每天在 PLM、MES、图纸协同平台上倒腾的 CAD 模型、工艺卡、质量检验报告，动不动就是几百 MB；等到装配体、整机图纸打包，几个 GB 也常有。我刚接手公司内部图纸管理平台时，第一周就被车间装配师傅骂了三次，原因是一个 3.8GB 的整机模型上传到一半直接超时，我在电脑前看着报错页面干瞪眼。

这个问题适合谁看？如果你在做机械制造相关网站的开发、部署或运维，或者正在企业内部搞数字化、协同设计、文档管理系统，这篇文章里的内容基本都能直接拿来用。这里不讲某个商业产品的广告，而是从实际项目中沉淀下来的一套通用思路：分片上传、断点续传、秒传、下载加速、内网部署适配、常见坑的排查方法。每一项都会给出尽量具体的参数和代码片段，方便你根据现场情况去调。

1. 机械制造网页里的“大文件”到底大在哪

1.1 制造业要面对的文件类型和典型大小

机械制造场景里，网页端要处理的文件类型其实比较固定，主要有这么几类：

• CAD/CAE 原生模型：SolidWorks、UG、CATIA 等导出的设计文件。
• 中间交换格式：STEP/STP、IGES、STL 等，这类格式在跨软件协作里出现频率最高。
• 工程图与工艺卡：DWG、PDF、工艺路线表，往往和物料清单绑定在一起。
• 质量与检测报告：包含影像检测数据的报告文件，尺寸会比普通文档大不少。
• 设备手册与自动化程序：重型机械的说明书、PLC 梯形图、CNC 加工程序。

不同类型文件的典型大小，可以看下面这个表：

这里还没有算测试时产生的点云数据、有限元分析结果文件，那些动辄几十 GB 的另说。做系统设计时，如果只按“普通图片 + PDF”的模型去规划，肯定会在上线第一周就翻车。

1.2 通用 Web 方案为什么直接套用会翻车

在普通网站上传几兆的照片，最简单的方式就是一个 <input type="file"> 加一个 POST 请求。但在制造业场景这套东西根本撑不住，原因有四个。

第一，网络层就是硬伤。 多数企业内部主干网是千兆，但车间或者弱电间到工位这一段经常是百兆，要走外网的办事处或者供应商更可能只有一般的上下行带宽。按百兆带宽计算，一个 2GB 装配体要传 160 秒以上；如果中途有点抖动，整个上传就要重新来，重传成本极高。

第二，服务端限制。 常见的 Nginx 默认 client_max_body_size 只有 1MB，Tomcat 默认也不大。如果以为改成一个很大的值就完事，那后续可能会在内存里加载整个文件，OOM 是早晚的事。上传大文件必须让服务器只处理一小块一小块的数据，不能一次性把整个文件吞进内存。

第三，浏览器机制不够用。 普通 form 上传没有精确的进度反馈，没有自动重试，更不可能实现断点续传。用户看到进度条卡在 30% 很容易手动刷新，一刷新全白传了。这个现象在制造业用户群里特别常见，因为车间师傅本来就是“卡了就重启”的使用习惯。

第四，数据一致性不可控。 机械图纸错了不是打开文件看一眼的问题，图纸传输过程中的损坏可能导致产线按错误的尺寸加工，验收失败损失不可控。你需要有校验机制，而不是传完就算完。普通上传方式在一致性保障方面几乎等于零。

从这几条原因就能看出来，大文件上传方案一定要把“可控性”放在功能优先级的前面。最核心的方案就是下面要讲的分片上传。

2. 上传侧方案：分片上传 + 断点续传 + 秒传

2.1 为什么分片是核心

分片上传的本质，是把一个文件看作一串连续的字节流，用 file.slice() 切分成多个小块，每个小块单独上传。这样做的好处很直接：

• 每个请求体都很小，服务端和网关不会因为体积太大而拒绝。
• 失败后只需要重传失败的哪一个分片，不需要重新传整个文件。
• 可以多个分片并发上传，充分利用带宽。
• 可以实时计算每个分片的状态，给用户一个准确的整体进度。

这种思路和高速公路分段计费是一个道理：全程堵车了不用从头再走，只处理堵塞的那一段就够了。放在生产线上也很好理解，一个大部件很难一次装好，拆成子部件逐项装配、逐项检验，风险更可控。

2.2 前端分片的一套标准做法

前端操作非常简单，核心 API 是 File.prototype.slice()。下面这段代码可以直接在浏览器里跑通：

js复制function createChunks(file, chunkSize) {
  const chunks = [];
  let start = 0;
  while (start < file.size) {
    chunks.push({
      index: chunks.length,
      start: start,
      end: Math.min(start + chunkSize, file.size),
      blob: file.slice(start, start + chunkSize)
    });
    start += chunkSize;
  }
  return chunks;
}

// 使用示例：把 2GB 装配体按 10MB 分片，切成约 200 片
const file = document.getElementById('modelInput').files[0];
const chunkSize = 10 * 1024 * 1024;
const chunks = createChunks(file, chunkSize);

然后对每个 blob 构造 FormData，POST 到后端：

js复制async function uploadChunk(uploadId, chunk) {
  const formData = new FormData();
  formData.append('uploadId', uploadId);
  formData.append('index', chunk.index);
  formData.append('chunk', chunk.blob);
  return fetch('/api/upload/chunk', { method: 'POST', body: formData });
}

这里的 uploadId 是标识本次上传任务的随机字符串，后端通过它来跟踪整体上传。前端在上传开始前，先向后端请求一个 uploadId，然后把文件总大小、总片数、文件名称等元信息报给后端，后端预先建好任务记录。

分片大小怎么选？ 这是经验问题。我在项目里用的规则是：内网千兆环境 10~20MB 一片，外网弱网环境 2~5MB 一片。分片越小，重传粒度越细；但分片越多，HTTP 请求数量越大，服务端开销越大。之前在外网环境用了 10MB 分片，供应商的弱网环境下经常超时重传，切到 4MB 后就平稳很多。算一下：如果带宽是 1MB/s，4MB 一片大约 4 秒传完，10MB 就是 10 秒，无论连接是否断开，都能把损失控制在较低范围。

2.3 并发控制：别无脑全开

分片后不能一次性把 200 个请求全部打出去。一是浏览器对同一域名的并发连接数有限制，二是服务端并发过高时会挤压磁盘和内存。比较合理的做法是维护一个并发队列，常保持在 3~5 个并发。

一个通用的 JS 并发控制实现：

js复制async function uploadAllChunks(uploadId, chunks, concurrency = 4) {
  let nextIndex = 0;
  async function worker() {
    while (nextIndex < chunks.length) {
      const chunk = chunks[nextIndex++];
      await uploadChunk(uploadId, chunk);
    }
  }
  const workers = Array.from({ length: concurrency }, () => worker());
  await Promise.all(workers);
}

上面每个 worker 就是一个“工人”，不断从队列里取出下一个分片进行上传。四五个工人同时搬，既不会闲置带宽，也不至于把服务器压垮。

2.4 断点续传的具体实现

断点续传的原理说来简单，流程长但稳定：

1. 每次分片上传成功后，后端把已上传分片的序号记下来。
2. 当文件需要继续上传时，前端先调用接口，例如 /api/upload/status?uploadId=xxx。
3. 后端返回已上传分片索引列表，前端直接从缺失的第一片继续上传。
4. 全部分片齐全后，前端再调用 /api/upload/complete 去触发后端合并。

这个流程还有一个衍生效果，就是“秒传”。秒传的本质是在上传前先计算整个文件的哈希值，例如 MD5 或 SHA-256，然后询问服务器：这个文件是不是已经存在？如果库里已经有相同哈希的文件，就不需要真上传了，直接返回“上传成功”。这个能力对制造业特别有用，因为同一套设计图纸会在不同项目里被反复引用，内容完全一致的概率很高。

要注意，浏览器里计算一个大文件的全量哈希不算非常快。2GB 文件算 MD5 可能要十几秒甚至更久。如果要秒传，最好在用户选择文件后立即在后台开始计算，同时显示一个“正在校验文件”的状态。计算过程最好放到 Web Worker 里，避免阻塞主线程。如果界面卡住，很多用户会以为网页死了，直接关掉重来。

2.5 完整工作流总结

我落地项目时，上传接口文档里通常就是下面这个流程：

这套流程看起来复杂，却是目前网页端做大文件上传最可靠的办法。它不依赖某种私有云服务，在 Apache、Nginx、Tomcat、容器环境里都能自己实现，也方便后续对接 MinIO 等对象存储。

3. 后端接收与合并的细节

3.1 后端应该如何接收分片

后端接口的职责其实很单一：接收每个二进制分片、把它保存到磁盘，并记录索引。以常见后端技术栈为例，分片保存思路如下：

• 任务目录按 uploadId 命名：/data/upload_tmp/{uploadId}/
• 每个分片保存为独立文件：0.part、1.part、2.part
• 同时在一个数据库表里记录每个分片的索引、大小和任务状态

有一个细节很关键：不要把分片数据直接写进数据库的 BLOB 字段里，而是直接落盘。 分片文件一般在 5~20MB 左右，数据库 BLOB 在大批量频繁写入时会带来很大压力。制造业系统并发上传不会像互联网 C 端那么恐怖，但工程现场批量入库时，连续上传几个小时也很常见，把存储路径记在库里就够了，文件本身放磁盘。

用 Go、Python 做后端，原理完全一致。核心就是一句话：请求体中的字节流直接写入磁盘文件，位置由 uploadId + index 决定，这样合并操作会非常简单。

3.2 合并策略：顺序拼接还是边传边合

合并一般有两种策略。

第一种，全部上传完成后顺序合并。 读取任务目录下所有分片文件，按 index 从 0 到 n-1 依次写入最终文件。这个方案代码最简单，出错也好定位。

第二种，边传边合（流式追加）。 每次上传分片后直接追加到最终文件对应偏移量。好处是省了一次全量合并时间，但缺点是如果某个分片被重传了几次，同一偏移量可能被写入多次，需要额外处理覆盖逻辑，一致性维护成本较高。

我的建议是：对于制造业内部系统，整体合并一次的成本并不高。一个 2GB 文件顺序写一遍磁盘，Linux 下大概十几秒到几十秒。而“边传边合”省下来的时间和它引入的复杂度相比并不划算。除非在做视频、超大扫描件这类持续写入的场景，才考虑流式合并。

合并之后，必须做一次完整性校验。前端在初始化时报告了文件总大小和 MD5，后端合并完成后重新计算一次 MD5，对不上就标记上传失败。这一步绝不能省。我有一个真实教训：某次合并后 MD5 不一致，排查了很久才发现任务目录所在的机械硬盘有坏扇区，导致分片 17 写入不完整。如果没有校验，这份图纸就会被下游当成正式文件使用。

3.3 用不用对象存储

制造业企业内部系统的存储方案有很多选择。公司规模不大时，直接用 NFS 挂一块盘做共享存储也够；图纸数据量很大、需要异地容灾时，接一个 S3 兼容的对象存储更合适。

对象存储做分片上传有一项天然优势：它本身就支持分片上传接口。以 S3 协议为例，典型过程是：

1. 调用 CreateMultipartUpload 得到一个 uploadId。
2. 逐片调用 UploadPart，每个分片会返回一个 ETag。
3. 最后调用 CompleteMultipartUpload，把所有 ETag 按分片顺序提交，由对象存储自己做合并。

这个方案省掉了自研后端对临时文件的管理，直接把临时文件层交给对象存储。坏处是要多理解一层 API 语义，并且在自建 MinIO 时需要关注它所在磁盘的 IOPS 和容量。

我的经验是：如果系统只是要快速落地一套图纸管理功能，自建后端 + 本地磁盘最省事；如果公司已经采购了统一存储底座，直接利用对象存储的分片上传能力，把临时文件和数据文件放在一处，运维更简单。

4. 下载侧方案：既要快，又要稳

4.1 文件下载为什么也能成为问题

说到下载，很多人觉得“给个 URL 就行”，但在机械制造场景里，大文件下载经常出现两种情况：

• 用户点下载后，浏览器转了很久，最后提示网络错误，从头再来。
• 明明服务器带宽足够，车间十几个人同时下载设备手册，其他人连查询接口都变卡。

这两个问题的根因，要么是下载链路不支持断点，要么是没有做流量控制和缓存。下面几个方法可以组合使用。

4.2 用静态服务 + Range 请求实现断点下载

Range 请求是 HTTP 协议自带的能力。浏览器下载文件时，如果服务器返回 Accept-Ranges: bytes，浏览器就能支持拖动进度条、断点续传。Nginx 默认就支持静态文件的 Range 请求；如果文件存在本地目录，直接让 Nginx 代理，配置非常简单：

nginx复制location /files/ {
    alias /data/files/;
    sendfile on;
    directio 4m;
    aio on;
}

这里 directio 4m 的含义是超过 4MB 的文件使用异步 IO 直读，可以防止大文件读磁盘时把 Nginx 的工作进程卡住。这个参数对大文件下载很有效，实测下载几 GB 的 CAD 模型时，CPU 占用率比默认配置低不少。

Range 请求的好处在于天然支持断点下载。用户下载到一半断网了，重新点下载时，新版浏览器会从上次的字节位置继续，而不是重新开始。这个能力不需要写额外代码，前提是服务器没有关闭 Range。

4.3 后端主动实现文件流的代码要点

如果文件不是直接存在静态目录里，而是存在对象存储或数据库里，就需要后端自己写一个文件流下载接口。核心逻辑可以用 Java 为例来说明：

1. 解析请求头中的 Range，拿到 start 和 end。
2. 打开文件输入流，把指针定位到 start。
3. 设置响应头 Content-Range: bytes {start}-{end}/{total}。
4. 返回 206 Partial Content。
5. 用流式输出，不要一次性把整个文件读成 byte[]。

如果对象存储支持 Range，直接透传也可以。一个很常见的生产实践是：后端用 64KB 或 128KB 的缓冲区循环写入：

java复制try (InputStream in = storage.openFile(id, start, end);
     OutputStream out = response.getOutputStream()) {
    byte[] buf = new byte[128 * 1024];
    int len;
    while ((len = in.read(buf)) != -1) {
        out.write(buf, 0, len);
    }
}

关键在于，缓冲数组不要特别大。128KB 是一个成熟的流式传输窗口。它在机械制造环境下的好处是明显的：即使现场网络波动，也不会因为一次性在内存里塞入几个 GB 而把整个服务器拖死。

4.4 多文件打包下载：流式压缩

机械制造里经常需要一次下载整套资料，比如“这个项目的所有图纸 + 说明书 + 外购件清单”。如果先把所有文件复制到临时目录，再压缩成 zip，内存和磁盘都容易出瓶颈。建议用流式 zip 的方式，边读原文件边写入压缩流。

Java 的 ZipOutputStream 可以逐文件写入，Node.js 的 archiver 库也是类似思路。核心原则是避免把 N 个几百 MB 的文件全部加载到内存里同时压缩。流式压缩对服务端内存很友好，实测下载 10 个总共 5GB 的图纸包时，Java 进程内存可以稳定在几百 MB 级别。

当然，打包下载也有几个坑。第一，传统 zip 格式对单个文件大小有限制，超过 4GB 要使用 zip64 或改用其他格式。第二，如果文件来自对象存储，每次都从远端拉一遍再压缩，耗时会很长。最好是让打包任务在后台执行，完成后推送下载链接，不要让用户一直等一个长 HTTP 响应。

4.5 下载加速与内网缓存

制造业公司的网络往往是“外网进线带宽有限，内网骨干带宽充裕”，所以可以在不影响安全的前提下，把常用图纸包放到内网 Nginx 代理缓存里。第一次从源存储拉取，第二次就直接从缓存磁盘读取。配置思路是：

• 对外接口保持不变。
• 在内网存放一份只读缓存目录。
• 下载时先检查缓存目录是否有同名文件，有就直接返回；没有则触发后台任务生成并放入缓存。

这样做的好处是：采购、售后、车间工人反复下载同一套图纸时，不需要每次都去数据库或对象存储里拉。如果图纸经常更新，还要注意在缓存 key 中加入文件版本号或更新时间参数，防止缓存过期导致下发旧版本。

5. 机械制造内网环境和老旧终端的适配

5.1 车间电脑、工控机浏览器兼容性

制造业现场的终端往往不是最新浏览器。有的车间 MES 终端还是 Windows 7 加 IE11，有些质检电脑用的是 Chrome 79 这种老内核，这些都是真实存在的。在设计上传下载功能时，有两个兼容性要点：

• 分片上传依赖 File.slice()，老旧浏览器里需要兼容处理。
• 如果要兼容 IE11，FormData 上传二进制文件还是能工作的，但进度事件细节上有坑。
• 建议在功能上线时做浏览器版本检测，对不支持的浏览器给出明确提示，引导用户使用推荐浏览器，而不是让用户面对一堆乱码。

我在一个项目里遇到过车间触摸屏一体机用 Win10 自带的老 Edge，虽然内核是 Chromium，但版本旧，File.prototype.slice 传参方式有兼容问题。当时的解法是在前端封装一个 safeSlice 函数，自动处理不同浏览器下的调用差异。

5.2 带宽占用和流量控制

生产车间的现场网络通常有较高优先级。如果某个操作员在工位电脑上下载 2GB 图纸，占满链路带宽，旁边的产线终端查询信息就会卡。针对这个情况，建议做流量控制：

• 下载接口在高峰期限制每个用户同时下载的任务数量。
• 设定最大并发下载数，例如同 IP 最多 2 个下载任务。
• 在后台任务中限制单个文件的下载带宽，例如限速 20MB/s，避免把骨干网络打满。

这些限制在内部系统里实施成本不高，只需要在网关或应用层做一个简单的令牌桶或者用户配额判断即可。不要等到业务方反馈“系统卡了”再去加，那已经晚了。

5.3 浏览器内存与卡死问题

再讲一个容易被忽视的坑：前端在预览大型 CAD 模型时，经常会使用 WebGL 渲染，WebGL 渲染和文件上传同时进行，会占用大量内存和显存。如果你在同一个页面里做“本地上传 + 3D 预览”，要特别注意内存峰值。建议用独立 Web Worker 去处理分片和哈希计算，预览用单独的 Iframe 承载，或者干脆在 PDF 渲染期间暂停上传任务。

大文件上传本身也很消耗浏览器内存，如果把整个文件读进 ArrayBuffer 再切分，2GB 文件很大概率直接把浏览器搞崩。正确做法是直接使用 File.slice() 生成的 Blob 上传，不要先整体读进内存。这一条在制造业老旧电脑上尤其重要，那些工控机本来内存就只有 4GB 左右。

6. 大文件上传下载常见问题和排查速查

6.1 高频问题对照表

6.2 几条实际排查思路

分享几个我在现场排查时常用的工具和命令。

• 用 iperf3 测试两台机器之间的真实带宽，不看理论值。
• 用 curl -I 检查响应头，确认是否包含 Accept-Ranges: bytes。
• 用 lsof 查看大文件是否被进程持锁，导致删除失败或 IO 阻塞。
• 用 du -sh /data/upload_tmp 看临时目录是否积累了失败任务文件，如果有，磁盘可能被悄悄占满。

Windows 上可以用资源监视器看网络活动。我实际遇到过车间网线水晶头松动，导致千兆链路回退到百兆，这种硬件问题在软件里根本查不出来，只能靠实测。

6.3 几个容易忽略的产品细节

还有一个容易被忽略的问题：下载文件时响应头里的 Content-Disposition。加不加 attachment 决定了浏览器是直接打开文件还是另存为。如果改成 inline，车间电脑上点了图纸，PDF 可能直接打开而不是下载，这个行为在产品需求里要提前定清楚。

另外，大文件下载的日志尽量打全：用户 ID、文件 ID、起始字节、结束字节、是否命中缓存。这个日志在排查“为什么车间网络卡”的时候几乎是唯一线索。我靠日志发现某位同事一天内反复下载了 15 次同一个 2GB 设计手册，出口带宽直接被耗干。后来加了下载缓存和单用户任务数限制，问题立刻缓解。

7. 结尾的经验分享

根据我自己的实际经验，机械制造网页里做大文件上传下载，核心其实就三件事：分片、断点、校验。无论用自研后端、Nginx、对象存储还是商业组件，这三件事永远逃不掉。在项目开始之前，建议先花一周时间把现场的网络图摸一遍，搞清楚带宽瓶颈在哪里、客户端浏览器都是什么版本，然后选型就会非常清晰。不要一上来就追求最先进的技术栈，把基础的分片上传和 Range 下载做扎实，配合合理的并发控制和日志，已经能解决绝大多数问题。最后再分享一个小技巧：上线前找一台最旧、内存最小的车间电脑做一次全链路测试，如果那台机器能流畅完成 2GB 文件的上传和下载，这套方案基本就可以放心交付了。