做机械制造相关网页，最让人头疼的往往不是页面本身，而是文件。客户发来一个CATIA装配体动辄几百兆，设计部提交的STEP中性格式包偶尔能到几个G，更不要说三维扫描点云和质检视频——这些在机械行业都是日常工作流的一部分。大文件上传下载在机械制造网页里，从来不是加个<input type="file">就完事的问题，背后牵涉超时控制、断点续传、服务器存储、带宽成本一系列环节。这篇文章是我在几个制造类项目里实际趟过坑之后整理的实用方案合集，适合做企业官网、图纸管理系统、供应商协同平台的朋友参考。
1. 机械制造行业的文件到底有多大：先给场景画个像
1.1 从几十KB到几十GB，不同文件的真实体积区间
机械制造网站的文件上传下载需求，跟电商网站完全不同。电商网站的图片一般几百KB到几MB，已经算"大"了；机械行业里的文件类型却横跨好几个数量级。我按实际项目里遇到的情况整理了一张表，建议做方案前先对照确认自己的场景落在哪个区间：
| 文件类型 | 典型大小 | 出现场景 | 数量特征 |
|---|---|---|---|
| 二维CAD图纸（dwg、dxf） | 2MB~50MB | 设计部出图、供应商核对 | 数量多，单文件小 |
| 三维零件模型（prt、SLDPRT、ipt） | 20MB~500MB | 设计协作、客户确认 | 单文件中等 |
| 三维装配体（asm、sldasm） | 500MB~20GB | 整机评审、工艺规划 | 单文件大，嵌套引用多 |
| 中性格式（STEP、IGES、STL） | 50MB~3GB | 跨软件交换、外发加工 | 单文件较大 |
| 3D扫描点云 | 20GB~200GB | 逆向工程、检测对比 | 文件巨大，一次性导入多 |
| 数控程序（NC、G代码） | 几KB~几十MB | 车间下发加工 | 数量极多 |
| 质检视频与高清照片 | 200MB~5GB | 工序追溯、质量报告 | 批量上传 |
我的经验是：如果只是做企业官网的客户图纸收集入口，2GB是一个比较舒适的上限；但如果是内部PLM（产品生命周期管理）或者图纸管理系统，不能按"单文件最大2GB"来设计架构，因为装配体加上材质贴图、分析结果文件，一个项目文件夹几个GB、几十GB一点都不夸张。先把场景定死，后面选型才不会跑偏。
1.2 为什么通用网站的上传组件在这里集体失灵
很多人一开始都会试着用现成的上传组件，比如Bootstrap File Input、jQuery Upload File之类，单文件几MB没问题，超过100MB就开始出状况。原因不难理解，通用组件默认走的是"整文件单次POST提交"的路线，在大文件场景下面临至少四个硬伤。
第一是超时。浏览器和服务器之间的HTTP连接，通常会有网关超时时间（Nginx默认60秒、Tomcat默认若干分钟）。一个500MB的文件在普通上行带宽下要传十几分钟，中途任何一个代理层超时，请求就被切断了。第二是内存与并发。整文件POST把文件读入服务器内存或临时目录，同时几个人上传，小机器直接把内存、磁盘写满。第三是没有断点能力。连接一旦断开，前端没有"接着传"的知识，只能从头再来，机械行业里几GB的装配体传了一半断掉，重传的耐心和带宽成本都受不了。第四是进度和校验缺失。没有分片粒度，进度条只能假装在动，文件传完也没有完整性校验的抓手，到了服务端才发现文件损坏，已经晚了。
一句话总结：大文件上传下载必须换一套思路，核心就是"分而治之"——把大文件切成小块，逐块传输，记录进度，支持续传。
2. 分片上传：最通用也最容易工业落地的方案
2.1 分片上传的底层逻辑与"为什么能断点续传"
分片上传的原理并不复杂：前端把文件用blob.slice()切分成若干固定大小的数据块，逐个上传到服务端；服务端把每个分片保存为独立的临时文件，全部上传完成后，再按顺序合并成一个完整的文件。关键在于，前端本地记录"哪些分片已经传成功了、哪些还没传"，下次打开页面或重新上传时，只补传缺失的分片，这就是断点续传。
这里有一个容易被忽略的点：分片不只是为了绕开超时，更是为了让"重传成本"可控。假设一个2GB的文件切成200个10MB的分片，传到第150个分片时断网，恢复后只需要重传剩下的50个，而不是整个2GB。用数学的说法，重传的期望成本从O(文件大小)降到了O(单个分片大小)，这个收益在大文件场景里是决定性的。
另一个容易踩的坑是"分片序号"。服务端必须依赖每个分片携带的chunkIndex字段来有序保存，合并时严格按这个序号拼接。如果并发上传时分片到达顺序是乱的，合并时还按"到达顺序"写，文件必然损坏。后面我会专门讲这个坑。
2.2 前端实现：自己封装还是用现成库
早期做分片上传，很多人用Plupload、Web Uploader这类库。Web Uploader对分片、并发、MD5校验都封装得挺好，但它基于jQuery，维护状态一般，且遇到移动端浏览器兼容性问题比较头疼。我现在的建议是：如果你所在项目有一个稳定可维护的前端工程，自己封装一个上传模块是更可控的选择，代码量其实不大。
核心逻辑如下（以10MB分片为例）：
const CHUNK_SIZE = 10 * 1024 * 1024; // 10MB async function uploadInChunks(file, fileId, onProgress) { const totalChunks = Math.ceil(file.size / CHUNK_SIZE); let uploaded = 0; // 先从服务端获取已上传的分片列表 const uploadedChunks = await axios.get(`/api/upload/status?fileId=${fileId}`); const uploadedSet = new Set(uploadedChunks.data); const tasks = []; for (let i = 0; i < totalChunks; i++) { if (uploadedSet.has(i)) { uploaded += CHUNK_SIZE; continue; } const start = i * CHUNK_SIZE; const end = Math.min((i + 1) * CHUNK_SIZE, file.size); const chunk = file.slice(start, end); tasks.push(uploadChunk(fileId, i, chunk, totalChunks, onProgress)); } // 限并发，不要一次全发出去 await runWithConcurrency(tasks, 3); // 通知服务端合并 await axios.post('/api/upload/complete', { fileId, totalChunks }); } async function uploadChunk(fileId, index, chunk, totalChunks, onProgress) { const formData = new FormData(); formData.append('fileId', fileId); formData.append('chunkIndex', index); formData.append('chunk', chunk); // 带重试 for (let retry = 0; retry < 3; retry++) { try { await axios.post('/api/upload/chunk', formData); return; } catch (e) { if (retry === 2) throw e; await sleep(1000 * Math.pow(2, retry)); // 指数退避 } } }这里的几个设计决策需要解释一下。第一，fileId不要用文件名，而是用文件MD5 + 时间戳 + 随机数生成，避免同名文件互相覆盖或并发任务冲突。第二，并发数取3，不建议太高。浏览器的同源HTTP/1.1连接数上限一般是6，且并发越高，分片乱序和服务端文件句柄压力越大；3个并发的效率和稳定性比较均衡。第三，分片大小10MB在公网环境下比较合适，内网千兆环境下可以放宽到20MB~50MB，减少请求次数。
2.3 后端合并策略与完整性校验
后端接收分片的逻辑很直接，但合并时要注意方式。很多人第一次写合并，用的是"把所有分片读到内存里再一次性写出去"，大文件直接OOM。正确做法是流式顺序写入：
@PostMapping("/api/upload/complete") public ResponseEntity<?> complete(@RequestParam String fileId, @RequestParam int totalChunks, @RequestParam String md5) throws IOException { File dir = new File(tmpDir, fileId); File target = new File(storeDir, fileId + ".bin"); try (FileOutputStream fos = new FileOutputStream(target)) { for (int i = 0; i < totalChunks; i++) { File part = new File(dir, "part_" + i); try (FileInputStream fis = new FileInputStream(part)) { byte[] buffer = new byte[8192]; int len; while ((len = fis.read(buffer)) != -1) { fos.write(buffer, 0, len); } } part.delete(); // 合并完删除分片 } } String calculatedMd5 = DigestUtils.md5Hex(new FileInputStream(target)); if (!calculatedMd5.equalsIgnoreCase(md5)) { target.delete(); return ResponseEntity.status(500).body("文件校验失败"); } return ResponseEntity.ok("ok"); }合并之后一定要做MD5校验。前端在上传前就计算出整个文件的MD5，上传完成后端重新算一遍，两端不一致说明某个分片传错了或合并顺序有问题，宁可删掉重传也不要把坏文件入库。这个步骤对机械图纸尤其重要，一个损坏的STEP文件在客户那边大概率无法打开，比"上传失败"更让人崩溃。
2.4 分片上传最容易踩的三个坑
第一个坑是合并时用Files.copy(part.toPath(), fos)不小心把多个分片以"到达顺序"拼接。并发场景下分片到达顺序是乱的，必须按chunkIndex排序后再合并。我见过一个项目，单线程传没问题，一上并发就文件打不开，排查到最后就是合并顺序出错。
第二个坑是代理层或网关缓冲导致的假失败。Nginx默认会缓冲请求体，如果后端已经接收完所有分片，但Nginx还没把最后一个分片的响应返回给浏览器，前端会误判为"这分片失败"并重试，进而产生重复分片。解决方法是设置proxy_request_buffering off;，同时把client_max_body_size调大（注意这个参数单位是字节，不要漏了）。还要记得同步调整proxy_read_timeout、fastcgi_read_timeout，因为大文件上传耗时很长，超时设短了会出现"后端还在写，连接已经被切了"的经典问题。
第三个坑是临时目录写满。机械行业大文件多，一个分片10MB，200个分片就是2GB，再加上多个用户并发，服务器的/tmp很容易爆盘。我习惯为上传单独划分一个数据目录，并配置定时任务清理超过24小时未完成合并的分片文件，防止垃圾文件堆积。
3. 秒传与断点续传：针对机械图纸重复上传的实操优化
3.1 秒传的本质：文件指纹比对
机械行业有一个非常典型的场景：同一个订单的图纸，客户发一遍、销售转一遍、技术部改完再传一遍，内容完全相同或只改个文件名。传统方案会让用户反复上传同一份数据，浪费大量时间。秒传的思路就是：前端计算文件的MD5，上传前把MD5发给服务端查一下，如果库中已经存在相同指纹的文件，直接就返回"上传成功"，再把原文件路径关联到当前任务，不产生实际传输。
实现秒传前需要先权衡：MD5计算本身对大文件是有成本的。一个10GB的点云文件在普通电脑上算全量MD5要几十秒甚至几分钟，用户等了半天结果发现不能秒传，体验反而更差。我的做法是：只对2GB以下的文件做全文件MD5秒传；超过2GB掉进分片流程，靠分片级的MD5做部分秒传。这个阈值可以根据目标用户的实际设备性能调整。
计算MD5时建议用SparkMD5这类增量计算库，并且放到Web Worker里执行，避免阻塞页面。实测下来，1GB左右的STEP文件用增量MD5大概耗时5~10秒，用户的等待是可以接受的。
3.2 分片级断点续传：比"整文件续传"更细腻
断点续传要做到位，不能只靠前端本地记录，因为用户换电脑、清缓存、换浏览器后，本地记录就没了。可靠做法是把"哪些分片已上传"的状态落到服务端。前端初始化时先查一次：
GET /api/upload/status?fileId=xxx → { uploadedChunks: [0,1,2,5,6] }前端拿到已上传分片列表，只补传缺失的分片。这样即使刷新页面、断网重连，也能继续。服务端需要一张分片状态表，字段大致是：fileId、chunkIndex、分片MD5、是否完成、上传时间。分片每传成功一个就更新一次状态。
强调一下，分片MD5不只是用来校验，更是用来做"分片级秒传"的。比如同一个装配体文件第二次上传，很多分片的内容跟第一次完全一样，前端可以先把每个分片的MD5发给服务端，服务端返回哪些分片已经存在，前端直接跳过。这在车间多次下发同一套NC程序时特别划算。
3.3 断点续传状态怎么保存才能扛住服务端重启
分片状态表如果只存在内存里，服务端一重启就全丢了；存在数据库表里又太重。我的折中方案是：用一个轻量的文件（比如JSON）作为上传会话的元数据，放在临时目录里，与分片文件放一起。每次分片上传完成后更新一次这个元数据文件。服务端重启后，前端再来查状态时，通过扫描临时目录下的分片文件数量也能恢复状态，不依赖数据库。
如果项目本身已经用了Redis，更直接的方案是把状态存成Redis Hash，HSET upload:fileId chunkIndex current_time，读取时用HKEYS拿全部分片序号。Redis方案的好处是支持过期时间，天然避免垃圾状态堆积。但要注意：Redis里存的毕竟只是"上传进度"，不是文件内容本身，文件内容还是得老老实实落在磁盘上。
3.4 文件去重：从源头节省存储成本
存储成本在机械行业是不可忽视的一项。一套完整的装配体包含成百上千个零件，不同项目中大量零件文件完全相同，如果每上传一次就存一份，存储利用率非常低。
分片MD5表恰好可以做跨任务去重。当多个文件的不同分片内容相同时，它们的分片MD5一致，服务端可不必重复保存分片物理文件。这是一个相对复杂的优化，适合存储压力大的场景。简单做法仍然是"全文件MD5去重"：同一MD5只存一份，其他任务引用同一个存储对象。云对象存储（OSS/COS）还提供服务端去重类型的哈希特性，可以在选型时一并考虑。
4. 对象存储：把大文件托管给专业选手
4.1 为什么机械制造网站尤其需要对象存储
分片上传解决了"传得上去"的问题，但"存哪里、怎么扩容、怎么备份"是另一个层面的问题。自己用服务器磁盘存大文件，很快会遇到几个现实困难：磁盘分区不够用、备份策略要自己写、多台服务器之间文件不同步、下载带宽被占用。
对象存储（Object Storage）就是为这种场景设计的，它以"桶 + 对象键"的方式存储文件，天然支持海量数据、跨节点冗余、版本管理和生命周期策略。对于机械制造网站，我推荐至少把"成品文件库"放进对象存储，业务服务器只负责接口逻辑，不直接持有文件数据。
先说两种常见选型的对比：
| 维度 | MinIO | 阿里云OSS / 腾讯云COS / 华为云OBS |
|---|---|---|
| 部署方式 | 自建，可跑在普通服务器上 | 托管，无需自建 |
| 成本模型 | 一次性硬件+运维成本，无流量费 | 按存储量+流量计费 |
| 大文件接口 | 支持S3 Multipart Upload | 原生MultipartUpload |
| 内网访问 | 延迟低，适合车间内网 | 走公网，内网需专线或VPC对等 |
| CDN分发 | 需要自建或另接 | 可选配置，和存储联动 |
| 运维门槛 | 中高，需要自己监控和扩缩容 | 低，官方解决 |
我个人的经验：制造企业内部有多个厂区走内网互联时，MinIO非常合适；角色是"给外部客户提供图纸下载"或"多地域协同"时，云OSS/COS的CDN分发能力可以省很多事。
4.2 预签名URL：让文件绕过业务服务器直传
对象存储最常见的错误用法，是让文件先上传到业务服务器，再由业务服务器转发到对象存储。文件一多，业务服务器就成了瓶颈，带宽被占满，CPU还要处理一堆I/O。正确思路是使用预签名URL（Presigned URL），让浏览器直接与对象存储交互。
以MinIO为例，后端只需要生成一个临时的PUT签名URL：
String presignedUrl = minioClient.getPresignedObjectUrl( GetPresignedObjectUrlArgs.builder() .method(Method.PUT) .bucket("drawings") .object(fileKey) .expiry(600) // 有效期10分钟 .build());前端拿到这个URL，直接把分片PUT或POST过去，整个过程不经过业务服务器。好处是明显的：业务服务器只负责生成凭证、校验权限、记录元数据；文件数据流的压力全部打在对象存储侧，扩容时只需要扩对象存储集群。
要注意的是：预签名URL的本质是"临时令牌"，要严格控制有效期和权限。机械图纸属敏感数据，签名URL的有效期我一般不超过30分钟；大文件分片上传时每个分片单独签名，防止一个URL泄露后被用来上传任意文件到同一桶。
4.3 S3 Multipart Upload标准流程
如果选MinIO或兼容S3协议的存储，分片上传可以直接使用S3标准接口，比自己维护"前端切分 + 后端合并"省掉大量工作。完整的流程分四步：
CreateMultipartUpload：向存储发起一个分片上传任务，返回UploadId。UploadPart：按PartNumber（1~10000）逐个上传分片，每片可独立重试，存储会返回ETag。ListParts：异常中断后，用UploadId列出已经上传成功的分片，实现断点续传。CompleteMultipartUpload：提交所有PartNumber和ETag，存储完成合并。
项目里如果用Java，实现上非常简单：
MinioClient client = MinioClient.builder() .endpoint("http://minio.internal:9000") .credentials("accessKey", "secretKey") .build(); // 初始化 CreateMultipartUploadResponse resp = client.createMultipartUpload( CreateMultipartUploadArgs.builder() .bucket("drawings").object("assemble.step").build()); String uploadId = resp.result().uploadId(); // 上传每个分片 UploadPartResponse partResp = client.uploadPart( UploadPartArgs.builder() .bucket("drawings").object("assemble.step") .uploadId(uploadId) .partNumber(1) .stream(inputStream, size, -1) .build()); // 完成后合并 client.completeMultipartUpload( CompleteMultipartUploadArgs.builder() .bucket("drawings").object("assemble.step") .uploadId(uploadId) .parts(partETagList) .build());这套标准接口最大的好处是断点续传、分片校验、合并全部由存储服务完成，前端断了只需要查ListParts接着传，不用自己在业务数据库里维护分片状态。建议在选型时优先考虑支持S3协议的存储，未来从MinIO迁移到云OSS也只是换配置的事。
4.4 对象存储的生命周期与成本控制
机械行业的文件有个特点：访问热度随着时间快速下降。设计阶段的图纸每天被反复查看，进入量产阶段后，同一套数据可能一年都不再被调用，但出于追溯要求又不能删除。云对象存储普遍提供标准、低频、归档三种存储类型，结合生命周期策略，可以把超过一定时间未访问的文件自动转低频或归档，存储成本能明显下降。
以代码方式设置生命周期规则，阿里云OSS的一个简单策略示例：
BucketLifecycleConfiguration config = new BucketLifecycleConfiguration(); config.addRule(new LifecycleRule("archive-after-180-days", new LifecyclePrefixPredicate("drawings/"), LifecycleRuleStatus.ENABLED, 180, // 转为低频 365)); // 再转为归档同时建议开启存储桶的版本控制。机械行业经常发生"昨天的图纸被覆盖了，需要找回"的情况，版本控制可以在不影响当前版本的前提下保留历史文件，删除也不立即销毁，而是保留一个删除标记，方便误操作恢复。
还有一个实操细节：用MultipartUpload传了一半没有Complete的分片，会在存储里残留part_临时数据，长期下来会产生额外费用。要配置一条规则清理超过一定天数的未完成分片，或定期遍历ListUploads清掉过期UploadId。
5. 下载端提速：Range续传、zip打包和CDN分流
5.1 HTTP Range：让断点下载和多线程下载成为可能
下载大文件和上传同样难，但往往被更少关注。一个5GB的装配体，用户下载到90%断网，如果整个请求失败，就得从头再来，这体验放在现代系统里是不可接受的。HTTP协议本身就支持范围请求：服务端返回Accept-Ranges: bytes，客户端请求指定字节范围时返回206 Partial Content和Content-Range头。
后端实现范围下载，Spring MVC可以这样处理：
@GetMapping("/api/download/{fileId}") public ResponseEntity<Resource> download(@PathVariable String fileId, @RequestHeader(value = "Range", required = false) String range) { File file = fileService.getFile(fileId); long start = 0, end = file.length() - 1; if (range != null) { // 解析 range: bytes=12345-67890 String[] parts = range.replace("bytes=", "").split("-"); start = Long.parseLong(parts[0]); if (parts.length > 1 && !parts[1].isEmpty()) { end = Long.parseLong(parts[1]); } } long length = end - start + 1; return ResponseEntity.status(HttpStatus.PARTIAL_CONTENT) .header("Accept-Ranges", "bytes") .header("Content-Range", "bytes " + start + "-" + end + "/" + file.length()) .contentLength(length) .body(new FileSystemResource(file) { @Override public InputStream getInputStream() throws IOException { RandomAccessFile raf = new RandomAccessFile(file, "r"); raf.seek(start); return new InputStream() { @Override public int read() throws IOException { return raf.read(); } }; } }); }实现好Range支持后，浏览器断点续传可用，IDM、aria2这类下载工具也会自动发起多线程分段下载，用户体验会有质的提升。另外下载接口要注意Content-Disposition里的文件名编码，机械行业常用中文名称，务必用URLEncoder.encode(fileName, "UTF-8")处理后再拼进响应头，否则大部分浏览器会乱码。
5.2 多文件打包下载：别在内存里拼ZIP
图纸系统的下载场景经常是"用户勾选了一个订单下的十几个零件，希望一次性打包下载"。最容易想到的方案是把所有文件读进内存然后生成一个zip返回，但文件一多、文件一大（比如打包几十GB的装配体目录），这种方式必然OOM。
正确方案是流式打包，边读边写，只对输出流做缓冲：
try (ServletOutputStream out = response.getOutputStream(); ZipOutputStream zos = new ZipOutputStream(out, Charset.forName("UTF-8"))) { response.setContentType("application/zip"); response.setHeader("Content-Disposition", "attachment; filename=" + URLEncoder.encode("order-2024.zip", "UTF-8")); for (DownloadItem item : items) { zos.putNextEntry(new ZipEntry(item.getDisplayName())); try (InputStream is = fileService.openStream(item.getFileId())) { byte[] buffer = new byte[8192]; int len; while ((len = is.read(buffer)) != -1) { zos.write(buffer, 0, len); } } zos.closeEntry(); } }这样无论打包多少文件，内存占用始终保持在一个小的常量级。打包时间虽然长一点，但服务器不会崩。
有一个容易忽略的坑：中文文件名写入ZIP时的编码。Java的ZipOutputStream默认按系统字符集写入，写出来在Windows上打开很可能乱码或无法解压。强烈建议使用ZipOutputStream时显式指定UTF-8字符集，并确保条目名称不用反斜杠路径分隔符，避免在Linux下打包出来的zip在Windows上解压出现目录结构错乱。
5.3 CDN分流与内网直连：机械行业的特殊下载加速
对象存储加CDN的组合，对公网场景是常规操作。图纸文件放到OSS/COS后，开启CDN加速域名，全国乃至海外客户下载时走边缘节点，源站压力大幅降低。特别要注意的是：如果图纸涉及保密要求，CDN的回源鉴权不能省，建议使用URL时间戳签名（鉴权A/B/C），签名过期后URL自动失效。
机械制造企业的另一个特点是厂区局域网。内网用户下载时如果还绕道公网CDN，反而更慢。我在一个集团项目里采用了一个很实用的混合策略：后端提供一个内部探测接口，判断客户端IP是否属于内网网段，是则返回内网穿透内网MinIO的直连地址，否则返回CDN签名URL。这样既保证了总部的下载速度，又让外协单位走公网CDN，带宽成本可控。
5.4 在线预览代替下载：大文件分发的另一种解法
最后提一个被很多人忽略的思路：有些场景其实没必要让用户下载完整文件。机械图纸在线预览，现在已经有成熟的WebGL方案，比如CAD模型转成轻量化3D格式后，前端按LOD（细节层级）流式加载，用户只需要看外观，不需要把几GB的原文件拉下来。
我之前做过一个方案：用免费的CAD转换引擎把STEP模型转成3D Tiles格式，放到对象存储上，前端用Three.js加载，用户浏览装配体时丝滑加载，完全没有大文件下载的焦虑。这个思路虽然不解决"传输原始文件"的问题，但把很多"只需要查看"的高频场景从下载链路里摘出来了，值得机械类网站考虑。
6. 不同规模场景下的推荐组合方案
6.1 中小企业官网：客户图纸收集入口
如果你的场景只是企业官网上的"客户请上传设计文件"，文件一般不超过2GB，服务器就一台云主机，预算有限。我推荐：前端用自封装分片上传（10MB分片、3并发、断点续传）；后端用Java或Python接收分片并合并；存储直接用阿里云OSS或腾讯COS的标准存储；客户端下载时提供预签名URL，有效期24小时。
这个组合的好处是：开发量不大，稳定，不占业务服务器带宽。预签名URL直传可以做也可以先不做，流量小的时候走业务服务器中转问题不大，但一旦频繁被大文件占用，优先改成预签名直传。
6.2 内部PLM或图纸管理系统
这种系统是机械行业大文件上传下载的"主战场"，往往几千人在用，文件总量几十TB级别。我建议：
- 上传链路：S3 Multipart Upload标准流程，分片大小按网络环境选20MB~50MB，前端并发3~5，后端只做认证和元数据记录。
- 存储：MinIO集群（内网方案）或云OSS（多厂区方案），开启版本控制和生命周期。
- 下载链路：Range断点下载 + 多文件流式zip打包 + 内网/CDN混合路由。
- 在线预览：对CAD/STEP类文件做轻量化转换，高频查看场景直接走3D预览，不占下载带宽。
这类系统最重要的是元数据与文件内容分离。数据库里存文件的业务属性（图纸号、版本、所属项目、上传人），对象存储里只存二进制数据；删除也一样，先标记元数据不可见，对象存储通过生命周期自动清理。这样就不会出现"图号改名了、文件还在跑"的混乱。
6.3 供应商协同与外部交换平台
机械行业的图纸经常要发给供应商加工或给客户确认，文件大、数量多，外发对象水平参差不齐，不可能要求对方理解我们内部系统的逻辑。这种场景我的建议是：把"下载链接"做成提取码形式，有效期短（比如7天），访问无需登录，下载用CDN加速的Range下载。上传端则用标准分片上传，对方不需要装任何插件。
高保密需求时，可以给下载链接再加一重"动态水印"：文件名带接收方代号，PDF/图片类文件下载时后端动态叠加可见水印，一旦泄露可以追溯责任人。这个做法我在外协场景里用过，威慑效果比事后追责好得多。
6.4 落地前必做的几项演练
方案规划得再好，不压测等于白做。大文件上传下载项目上线前，我强烈建议至少在测试环境做三件事。
第一，弱网模拟测试。用代理工具（比如Fiddler或Charles的限速功能）把上传带宽限制在1Mbps，模拟车间现场的网络抖动，看断点续传是否真正生效、重试机制是否会多次重复上传同一分片。第二，并发压测。至少模拟20个用户同时上传1GB文件，观察服务端临时目录、内存、对象存储桶是否出现瓶颈，特别关注Nginx的buffer和超时配置是否合理。第三，断电/重启演练。在上传进行到一半时重启业务服务或存储服务，验证前端能否凭服务端状态恢复续传，而不是直接报"上传失败"。
这三项演练我在项目里筛出过不止一个隐藏问题，比如并发高峰时Nginx的proxy_temp_path磁盘写满、Redis状态和临时文件不同步等等。早点暴露总比客户现场踩雷强。
最后说一点个人体会：大文件上传下载在机械制造网站里不是"功能"，而是一套需要从网络、存储、数据一致性三个角度整体设计的基础设施。不要试图用一个大而全的组件解决所有问题，弄清楚自己的文件量级、网络环境和用户习惯，然后按"分片 + 断点续传 + 对象存储 + Range下载"这条主轴做组合，基本能覆盖绝大多数场景。每个环节都不要贪多求全，盯住最影响体验的那几个指标——上传成功率、断点恢复能力、下载稳定性和存储成本——逐个击破，系统自然会好用起来。
