镝不咸这种上传问题，我最早是在给一所职业院校做教学资源平台对接时遇到。老师那边录好的实训课视频，一节轻松超过1GB，用传统ASP.NET上传接口传，传了快40分钟，网页提示失败，前面的进度全部白费。第二天教务老师直接把电话打到我这里，说课件传不上去，平台没法用。那一刻我就明白，教育行业里的“大文件上传”从来不是技术选型上的选择题，而是业务能不能跑通的基础设施问题。
那段时间我把ASP.NET体系下的大文件上传、断点续传、视频切片整条链路重新捋了一遍。后来不少同行问我：网上的插件五花八门，为什么部分历史控件还需要IE浏览器，能不能在纯网页端自己集成一套稳定的上传方案，既能支持断点续传，又能顺便处理视频切片。这篇文章我就把这些经验完整梳理出来，偏向直接可以落地的方案，也包含我在排查过程中踩过的比较隐蔽的坑。
1. 教育行业的上传场景：不是普通的文件提交
先别急着谈切片、续传、接口设计，我得先让大家理解教育行业的上传请求到底长什么样。很多人一听说“大文件上传”，第一反应是网盘同步、图片批量传，那些场景说难也难，但和教学资源上传的压力完全不同。
1.1 一节45分钟课程的真实体积，先算一笔账
我们以最常见的课堂实录为例。现在的录播设备最低也是1080P起步，部分稍微好点的设备直接给到2K甚至4K。码率按照主流的6Mbps到12Mbps波动，算下来一节45分钟的课大概是：
- 1080P、低码率6Mbps：约45分钟 × 60秒 × 6Mbps ÷ 8 ≈ 2GB
- 1080P、中高码率12Mbps：约45分钟 × 60秒 × 12Mbps ÷ 8 ≈ 4GB
- 包含多机位或教师屏幕录制的复合流，文件会更大，达到5GB以上也不意外
而那些微课、精品课，虽然单节时长短，但制作方为了保证画质，导出PRORES或者其他高码率中间格式时，单个视频体积也很吓人。所以教育系统里说的“大文件”，基本不是几百MB的量级，而是1GB到5GB这个区间。
1.2 集中爆发式提交与“弱上行”网络
教育行业的上传还有一个鲜明特点，就是时间高度集中。学期初、期末、精品课程申报截止前，所有老师会集中在同一时间段上传。于是服务器在平时很闲，到了节点就炸，高峰期一个几百人的学校可能同时涌进几十个GB级别的上传任务。
另一个要命的约束是网络。校园网内部访问服务器时带宽尚可，但很多老师是回家上传的，家用宽带的下载可能500M，上行却只给30M到50M。按照30M上行粗算，上传一个2GB文件理论需要9到10分钟，实际因为运营商限制和WiFi波动，往往需要20到30分钟，这期间只要网络抖动一次，任务就很可能失败。
1.3 为什么“失败重传”会让教师直接弃用系统
可以换位思考一下：老师录了一节课，剪辑完导出一个2.5GB的MP4，他在系统里点上传，等了半小时，到了97%忽然弹出“连接被重置”，他会不会再忍受半小时重新传一次？大概率不会。他只会截图反馈到工作群，说平台是垃圾、系统有问题，然后改用U盘拷贝或者第三方网盘分享。
所以教育行业的上传需求有一个核心考核指标：一次传不成功不要紧，但再次点击续传时，不能让他从头开始。这个业务诉求直接决定了断点续传不是选配，而是标配。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 断点续传与视频切片：一个解决传输可靠性，一个解决文件处理方式
我见过不少项目方案，把“断点续传”和“视频切片”当成同一个功能来讲，实际这是两个维度的问题，不区分清楚，后面的架构会越做越乱。
2.1 断点续传，续的是“已经传输成功”的终点
断点续传从字面理解，就是传输中断后，再次发起传输时不需要从第1个字节开始，而是从已经传输成功的最后一个字节往后继续。
实现上通常有两种流派：
一种是在HTTP层用Range请求实现。客户端在断点后带上Content-Range: bytes=已传字节数-的请求头，让服务器直接从指定位置继续接收，这偏向于单个TCP连接层面的大文件续传，逻辑比较轻，但遇到服务器程序崩溃、或者网络切到另一个网段导致连接彻底失效时，实现起来依然麻烦。
另一种是“切片上传”。前端先把文件按固定大小切成若干个chunk，例如每个分片5MB，然后逐个上传。已经传成功的分片，服务器会记录编号；失败后重试，只上传那些尚未记录成功编号的分片。当前端把每个分片都传完，再请求服务器把分片合并成完整文件。
教育行业我更推荐后者。原因很简单：面对1GB以上的视频文件，切片方式能把单次HTTP请求的持续时间缩短到几秒到十几秒，单个分片失败重传的成本极低，同时还能配合多线程或者并发上传来提升总吞吐量。
这里需要澄清一个术语：我们常说的“断点续传里文件被切成了很多片”，但这个片和后面播放层面的视频切片是完全不同的概念。
2.2 视频切片，切的是“一整次传输”还是“一整段视频”
当前面说的上传方案中把文件切分，那是传输层的分片，目的是方便上传、支持续传。切完以后，服务端收到的是一个个按序号排列的二进制分块，这些分块拼起来还是一个一模一样的完整MP4或者MOV文件。
而视频切片，在播放领域有另一层含义，指的是把一个视频文件按照时间轴切成一个个小的媒体片段，比如HLS协议里的.ts文件，或者DASH里的.m4s文件，每个片段通常几秒到十几秒，可以被流媒体服务器按需下发，配合m3u8等索引文件实现边下载边播放和自适应码率切换。
这两个概念在标题中被放在一起，容易造成直觉上的混淆。实际在做一个上传系统时，通常是“传输层先做分块上传”，等完整文件在服务端被重组后，再进入“媒体处理层，转码切片成HLS/DASH”。
但也有系统为了追求极致效率，把两层合并。比如在服务端收到足够多的MP4分片后，不等完整文件落盘，就开始解析、转码已经可用的片段，把转码后的媒体切片直接分发到CDN。这种方式看起来快，但工程复杂度高不少，连moov元数据在文件头的MP4都能处理，普通团队不必轻易尝试。我更建议分阶段实施，先把上传层做好，再做转码切片层的衔接。
2.3 秒传：和断点续传既协作又互相独立
教育系统里还经常被问到“秒传”功能。秒传的真实原理，不是网速变快了，而是服务端已经拥有同样一份文件。客户端在上传前先计算文件的哈希值，比如MD5或SHA-1，把哈希发给服务器，服务器在自己的文件库里一查，如果内容和大小都匹配，直接返回“这个文件已经存在”，根本不需要上传数据。
对于很多老师反复上传同一份录制视频（比如上传多门课程，或者文件之前没提交成功又重新上传），秒传能节省大量时间。值得注意的是，秒传与断点续传、切片是互补关系：秒传解决“这个文件曾经有机构传过”的问题，断点续传解决“这个文件没传完”的问题。好的上传插件一般先试秒传，失败后再按照“查进度、传剩余分片”的流程走。
2.4 IIS默认限制下的切片收益
另外，传统ASP.NET应用跑在Windows上的IIS里，默认配置通常只允许30MB左右的上传请求。老版本的ASP.NET甚至默认限制4MB。如果不做任何调整，一个2GB的视频文件连请求都发不出去。
切分片后就能绕开这个限制吗？不是绕开，是让单次请求体变小，每个请求都保持在几MB到十几MB的范围，只要每个分片请求小于IIS的单次请求大小上限，就不会触发限制。若想在服务器端接收几十GB的大文件，仍需要调整IIS的maxAllowedContentLength等参数，这些放到第3章讲。
3. ASP.NET服务端：分片接收与合并的正确姿势
服务端是整个续传体系的底盘。如果接口设计不合理，前端做得再华丽也没有意义。这一部分我结合ASP.NET Core写一套能直接落地的接口实现，同时补充传统ASP.NET项目中比较头疼的兼容点。
3.1 新项目选型：直接用ASP.NET Core接收流更顺手
要是从零开始做，我建议直接上ASP.NET Core，尽管标题里写ASP.NET，但今天完全没必要再在老ASP.NET Web窗体里做新的上传组件。ASP.NET Core在请求管道上更接近现代Web框架，大文件流式读写、异步处理、依赖注入都是第一公民，写起来比传统的Page_Load时代舒服太多。
传统ASP.NET项目能不能做？也能做，但是会在很多隐蔽处吃苦头，比如框架自带的输入验证、基于System.Web的HttpRuntime限制、老式进程池回收机制等。我见过一些老项目为了兼容上传，在web.config里把maxRequestLength调到很大，结果进程被大请求拖死，因为老ASP.NET接收请求时往往把整个请求体读入内存，一个2GB的文件直接让内存占用暴涨。
ASP.NET Core里可以通过Request.Body拿到原始流，边读边写，避免一次性加载整个文件。对于IIS托管，还需要注意在web.config里同时放开maxAllowedContentLength和maxRequestLength两层限制。
3.2 分片上传接口：元数据参数与文件流分开传
实现断点续传的服务端接口，可以采用一种常见的方案：前端把每个分片的元数据放在Header或Form字段中，分片的二进制内容以文件流方式提交。上传完一个分片，服务器只记录该分片的完成状态，不立即合并。
下面是一份简化的ASP.NET Core分片上传接收端代码：
csharp复制[ApiController]
[Route("api/upload")]
public class UploadController : ControllerBase
{
private readonly IWebHostEnvironment _env;
public UploadController(IWebHostEnvironment env)
{
_env = env;
}
[HttpPost("chunk")]
public async Task<IActionResult> UploadChunk([FromForm] ChunkUploadModel model)
{
if (model.File == null || model.File.Length == 0)
return BadRequest("chunk file is empty");
// fileId是前端生成的任务唯一标识，chunkIndex表示当前分片序号
string tempDir = Path.Combine(_env.ContentRootPath, "temp", model.FileId);
Directory.CreateDirectory(tempDir);
// 保存当前分片，文件名直接用序号
string chunkPath = Path.Combine(tempDir, model.ChunkIndex.ToString());
await using (var stream = System.IO.File.Create(chunkPath))
{
await model.File.CopyToAsync(stream);
}
bool isCompleted = await CheckIfAllChunksUploadedAsync(model.FileId, model.TotalChunks);
if (isCompleted)
{
// 合并分片后，可以删除临时目录
string mergedFile = await MergeChunksAsync(model.FileId, model.FileName);
return Ok(new { completed = true, filePath = mergedFile });
}
return Ok(new { completed = false, current = model.ChunkIndex });
}
}
public class ChunkUploadModel
{
public string FileId { get; set; }
public string FileName { get; set; }
public int ChunkIndex { get; set; }
public int TotalChunks { get; set; }
public IFormFile File { get; set; }
}
前端用multipart/form-data提交时，分片元数据可以通过form表单字段一起传递，服务端使用[FromForm]接收，再配合IFormFile属性直接获取分片二进制流。
这里有个容易忽略的点：fileName不要直接用用户传来的原始值作为服务器磁盘文件名，否则可能导致路径穿越等安全问题。建议只保存原始文件名用于后续重命名，实际磁盘文件统一使用fileId + 后缀，让用户对最终存储路径不可控。
3.3 合并文件的关键细节：排序请用数字，不要用字符串
所有分片上传完以后，服务端需要把分片文件按照顺序拼接成一个完整视频。很多初版实现在这里出问题：遍历临时目录时，拿到的文件顺序可能是1、10、11、2、20、21，如果直接用字符串排序然后依次写入，视频文件就会变成乱序拼贴，播放起来直接花屏。
等你把所有分片传完，合并接口的完整逻辑大概是：
csharp复制private async Task<string> MergeChunksAsync(string fileId, string fileName)
{
string tempDir = Path.Combine(_env.ContentRootPath, "temp", fileId);
string uploadDir = Path.Combine(_env.ContentRootPath, "uploads");
// 必须用数字解析再排序，避免“10”排在“2”前面
var chunkFiles = Directory.GetFiles(tempDir)
.Select(f => new
{
Path = f,
Index = int.Parse(Path.GetFileName(f))
})
.OrderBy(x => x.Index)
.ToList();
string safeName = Path.GetFileName(fileName); // 只取文件名部分，去除路径信息
string ext = Path.GetExtension(safeName);
string newFileName = $"{Guid.NewGuid():N}{ext}";
string outputPath = Path.Combine(uploadDir, newFileName);
await using var outputStream = System.IO.File.Create(outputPath);
foreach (var chunk in chunkFiles)
{
await using var inputStream = System.IO.File.OpenRead(chunk.Path);
await inputStream.CopyToAsync(outputStream);
}
Directory.Delete(tempDir, true);
return $"/uploads/{newFileName}";
}
如果系统不能直接用int.Parse，例如分片文件命名中带有前缀，也需要至少按照数值在程序内定排序规则。不要图省事在Shell或者文件系统层面直接OrderByName。
3.4 老路由里被拦下的“潜在危险Request值”及其对策
如果你真的在一个传统ASP.NET项目中调试，那么有很大概率看到这样一个异常：检测到有潜在危险的 Request.Querystring 值。
这个报错来自于ASP.NET早期为了防范脚本注入而引入的请求验证机制。当从QueryString、Form或Cookie中读到类似<、>、&等字符时，框架会直接抛异常，从HTTP 500开始，内容却是这样一句带有“潜在危险”的描述。
为什么大文件上传会踩到这个机制？因为分片上传时，一些人习惯把fileName、fileId这类参数放在URL的QueryString里，比如：
text复制/api/upload.ashx?fileName=course_第1讲.mp4&chunkIndex=0
中文、空格或其他特殊字符经过URL编码后还原，某些情况下可能被框架判定不符合输入白名单；老版本IIS和ASP.NET对URL中特殊字符的接受度也各不相同，结果请求还没进业务代码就被中断。
处理方式要分情况。
如果整个站点都是现代化架构或接口化改造，建议直接把请求验证的粒度控制在必要位置。传统.aspx页面可以在页面指令中设置ValidateRequest="false"，但这就等于告诉框架“本页面不要自动拦截潜在危险输入”，安全性需要在业务代码层自行保证。你可以在页面的Load事件里对输入参数做白名单校验，比如文件名中不允许出现路径分隔符和可执行脚本字符。
如果接口是通过一般处理程序（.ashx）实现，框架的请求验证默认不触发，因为一般处理程序不经过页面的ValidateRequest流程。这也是很多老项目把上传处理放在.ashx里的原因。
在没有改造预算的情况下，不要全局关闭请求验证，否则一个教学资源站会很容易被脚本注入打穿。比较稳妥的方案是：对历史规则熟悉的团队，保留站点的通用拦截；只为上传接口单独建一个目录或页面，在页面级别允许一些特殊字符，并在业务层做二次清洗。
3.5 零散分片文件的清理策略
分片传输虽然好，但会给服务器留下一堆问题：临时目录里可能积累大量未完成或上传完但尚未合并出来的分片文件，每个任务几十到几百个，如果不定期清理，磁盘很快会被撑爆。
我习惯给每个上传会话设置一个过期时间，比如24小时内未完成的任务，定时任务扫描后直接删除临时目录；已完成合并的任务，合并后立即删除临时目录。对应到ASP.NET Core里可以写一个后台服务BackgroundService，每10分钟执行一次清理逻辑。
4. 前端上传插件的实现重点：Web Worker与IndexedDB配合，才是真正的断点续传体验
现在回到浏览器端。很多教育平台的使用者还在用老内核浏览器，因此在做前端上传体验时，兼容策略和代码边界非常重要。
4.1 这里的插件是Web组件，不是需要管理员安装的ActiveX控件
教育行业用户说“上传插件”，脑海里浮现的是古老网站提示“请安装上传控件”那种东西。在今天的实现中，我要强调：现代上传插件应该是一个纯网页模块，用JavaScript实现切片、调度、失败重试和进度上报，不需要用户额外安装任何程序。
它能达到和桌面控件几乎等同的体验：点击选择文件后，立刻开始切片上传，进度独立显示，网络断开后重新连接，能自动恢复。
如果还有学校电脑的浏览器非常老、连File.slice都不支持，现阶段的解决建议是直接升级到Chrome、Edge或Firefox ESR版本，而不是去给老浏览器写兼容垫片。对安全性和后续维护来说，捆住你的从来不是技术，而是旧浏览器的历史包袱。
4.2 用Web Worker把切片和上传丢到后台线程，避免页面卡死
这里直接回应一个热搜点：前端使用worker上传大文件。
文件切片操作本身不需要花太多时间，但如果是读取文件内容并计算哈希，或者同时监控几个分片的上传状态，很容易让主线程跑满。2GB的文件用File.slice切出几百个分片，刷一次界面如果还顺带做MD5计算，浏览器页面可能卡顿明显。
把切片和上传逻辑放进Web Worker，可以很好地解决页面卡顿问题。主线程只负责选择和暂停，真正循环读文件的逻辑在Worker线程里执行，通过postMessage把进度传递回来。
Worker的基本结构大概是这样：
javascript复制// uploadWorker.js
self.onmessage = async function (e) {
const { file, fileId, chunkSize, chunkIndex, fileIdList } = e.data;
for (let i = 0; i < fileIdList.length; i++) {
const start = i * chunkSize;
const end = Math.min(start + chunkSize, file.size);
const blob = file.slice(start, end);
const chunkFileId = fileId + '_' + i;
const formData = new FormData();
formData.append('fileId', fileId);
formData.append('fileName', file.name);
formData.append('chunkIndex', i);
formData.append('totalChunks', fileIdList.length);
formData.append('file', blob, 'chunk_' + i);
try {
const resp = await fetch('/api/upload/chunk', {
method: 'POST',
body: formData
});
const json = await resp.json();
if (json.completed) {
self.postMessage({ type: 'complete', filePath: json.filePath });
return;
}
self.postMessage({ type: 'progress', current: i + 1, total: fileIdList.length });
} catch (err) {
// 单个分片失败重试，在Worker内部控制重试次数
self.postMessage({ type: 'error', chunkIndex: i, message: err.message });
}
}
};
除了网络耗时，使用Worker最大的好处是：当教师把窗口切到别的应用再切回来时，页面不会出现那种“假死”状态。
4.3 用IndexedDB记录“哪些分片已经传上去”，续传才能精确到分片
如果只是管理内存里的上传状态，一旦浏览器刷新或关闭，进度就丢了。断点续传要能跨刷新、跨断电继续，就必须把“已上传分片的信息”持久化到浏览器端。
IndexedDB是最合适的浏览器内数据库。可以建一个对象仓库，键是fileId，值里记录文件名、文件大小、总分片数、已传分片序号列表、分片大小等：
json复制{
"fileId": "48fe0a2c-b6b1-4e19-8e1d-8920cd8c4a5f",
"fileName": "教学设计大赛-王老师.mp4",
"fileSize": 2147483648,
"chunkSize": 5242880,
"totalChunks": 410,
"uploadedChunks": [0, 1, 2, 5, 6, ...],
"lastModified": "2024-11-20T10:30:00Z"
}
选择文件后，先查IndexedDB：
- 如果没有任何记录，说明这个文件从没传过，开启新上传任务。
- 如果有记录，则进入“续传模式”，把已存在的分片序号发给服务端确认，服务端返回真正缺失的分片，前端只上传缺失部分。
这套逻辑在实现上要注意一个细节：已上传分片不能只写在内存里，每次单个分片上传成功后立刻更新IndexedDB记录。
我在某个平台测试时，用同样的2GB文件分别测试“刷新后续传”和“断网恢复”，整个体验差异很大。有持久化记录的情况下，任务从97%开始只需再传几十MB；没有持久化，前端只能重新全量上传，服务端靠“分片已存在”跳过——虽然理论上也能少传，但每次断线都要服务端把所有分片状态比较一遍，网络请求量和处理时间也会变长，不是最优解。
4.4 并发分片数与失败重试策略
光有切片还不够，同一时刻上传几个分片，会直接决定总耗时。
很多初版实现会一次性把几百个分片全部并发发出。在服务器压力大时，这种全量并发会把IIS线程池打满，给同服务器上的其他业务造成影响。如果教育机构是集中上传高峰期，更是雪上加霜。
比较合理的策略是控制并发数在3到5个：
- 在每个分片上传完成后，立即从任务队列取下一个分片，保持固定并发数。
- 单个分片失败后，先记录失败原因，放入重试队列。
- 连续失败次数过多时，可以暂停整个任务，提示用户检查网络，并提供“重试”按钮，而不是无限循环重试。
在上传过程中，如果断网恢复，只用记录“哪些分片还没得到成功回报”，查一次IndexedDB，跳过已成功的部分继续。
5. IE和ActiveX这两条老路：真到了必须兼容的时候，怎么办
这个标题下面的热搜词里，连续出现“不能装载NTKO大文件上传控件。请确保使用IE浏览器，并检查浏览器的安全设置”这样典型的报错。这句话属于教育行业信息化的一个时代投影。
5.1 “必须使用IE”的历史包袱从哪来
很多老牌资产管理、教务管理系统是在十几年前基于ASP.NET Web Forms开发的。当年浏览器技术并不标准，微软的一大堆ActiveX控件只能在IE里跑，上传大文件也就自然做成了ActiveX方式。
当时选择ActiveX是有道理的：浏览器本身的下载上传能力弱，ActiveX可以访问本地文件系统，能实现真正的断点续传，甚至可以读取文件硬盘。问题是，这些能力高度依赖Windows环境、IE内核和复杂的注册表安装步骤。
发展到现在，网上仍然有很多学校反馈“在Win10、Win11的Edge里无法安装控件”。因为新版Edge默认不支持和旧ActiveX相关的机制，而Windows 11里的IE已经被彻底移除。学校的信息技术老师又不一定敢改注册表、组策略，导致一个简单的传视频操作变成事故高发点。
5.2 ActiveX控件上传的受限条件：安全级别、IE内核、管理员权限
如果真要运行这类控件，通常需要满足一连串条件：
- 必须使用Internet Explorer或支持IE内核的浏览器，不少新Edge已经不再支持。
- 浏览器安全设置需要降级，把站点加入“受信任的站点”，启用ActiveX筛选并允许运行未签名或已签名的控件。
- 安装控件往往需要管理员权限，很多学校电脑有还原卡或软件分发策略，重启后控件状态可能就变了。
这其中每一条单独拿出来，都会让一个不熟悉技术的教师束手无策。我看到这个问题的第一反应就是：技术上能强行兼容，但从产品层面看，让上传功能变成“必须由管理员处理”的方案已经不适合教育行业。教师没有义务理解ActiveX安全级别，他们要的是点一下上传，然后等进度条走完。
5.3 不硬走老路：我对接存量系统时用的兼容解法
我在给一个老教学平台做上传改造时，采用的方式是：
- 在新版页面中集成基于Web Worker和IndexedDB的普通网页上传模块，适用于所有现代浏览器。
- 保留老接口路径，但不强求用户在IE中操作。
- 对必须使用老ActiveX控件的模块，建议客户在校园网里提供一台仅有内部访问的老Windows镜像或虚拟机，或者让信息技术老师通过远程协助完成特殊操作。
教育行业的信息化升级本质上是一场渐进式替换。如果你是自研系统，大可直接放弃IE兼容，引导用户换到Chrome、Edge。如果你是集成商，前端检测到老浏览器时弹出明确的升级指引，远远好于让用户卡在ActiveX安装提示里。
6. 分片合并之后的存储与播放衔接：通往HLS切片的一条中间态
上传完成并不是终点，视频还要被播放。这就牵扯到标题里的另一个关键词：视频切片。
有个容易被忽略的衔接点：分片上传完成后得到的MP4文件，和流媒体播放系统需要的媒体切片并不是一件事。需要把合并后的文件再交给转码服务，或者采用一种“直接分片存储+动态组合播放”的方案。
6.1 常规路线：先合并成完整MP4，再交给媒体服务转码
大多数教学平台会把上传完成的文件先存到存储区，然后触发一次后台任务，交给FFmpeg或者云转码服务。转码时把同一个源视频切成两种产物：
- 给普通点播使用的MP4（H.264+AAC）。
- 给HLS流媒体使用的m3u8索引文件，以及若干
.ts切片。
在这个链路里，“上传分片”是为了让文件安全到服务器；“媒体切片”是为了让视频播得流畅。很多方案把两个阶段分开做并没有问题，只要上传接口成功回调里能带上最终存储路径即可。
6.2 合并后的MP4能否拖动进度条，关键在moov元数据位置
如果只是上传并直接播放，需要留心一个隐藏坑：MP4文件的元数据（时长、轨道偏移量等信息，统称moov）可能分布在不同位置。录制软件直接生成的MP4，很多格式信息保存在文件尾部。正常网络播放器播放时可以忍受，因为解码器会先把尾部元数据读完再开始播。但对大视频和在线点播场景来说，这会导致“打开后长时间空白”，或者进度条无法拖动。
解决办法有两个：
- 合并完成后，用FFmpeg做一次快速处理：
bash复制ffmpeg -i merged.mp4 -c copy -movflags +faststart output.mp4
这条命令不改编码，只把moov元数据搬到文件头部，速度很快。
- 在录制课程时就引导教师按统一格式导出，例如“导出Web优化格式”。
这里我要多说一句：我见过不少团队为了快，上传完成后直接用原始文件路径提供点播。文件小、网内播放看不出来，一旦视频到2GB以上，拖动进度条的体验就会很差。教育场景里学生经常要跳到中间某个知识点，忽视moov位置问题很容易被投诉“播放器卡”。
6.3 进阶方案：不合并完整文件，直接保留分片并做HLS媒体切片
如果团队有转码能力，其实还存在一条更彻底的路线：前端切好分片后，服务端不做完整文件合并，而是把分片作为输入源，直接进入转码队列，让FFmpeg读取这些分片并生成HLS切片。
之所以这种方案不常见，在于分片之间要有完整、连续的文件结构才能被FFmpeg正确解析。MP4是一个由索引+数据块组成的格式，单纯把文件从中间切开，每个分片不一定能独立解码，所以服务端必须按顺序完整拼好后再转码。想要做到“边传边转”，通常需要借助文件系统的稀疏文件，或者等最后一个分片到达后，通过一个“拼接视图”虚拟化为完整文件，再交给转码任务。这个做起来很复杂，普通上传不需要。
如果确实希望教师上传完几分钟后就能开始在线播放，比较稳妥的流程是：分片合并成完整MP4后，立即触发转码任务，转码生成HLS切片，播放器指向m3u8地址。整个链路利用后台任务执行，用户不用等着全部转完，转码出前几个切片后就能开始播放。
最后再多说一条经验：任何大文件上传方案，上线前都要做一次基于弱网环境的模拟测试。我自己习惯在浏览器开发者工具的网络面板中把上行带宽调到1Mbps以内，再配合断网模拟，反复验证“传一半断网再恢复”“刷新页面继续上传”“同时传多个文件”三个场景。这套体检验证通过了，可比看着代码逻辑正确可靠得多。真到学校集中的申报季，你会感谢自己当初没有省这一步。