课程资源大文件分片上传，想要稳定可靠，核心思路只有一条：用受控并发提升速度，用指数退避重试保证成功率，两者缺一不可。
在线教育平台每天都要接收大量的视频课程、压缩包、课件合集，动不动就是几个GB甚至十几个GB，传统的一次性POST上传，网络稍有不稳就前功尽弃，分片上传解决了体积问题，但把难题转移到了并发和重试这两个环节上,下面聊的是实际项目中反复踩坑后沉淀下来的做法。
为什么课程资源上传总是失败在最后一步？
大文件上传最让人崩溃的场景：进度条跑到90%，突然断网，然后从头再来，分片上传把文件切成多个小块，每块独立上传，最后服务端合并，看起来简单,但真正的坑在于两个地方。
第一个坑：分片不是越小越好。 常见说法是“越小越不容易失败”，但分片过小会导致请求数量激增，以1GB文件为例，如果用1MB分片，会产生1024个请求；如果用10MB分片，只有102个请求，请求数越多，服务器压力越大，超时重试的可能性反而更高，行业共识认为，课程类大文件（视频、课件包）的分片大小在5MB到20MB之间比较合适,具体看网络环境。
第二个坑：并发数被当成“越高越快”。 有人一听说并发上传，直接开20个线程同时传，结果服务器很快返回429或者连接超时，因为每台服务器、每个带宽都有上限,无脑并发等于自己攻击自己。
分片上传的基本流程，业内已经比较固定：前端读取文件→计算MD5→调用后端接口获取上传凭证→逐片上传→上传完成后通知服务端合并→校验分片完整性，并发控制和重试策略就夹在“逐片上传”这个环节里。
课程资源并发上传：到底开几个线程才算合适？
“并发上传 线程数 怎么设置”是教育平台开发者问得最多的问题，答案不是固定数字,但有两个判断依据。
当前网络的上行带宽
假设你的家庭宽带上行只有10Mbps，理论每秒传输约1.2MB，如果分成10MB一片，每片需要约8秒；同时开5个线程，每个线程抢到的实际带宽只有2Mbps，单片耗时变成约40秒，总吞吐反而没有显著提升，更糟的是，并发过高会让路由器缓冲区溢出,出现大量丢包重传。
实操建议：用浏览器或Node.js里现成的探测逻辑，先上传一个1MB的测试分片，记录耗时，再动态调整并发数，现代浏览器支持navigator.connection.downlink，但那是下行；上行带宽可以用XMLHttpRequest上传一个临时空白文件来估算，虽然不精确,但比拍脑袋强。
服务器端的承受能力
很多课程平台用的是Nginx做反向代理，默认client_max_body_size只允许单请求小体积，需要单独为分片接口设置大值，同时调整keepalive连接数，服务器能同时处理的并发连接是有上限的，如果两千个学生同时上传课程，每个客户端开10个线程，服务器要承受两万并发连接,这个量级足以击垮默认配置的Nginx。
比较稳妥的取值逻辑是：
- 普通有线网络：3到5个并发。
- 内网或教育网专线：5到8个并发。
- 移动网络（4G/5G）：1到3个并发，因为移动网络丢包率更高,并发越大重传越严重。
这里有个关键点：并发不是固定不变的，建议做“动态并发”如果连续几个分片都一次性成功，可以增加一个并发；如果连续三次出现超时，就减少一个并发,比固定值更适应真实场景。
上传失败后的重试：指数退避才是正确的处理方式
课程资源上传失败，最常见的错误是直接重传同一片，而且是立刻重传，这种做法在弱网环境下就是死循环，比如宽带临时抖动，你立刻重传，可能正好撞上抖动持续期，于是又失败，又重传，正确的重试逻辑是退避每次失败后等一段时间再试,而且等待时间要逐步变长。
三种常见的重试策略
固定间隔重试：每隔3秒重试一次，简单但不管用，如果故障持续30秒,这3秒的间隔会白耗十几次请求。
线性退避：第一次等1秒，第二次等2秒，第三次等3秒，效果比固定好，但遇到长时间网络波动时，重试窗口拉得太长,用户急。
指数退避：第一次等1秒，第二次等2秒，第三次等4秒，第四次等8秒，以此类推，这才是行业共识里的标准做法，每次重试还要带一点“随机抖动”，比如在基础等待时间上随机增减0到1秒，防止多个客户端同时失败后同时重试，形成一个一个的“重试风暴”。
具体到代码实现,推荐用类似下面的逻辑：
- 设置最大重试次数为5次，超过后不再重试该分片，而是标记为失败,等所有分片上传完成后合并上报。
- 每次失败时，记录HTTP状态码：413（分片太大）、403（凭证过期）这类错误不需要重试，直接终止；408、429、500、502这类瞬时错误才值得重试。
- 如果是因为服务端返回“该分片已存在”，要直接跳过一个分片,避免重复上传浪费带宽。
这里要提醒一句：
重试不是万能的，如果用户断网超过几分钟，所有重试都会失败，这时候前端应该停止上传，保留进度，等网络恢复后让用户手动点“继续”，重试机制必须结合“断点续传”的状态记录每个分片的上传状态保存在本地（比如localStorage或IndexedDB），而不是只放在内存里，很多课程资源平台最后做出来的体验不好,就是因为任务一刷新就全部归零。
课程资源分片上传的实战实现路径：从切片到合并
前面聊了理论，这部分给出一个能落地的操作路径，假设你在做一个教育平台的后台管理系统，技术栈是Vue+Nginx+Spring Boot,上传的课程包是2GB的录播视频。
第一步：前端切片并初始化上传
用浏览器原生的File.slice()方法，按8MB一个分片切割，一个大文件会被分成约256片，每片生成一个序号和MD5值，放到一个待传队列里，调用后端/upload/init接口，传入文件总大小、分片大小和MD5，获取一个uploadId和每片的预签名URL（如果用的是OSS或S3）。
第二步：并发控制队列
不要让256个请求同时跑，自己实现一个“并发池”：用Promise控制同时最多有4个上传任务，每个任务完成后从队列里取出下一个分片，同时维护一个“成功列表”和“失败列表”，成功列表的作用很关键如果中途刷新了页面，再次进入时先向后端查一下哪些分片已经存在,直接把对应的队列任务跳过。
第三步：失败分片的指数退避重试
给每个分片设置一个retryCount，一旦上传失败，先把分片放回队列尾部，但设置一个延迟，延迟时间按照Math.pow(2, retryCount)秒计算，并加一个0到1秒的随机量，注意：放回队尾而不是队首,这样可以避免同一个分片一直卡着整个队列。
第四步：合并校验与回调
所有分片完成后，调用/upload/complete接口，服务端根据uploadId把所有分片按序号拼接成完整文件，拼接完成后，计算整个文件的MD5，和前端初始化时传的MD5做对比，不一致的话，说明有分片内容损坏（极少见但可能发生），让前端重新上传哈希值不匹配的那几片，这步不省略，否则会有一批“看着上传成功却无法播放”的课程视频。
第五步：服务端限流与凭证过期处理
服务端要对每个uploadId设置有效期，比如2小时，用户上传到一半去开会，回来之后凭证已过期，这时候需要自动续期而不是报错，Nginx层面设置
limit_req，限制单IP每秒最多上传分片数，防止有人拿这个接口刷流量，对教育平台而言，这种滥用一般不多,但加上限流能让服务器更稳定。
课程资源上传中断后，如何做到真正的断点续传？
课程运营人员经常遇到的场景是：老师上传课件到一半，笔记本合上了，第二天打开网页发现进度还在，这个体验的关键在于“断点续传”的实现。
关键在于两点,缺一不可。
第一，前端在上传过程中实时记录每个分片的状态，记录在哪里？IndexedDB比localStorage更适合，因为分片状态可能上千条，localStorage的5MB配额容易爆，每条记录包含分片序号、大小、MD5、上传状态、重试次数。
第二，后端必须提供“查询已完成分片”的接口，用户重新打开上传页面时，先调用这个接口拿到已上传的分片列表，前端把所有已存在的分片直接从队列里剔除，从第一个缺失的分片开始续传，有时候用户换了一台电脑，本地没有记录，照样能续传因为后端已经攒了一部分分片。
这里有一个容易被忽略的坑：分片的大小一旦设定，整个上传过程中不能变，如果用户第一次选了8MB，第二次在另一台电脑上选了16MB，同一个文件的后端分片就会对不上，合并出来的文件一定是坏的，分片大小必须在文件初始化时写进记录,并且续传时强制沿用旧值。
Q&A：课程资源分片上传的并发与重试常见问题
问：如果多个用户同时上传同一个课程视频，会产生数据冲突吗？
答：不会，每个文件初始化时都会生成独立的uploadId，分片存储路径以uploadId为目录名，互不干扰，如果同一个用户重复上传同一份文件，建议后端做一次“秒传”检查全文件MD5一致时，直接返回已有的课程地址,没必要再传一遍。
问：分片并发数和服务器CPU核数有关系吗？
答：关系很小，分片上传的瓶颈在网络I/O和连接数上，不在CPU计算上，真正吃CPU的是合并后的MD5校验和转码，不要让上传接口去做这些事，建议上传接口只做存储,把转码任务交给消息队列异步处理。
问：重试次数最大设置成多少比较合理？
答：对课程资源这种大文件场景，单分片重试5到6次够用，超过这个次数还在失败，说明网络或者服务器有持续性问题，再重试只是浪费流量，正确做法是将失败分片的信息持久化保存,等网络恢复后由按钮触发新一轮重试。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/769035.html
