1. 移动端大文件上传的痛点与整体思路拆解做过移动端文件上传的朋友应该都有体会一个几百兆的视频直接往服务端扔结果基本只有两种要么请求超时要么内存直接爆掉。尤其是现在短视频、在线教育、社交分享这类场景用户随手拍一段视频就是几十上百兆如果还用传统的“一次性表单上传”思路用户体验会非常糟糕。我最近在一个跨平台应用项目里就遇到了这个问题需求很明确用户从相册选一段视频前端做分片处理然后逐片上传到服务端最后在服务端合并成完整文件。这个方案的核心价值在于三个层面。第一是稳定性大文件拆成小块之后单个请求的体积可控网络抖动导致的失败只需要重传某一片而不是整个文件从头再来。第二是内存友好移动设备的内存本来就紧张把整个视频读进内存再上传很容易触发系统杀进程分片之后每次只处理一小块数据内存占用曲线会平缓很多。第三是可恢复性分片上传天然支持断点续传用户切到后台再回来或者网络短暂中断都能从已上传的分片继续不用重新开始。适合阅读这篇内容的人我大致分三类。一类是刚接触Flutter跨平台开发、正在做文件上传功能的开发者你可以直接参考这里的流程和代码结构。另一类是有一定经验但没处理过大文件分片的后端或全栈工程师这里会讲到分片策略、合并逻辑和校验机制。还有一类是技术负责人需要评估分片上传方案的复杂度和落地成本我也会把踩过的坑和取舍讲清楚。整体方案我采用的是“前端分片 逐片上传 服务端合并”的经典架构。前端负责读取视频文件、按固定大小切分、维护上传状态服务端负责接收分片、临时存储、校验完整性、最终合并。这个架构不依赖特定的云服务自己搭一套也能跑起来灵活性比较高。下面我会从技术选型、核心细节、实操流程、问题排查几个维度展开把每个环节的“为什么”讲透。2. 技术选型与核心细节解析2.1 为什么选Flutter做视频选择与分片Flutter本身是跨平台的一套代码能跑在Android和iOS上这对需要快速覆盖多端的项目来说很关键。视频选择这块社区里比较成熟的方案是image_picker和file_picker这两个库。image_picker对相册视频的支持比较直接调用pickVideo方法就能拿到文件路径file_picker则更通用能选任意类型文件但视频预览体验稍弱。我最终选了image_picker因为它的API更简洁而且对相册权限的处理比较完善。拿到文件路径之后分片操作其实是在Dart层做的。这里有个关键点不要试图把整个视频读成字节数组再切分。我试过用File.readAsBytes()一次性读取一个200MB的视频直接让内存飙到几百兆低端机当场卡死。正确做法是用RandomAccessFile或者File.openRead()配合Stream按偏移量逐段读取。Dart的File类提供了open方法返回RandomAccessFile可以精确控制读取位置和长度这样每次只把一片的数据加载到内存。分片大小我建议设在1MB到5MB之间。太小会导致请求数量暴增服务端压力大太大又失去了分片的意义。我实测下来2MB是一个比较平衡的值一个100MB的视频大概50片上传过程比较流畅。当然这个值可以根据网络状况动态调整比如WiFi下用5MB移动网络下用1MB但那是进阶优化第一版先固定值跑通再说。2.2 分片上传的通信协议设计分片上传不是简单地把文件切开发出去就完事了前后端需要约定一套协议。我设计的接口大致是这样的前端每次上传一个分片请求里带上fileId文件唯一标识、chunkIndex当前分片序号、totalChunks总分片数、chunkData分片二进制数据。服务端收到后把分片存到以fileId命名的临时目录下文件名用chunkIndex区分。这里有个细节容易被忽略fileId的生成时机。我一开始是在前端生成一个UUID但后来发现如果用户重复选择同一个视频fileId会变导致服务端无法识别这是同一个文件。更好的做法是用文件的哈希值或者“文件名文件大小修改时间”组合生成一个稳定ID。不过计算哈希需要读取整个文件对大文件来说耗时较长所以我最终用了“文件名大小最后修改时间戳”的MD5既稳定又不用全量读取。另一个关键点是分片校验。每个分片上传时我会额外传一个chunkHash服务端收到后校验分片完整性。如果校验失败返回错误码前端重传这一片。全部上传完成后前端再发一个“合并请求”服务端按顺序拼接所有分片并计算最终文件的哈希和前端传来的总哈希比对确保合并结果正确。2.3 断点续传的状态管理断点续传的核心是“知道哪些片已经传成功了”。我的做法是在前端维护一个上传状态对象记录fileId、已上传的分片索引列表、总分片数。每次上传前先请求服务端的“检查接口”服务端返回已接收的分片列表前端对比后只上传缺失的部分。这个状态对象需要持久化否则应用被杀掉再打开就丢了。我用的是shared_preferences存一个JSON字符串结构很简单{fileId: {uploaded: [0,1,2], total: 50}}。每次分片上传成功后更新这个对象应用启动时读取如果有未完成的任务就提示用户继续上传。注意状态持久化不要存分片数据本身只存索引和元信息。分片数据是临时的存了反而占空间而且可能过期。2.4 服务端合并策略与存储设计服务端我用的是Node.js配合Express临时分片存在本地磁盘的temp/{fileId}/目录下。合并的时候按chunkIndex排序用fs.createWriteStream逐片追加写入最终文件。这里有个坑不要用fs.readFileSync读所有分片再拼接那样内存会爆。正确做法是用流式写入每次读一片写一片内存占用恒定。合并完成后我会做三件事一是计算最终文件的MD5和前端传来的总哈希比对二是删除临时分片目录释放空间三是把最终文件移到正式存储目录返回访问URL。如果比对失败说明分片有问题需要清理并让前端重新上传。存储设计上我建议临时目录和正式目录分开临时目录可以设置定时清理任务比如超过24小时未合并的分片自动删除避免磁盘被占满。正式目录按日期分文件夹比如uploads/2025/01/15/方便管理和备份。3. 实操过程与核心环节实现3.1 视频选择与文件信息读取第一步是让用户选视频。用image_picker的代码大概长这样final ImagePicker picker ImagePicker(); final XFile? video await picker.pickVideo(source: ImageSource.gallery); if (video null) return; final File file File(video.path); final int fileSize await file.length(); final String fileName video.name; final DateTime lastModified await file.lastModified();拿到文件后先算fileId。我用的是crypto库的MD5final String rawId $fileName-$fileSize-${lastModified.millisecondsSinceEpoch}; final String fileId md5.convert(utf8.encode(rawId)).toString();然后算总分片数const int chunkSize 2 * 1024 * 1024; // 2MB final int totalChunks (fileSize / chunkSize).ceil();这里要注意fileSize是字节数chunkSize也是字节除法之后向上取整。比如一个5MB的文件totalChunks就是3最后一片可能不足2MB这是正常的。3.2 分片读取与上传的完整流程分片读取我用的是RandomAccessFilefinal RandomAccessFile raf await file.open(); for (int i 0; i totalChunks; i) { final int start i * chunkSize; final int end (start chunkSize fileSize) ? fileSize : start chunkSize; final int length end - start; await raf.setPosition(start); final Uint8List chunk await raf.read(length); // 上传这一片 await uploadChunk(fileId, i, totalChunks, chunk); } await raf.close();uploadChunk方法用http库的MultipartRequest发送Futurevoid uploadChunk(String fileId, int index, int total, Uint8List data) async { final uri Uri.parse(https://your-server.com/upload/chunk); final request http.MultipartRequest(POST, uri); request.fields[fileId] fileId; request.fields[chunkIndex] index.toString(); request.fields[totalChunks] total.toString(); request.files.add(http.MultipartFile.fromBytes(chunk, data, filename: chunk_$index)); final response await request.send(); if (response.statusCode ! 200) { throw Exception(分片 $index 上传失败); } }这里有个性能优化点不要串行上传所有分片。串行虽然简单但速度慢。我改成了并发上传用Future.wait控制并发数比如同时传3片。但并发数不能太高否则移动网络下容易超时而且服务端压力也大。我实测3到5是比较合适的值。final ListFuturevoid tasks []; for (int i 0; i totalChunks; i) { if (uploadedChunks.contains(i)) continue; // 跳过已上传的 tasks.add(uploadChunk(fileId, i, totalChunks, chunkData)); if (tasks.length 3) { await Future.wait(tasks); tasks.clear(); } } if (tasks.isNotEmpty) await Future.wait(tasks);3.3 服务端接收分片与合并的代码实现服务端用Express接收分片const express require(express); const multer require(multer); const fs require(fs); const path require(path); const app express(); const upload multer({ dest: temp/ }); app.post(/upload/chunk, upload.single(chunk), (req, res) { const { fileId, chunkIndex, totalChunks } req.body; const tempDir path.join(__dirname, temp, fileId); if (!fs.existsSync(tempDir)) { fs.mkdirSync(tempDir, { recursive: true }); } const chunkPath path.join(tempDir, chunkIndex); fs.renameSync(req.file.path, chunkPath); res.json({ code: 0, message: ok }); });合并接口app.post(/upload/merge, async (req, res) { const { fileId, totalChunks, fileName } req.body; const tempDir path.join(__dirname, temp, fileId); const finalDir path.join(__dirname, uploads, new Date().toISOString().slice(0, 10)); if (!fs.existsSync(finalDir)) { fs.mkdirSync(finalDir, { recursive: true }); } const finalPath path.join(finalDir, fileName); const writeStream fs.createWriteStream(finalPath); for (let i 0; i totalChunks; i) { const chunkPath path.join(tempDir, i.toString()); const chunkData fs.readFileSync(chunkPath); writeStream.write(chunkData); } writeStream.end(); writeStream.on(finish, () { // 清理临时目录 fs.rmSync(tempDir, { recursive: true, force: true }); res.json({ code: 0, url: /uploads/${fileName} }); }); });这段代码里fs.readFileSync读单片是没问题的因为单片只有2MB内存占用可控。但如果你把分片大小设成50MB那就得改成流式读取了。3.4 上传进度与用户反馈的实现用户需要知道上传到哪了。我在前端维护一个progress变量每上传成功一片就更新double progress uploadedCount / totalChunks;然后用StreamBuilder或者setState刷新UI。这里有个细节进度更新不要太频繁否则UI会卡。我是在每片上传成功后更新一次50片就是50次更新完全没问题。如果你把分片设得很小比如100KB那更新次数会很多可以考虑每5片更新一次。另外上传过程中要允许用户取消。我用了一个bool _isCancelled标志在循环里检查如果取消了就跳出循环并调用服务端的“取消上传”接口清理临时分片。提示取消上传后记得把持久化的状态也清掉否则下次进来还会提示继续上传。4. 常见问题与排查技巧实录4.1 分片上传中的典型问题速查表问题现象可能原因排查方法解决方案上传到一半卡住网络超时或并发过高查看日志中哪个分片没返回降低并发数增加超时重试合并后文件损坏分片顺序错乱或缺失比对分片数量和索引合并前校验分片完整性内存占用飙升一次性读取整个文件用Profiler看内存曲线改用RandomAccessFile逐片读断点续传失效状态未持久化或fileId变化检查shared_preferences内容用稳定fileId及时保存状态服务端磁盘占满临时分片未清理查看temp目录大小加定时清理任务iOS上传失败权限或后台限制查看系统日志申请相册权限处理后台任务4.2 我踩过的三个坑与解决方案第一个坑是iOS后台上传被系统挂起。iOS对后台任务限制很严应用切到后台几秒后网络请求就会被暂停。我一开始没处理用户切出去回个消息上传就断了。后来用了background_fetch或者flutter_background_service这类库把上传任务放到后台isolate里跑情况好了很多。但要注意iOS后台时间有限大文件还是建议提示用户保持前台。第二个坑是分片哈希校验的性能问题。我一开始对每个分片都算MD5结果发现CPU占用很高上传速度反而慢了。后来改成只对分片做简单的长度校验总文件才做MD5。这样既保证了完整性又不会拖慢速度。如果你对安全性要求极高可以保留分片哈希但要做好性能测试。第三个坑是服务端合并时的文件句柄泄漏。我用fs.createWriteStream写文件但忘记在finish事件里关闭流导致大量文件句柄没释放跑一段时间后服务端就报“too many open files”。后来加了writeStream.close()和错误处理才解决。这个坑很隐蔽因为短期内看不出问题跑久了才暴露。4.3 性能优化的几个实用技巧技巧一动态分片大小。根据网络类型调整分片大小WiFi下用5MB4G用2MB弱网用512KB。这样能在不同网络下都有不错的表现。实现上可以用connectivity_plus库检测网络类型。技巧二分片压缩。如果视频不需要原始画质可以在前端用ffmpeg做压缩再上传。不过Flutter里集成ffmpeg比较重我一般建议在服务端做转码前端只负责上传原始文件。技巧三秒传检测。上传前先算文件哈希请求服务端检查是否已存在相同文件。如果存在直接返回URL不用上传。这个对热门视频特别有效能省大量带宽。但哈希计算需要读整个文件对大文件来说耗时可以只算前1MB的哈希做粗略判断。技巧四分片预签名URL。如果服务端支持对象存储可以给每个分片生成预签名URL前端直接传到存储服务不经过应用服务器。这样能大幅降低服务器压力但架构会复杂一些适合大规模场景。注意预签名URL有有效期生成后要尽快使用否则会过期导致上传失败。4.4 安全性与合规性注意事项分片上传涉及文件写入安全上要特别注意几点。一是文件类型校验不能只信前端传来的扩展名服务端要检查文件头魔数确保是真正的视频文件。二是分片大小限制防止恶意用户上传超大分片撑爆内存。三是fileId防猜测不要用自增ID用UUID或者哈希避免被遍历。四是临时目录权限确保只有应用进程能读写防止其他用户访问。另外如果应用面向多用户要做好鉴权。每个上传请求都要带token服务端验证用户身份后再允许写入。合并时也要检查该用户是否有权限操作这个fileId防止越权。4.5 测试与验证的完整流程上线前我做了几轮测试。第一轮是功能测试用不同大小的视频10MB、100MB、500MB跑完整流程确认能选、能分、能传、能合并。第二轮是异常测试模拟网络中断、服务端重启、磁盘满等情况看断点续传和错误处理是否正常。第三轮是性能测试用JMeter或者wrk压测服务端看并发上传时的吞吐量和响应时间。测试时我建议用真机不要只用模拟器。模拟器的网络和存储行为和真机差别很大尤其是iOS模拟器后台任务行为和真机完全不同。真机上还要测不同网络环境比如WiFi切4G、弱网、高延迟这些场景下分片上传的表现才是真实的。验证合并结果时我会用md5sum对比前后端文件哈希。如果一致说明分片和合并都没问题。如果不一致就逐片比对找出是哪一片出了问题。这个排查过程比较耗时但能精确定位问题。5. 方案扩展与个人经验体会这套分片上传方案跑通之后我做了几个扩展。一个是多文件并发上传用户一次选多个视频每个文件独立维护状态用队列控制总并发数。另一个是上传优先级小文件优先传大文件后台慢慢传提升用户感知速度。还有一个是失败自动重试分片上传失败后自动重试3次超过次数才提示用户。我个人在实际操作中的体会是分片上传的复杂度主要不在分片本身而在状态管理和异常处理。分片逻辑写起来很快但断点续传、并发控制、错误恢复这些才是真正花时间的地方。我建议第一版先把串行上传跑通确认流程没问题再逐步加并发、加断点续传、加动态分片。不要一上来就追求完美那样很容易卡在细节里出不来。最后再分享一个小技巧日志要打全。每个分片的上传时间、大小、结果都记下来出问题的时候一看日志就知道是哪一片、什么原因。我一开始日志打得很简略排查问题时只能靠猜后来加了详细日志排查效率提升了好几倍。这个习惯在移动端开发里特别重要因为真机调试不像Web那么方便日志往往是你唯一的线索。