作金融项目前端这些年最怕听到的一句话就是就一个上传功能找个控件接一下不就行了。大文件上传尤其是金融行业里动辄几百MB、甚至几个G的报表、合同影像、交易流水文件远不是一个input typefile加个进度条就能糊弄过去的。所以我每次遇到这类需求第一件事不是选控件而是先花两三天做一个DEMO用真实文件、真实接口把方案跑通。这个DEMO不是给领导看的炫技页面而是用来回答分片怎么切、断点怎么续、并发怎么控、异常怎么恢复、合规怎么满足这些问题的。这篇文章就把我在金融场景下做Vue大文件上传控件DEMO的完整思路、代码和踩过的坑都摊开来讲给打算接这类活儿的同学一个能直接参考的底子。1. 金融场景的大文件上传到底难在哪先想清楚再动手1.1 一个普通上传需求背后的隐性要求很多从外包或者互联网项目转过来的前端同事一开始都觉得大文件上传不就是把文件变大、超时时间调长吗这种想法在金融项目里会死得很难看。先说几个金融场景的硬约束你就知道为什么不能拿普通项目那套来套第一文件体量不是一般的大。银行间交易流水导出一个对账文件几百MB算是中等水平基金托管业务里的估值表、清算文件动辄1GB以上再碰上审计影像压缩包几个G都有的。普通表单上传顶多撑个几十MB超过200MB不管是nginx的client_max_body_size还是网关的超时时间都会直接把连接掐断。第二业务连续性要求极高。银行、券商、保险的报送系统都有窗口期比如日终批处理只有凌晨几个小时。如果上传中断了整个重来可能就赶不上监管报送截止时间这是事故级别的问题不是刷新重试就能交差的。第三安全与合规审计一条不能少。文件传输要加密、要有操作留痕、要能追溯谁在什么时间传了什么文件甚至文件内容本身的关键字段要做脱敏或完整性校验。普通的第三方上传组件根本不带这些能力你后期拿胶水糊也糊不严实。第四网络环境不可控。不要以为政企客户的内网带宽都很大。证券营业部到总部的专线、移动展业人员在4G/5G环境下传尽调材料弱网、抖动、断线都是常态。方案必须能断了接着传而不是断了从头来。所以你会发现金融场景的大文件上传本质上不是控件选择问题而是一整套容错、安全、可控的传输方案问题。DEMO要验证的正是这套方案能不能在真实约束下跑通。1.2 先做DEMO到底是为了验证什么我见过不少团队跳过DEMO直接上控件结果联调阶段问题爆发的例子。等你在测试环境发现分片顺序错乱、服务器合并超时、并发连接被网关限流的时候再回头改方案成本至少翻三倍。一个合格的大文件上传DEMO至少要能回答这七个问题大文件在前端如何切片切片大小怎么定文件唯一标识怎么生成并发上传时后端如何识别是同一个文件断点续传靠什么实现秒传靠什么实现多个分片并发上传时浏览器的并发上限怎么控制传一半失败了重试机制怎么设计服务端怎么接收分片、校验分片、合并分片传输过程中文件内容如何加密审计日志怎么记这些问题里任何一个没有想清楚直接上生产都是给自己埋雷。DEMO的意义就是用最小成本把这七个问题全部验证一遍把雷提前排掉。2. 为什么不直接引一个现成的控件选型之前的交锋2.1 现成组件在金融场景里的硬伤我知道很多人的第一反应是GitHub上一堆Vue上传组件Star上万拿来即用不香吗香但那是在普通业务场景下。金融项目里现成组件有几个绕不过去的硬伤传输协议固定大部分组件走的是HTTP POST把文件交给后端后端接收后写磁盘。对于大文件缺少服务端配合的预检、断点记录、分片管理能力或者有也是浅尝辄止。安全能力缺失文件加密、国密算法支持、审计日志埋点这些商业级能力基本没有。你总不能指望一个开源组件帮你做等保合规。改造难度不可控为了适配内部网关、统一身份认证IAM、单点登录SSO、操作日志平台你往往需要魔改源码。改到最后版本都升不上去维护成本极高。大文件场景没经过压测大多数开源组件在几百MB的文件下表现尚可但到了1GB以上、并发10个分片时内存占用、超时控制、错误处理都很容易出问题。还有一个金融行业特别在意的问题组件依赖的可控性。很多机构对第三方依赖有严格的安全审查一旦引入的组件被发现高危漏洞你自己又没能力修那就非常被动。2.2 自研控件的边界DEMO跑通哪些就可以动手那是不是意味着全自研也不需要。我的建议是传输内核自研界面组件自研但底层的加密库、Hash计算库、HTTP客户端可以选经过安全审查的成熟依赖。也就是说DEMO要跑通的核心链路切片、预检、并发、合并、续传必须自己掌控这是方案的核心竞争力不能靠黑盒组件。至于UI上的拖拽、缩略图、进度动画这些反而无所谓简单实现即可。在我实际负责的项目里最终形态是一个内部npm包形式的Vue插件封装了PendingUpload组件、useUploader组合式API以及一套和后端约定的协议。DEMO阶段就用这套API写了个最简页面验证核心逻辑后续接业务系统时业务方只需要传文件、监听事件不需要关心分片和续传的细节。这就叫控件——不是界面上一个框而是整套可复用的上传能力。3. DEMO的端到端方案设计五层结构先把边界划清楚3.1 整体架构的核心设计原则大文件上传DEMO的整体方案我习惯分成五层接入层、策略层、传输层、存储层、审计层。接入层负责和业务系统对接暴露的是一句话上传的接口。策略层处理文件的预检、分片大小的动态计算、是否启用并发、重试次数等规则。传输层是内核负责分片的实际发送、收到响应后的确认、进度汇总。存储层对接对象存储或文件服务既要保证写入速度又要保证合并后文件完整。审计层则把谁、什么时候、传了什么文件、每个分片的耗时、是否有重试、最终结果全部记录到审计系统。分层的好处是职责清晰。比如金融客户问分片大小为什么是8MB你可以在策略层解释这取决于带宽、服务端性能和你设定的并发数。换成2MB或者16MB只是改策略不会动传输内核。3.2 为什么分片必须是字节级的精确设计分片上传的核心是前端把文件切成多个二进制块分别上传。关键在于切片的边界必须基于字节位置而不是基于行、页或者其他业务维度。以8MB分片为例假设文件总大小是100MB那么分片顺序是第1片字节 0 到 8MB-1第2片字节 8MB 到 16MB-1以此类推直到最后一片大小不超过8MB前端用Blob.prototype.slice()来切这个方法在浏览器里非常成熟效率也很高。切完每片后前端为该片生成一个序号从0开始连同文件唯一标识一起发给后端。后端收到后严格按序号写入临时文件块的对应偏移位置。注意这里的偏移位置应该用该片在整个文件中的起始字节位置来计算也就是总片数之前的字节总数这样即使中间有片丢了或者重传了也不会覆盖错位置。我见过一个常见的错误有人用数据库表的自增ID来记录分片顺序结果并发上传时先到的分片ID是5后到的ID是3合并时按错误的ID排序文件就损坏了。所以DEMO里我始终坚持的是分片序号和文件字节偏移强绑定由前端算好带过去后端只认这个偏移量。4. Vue端核心实现从切片到断点续传的完整代码拆解4.1 环境准备与依赖选型DEMO我用的技术栈是Vue 3.4 Vite 5 TypeScript。为什么用TypeScript因为金融项目对代码可维护性要求高上传这种核心模块接口类型定义清楚后续接手的同事不容易改坏。需要引入的核心依赖其实很少spark-md5用来计算整个文件的MD5或者更严谨一点用SHA-256作为文件的唯一标识。计算Hash的耗时操作放到Web Worker里做避免阻塞UI线程。axios做HTTP请求实际上手写XMLHttpRequest或fetch也行但axios在取消请求、超时控制、并发限制上更省事。可选crypto-js或electron/remote相关加密能力取决于你是否需要在浏览器侧对分片内容做加密。金融场景通常更推荐HTTPS链路加密服务端加密存储尽量不要在浏览器侧做重量级加密性能损耗大。安装命令很简单npm create vitelatest bigfile-upload-demo -- --template vue-ts cd bigfile-upload-demo npm install axios spark-md54.2 文件唯一标识的计算为什么必须在Worker里算Hash文件唯一标识就是文件的Hash值。它的用途有两个一是做断点续传时服务端靠它识别这个文件之前传过哪些分片二是做秒传服务端发现整个文件的Hash已存在直接返回上传成功省掉所有分片传输。大文件计算Hash最忌讳的就是在主线程做。一个500MB的文件即使只算一次全量MD5在一般笔记本上也要好几秒甚至十几秒期间UI直接卡死用户以为页面崩溃了。所以DEMO里的标准姿势是把文件对象postMessage给Web Worker在Worker里读文件、算Hash算完再把结果传回主线程。下面是一个简单的Web Worker文件hash-worker.ts/// reference libwebworker / import SparkMD5 from spark-md5; self.onmessage (e: MessageEventFile) { const file e.data; const chunkSize 2 * 1024 * 1024; // 读文件时每次2MB避免一次占用太多内存 const spark new SparkMD5.ArrayBuffer(); let currentChunk 0; const totalChunks Math.ceil(file.size / chunkSize); const fileReader new FileReader(); const loadNext () { const start currentChunk * chunkSize; const end Math.min(start chunkSize, file.size); fileReader.readAsArrayBuffer(file.slice(start, end)); }; fileReader.onload (event) { spark.append(event.target!.result as ArrayBuffer); currentChunk; if (currentChunk totalChunks) { loadNext(); } else { const fileHash spark.end(); self.postMessage({ fileHash, fileSize: file.size, fileName: file.name }); } }; fileReader.onerror () { self.postMessage({ error: 文件读取失败 }); }; loadNext(); };主线程里通过new Worker来调用Worker结束后要记得terminate()释放资源。提示如果用Vite打包Worker文件要用new Worker(new URL(./hash-worker.ts, import.meta.url), { type: module })这种形式引入否则生产环境打包容易404。4.3 分片上传器的核心逻辑预检、切片、并发、续传DEMO的核心是一个useUploader组合式函数它把上传状态机完整封装起来。先看状态设计pending已选择文件正在算Hash还没开始上传。checking正在调后端预检接口。uploading至少一个分片正在上传。paused用户主动暂停或前端主动停止。completed所有分片上传完成且服务端合并成功。error出现了无法自动恢复的错误。预检接口的协议很关键我设计的请求和响应如下// 请求 interface CheckRequest { fileHash: string; fileName: string; fileSize: number; } // 响应 interface CheckResponse { uploadedChunks: number[]; // 服务端已收到的分片序号 chunkSize: number; // 服务端要求的分片大小两端必须一致 needUpload: boolean; // 是否需要继续上传 uploadId: string; // 本次上传任务的ID后续所有分片请求都带上 }为什么预检要返回uploadId因为同一个文件可能不同人、不同时间上传过服务端要保证每个上传任务有独立的上下文避免分片数据互相覆盖。uploadId相当于这个上传任务的身份证。主线程的上传流程伪代码如下async function upload(file: File) { const fileHash await calculateHash(file); // Worker计算 const checkResult await checkExist({ fileHash, fileName: file.name, fileSize: file.size }); if (!checkResult.needUpload) { status.value completed; // 秒传 return; } const chunkSize checkResult.chunkSize; const chunkList createChunks(file, chunkSize, checkResult.uploadedChunks); status.value uploading; await concurrentUpload(chunkList, { uploadId: checkResult.uploadId, fileHash, concurrency: 3, // 并发数 }); await notifyMerge(uploadId, fileHash); status.value completed; }createChunks这一步会过滤掉uploadedChunks里已有的分片只上传没传过的部分这就是断点续传的落地逻辑。4.4 并发上传与进度计算没有进度条的上传是反人类的并发上传的实现在DEMO里是重头戏。浏览器对同一个域名的并发HTTP连接数是有限制的HTTP/1.1一般是6个HTTP/2虽然是多路复用但服务端依然可以限流所以我们要自己维护一个请求池控制同时最多3到5个分片在上传。核心思路是维护一个待上传队列和一个正在上传的Set每结束一个就从队列里取一个新的补上直到队列清空。async function concurrentUpload(chunkList, options) { const { concurrency, uploadId, fileHash } options; const queue [...chunkList]; const active new SetPromisevoid(); const uploadOne async (chunk) { const formData new FormData(); formData.append(uploadId, uploadId); formData.append(fileHash, fileHash); formData.append(chunkIndex, String(chunk.index)); formData.append(chunkTotal, String(chunk.total)); formData.append(file, chunk.blob, chunk-${chunk.index}); const response await axios.post(/api/upload/chunk, formData, { timeout: 60_000, onUploadProgress: (e) { // 累加到当前分片的上传进度再汇总更新整体进度 }, }); return response.data; }; for (let i 0; i concurrency queue.length 0; i) { const task uploadOne(queue.shift()!).catch((err) { // 失败进重试队列或标记失败 throw err; }); active.add(task); task.finally(() { active.delete(task); if (queue.length 0 status.value uploading) { const next uploadOne(queue.shift()!); active.add(next); } }); } await Promise.allSettled(active); }这里有个细节值得说进度条怎么算才准确不能只看已上传字节 / 总字节因为并发时你只有每个分片自己的onUploadProgress事件。正确做法是每个分片维护一个loaded整体进度 所有分片的loaded之和 / 文件总大小。所以我通常会用一个MapchunkIndex, number来记录每个分片已经上传的字节数然后每100ms汇总一次触发Vue的响应式更新。4.5 失败重试与暂停恢复什么该自动什么该给人决定弱网环境下分片上传失败是常态DEMO里必须验证重试策略。我的原则是网络请求失败超时、断连自动重试最多3次退避策略采用指数退避第一次等1秒第二次等2秒第三次等4秒。服务端返回业务错误如分片校验失败不自动重试直接报错提示用户。因为业务错误往往意味着协议的bug或数据损坏重试也没用。用户主动暂停暂停状态下queue和active里的任务立即停掉利用AbortController但已传成功且收到确认的分片保留。恢复时重新调用预检接口把已上传的分片序号拿回来只传剩余部分。暂停恢复的代码里最容易踩的坑是axios的CancelToken已经废弃了要用AbortController。每个请求创建时绑定一个signal暂停时触发abort浏览器会自动断开这个HTTP请求后端收到的就是不完整的请求但不会写坏文件因为后端只有在完整收到某一个分片的所有字节后才会记录该分片已上传。5. 后端配合与联调接口约定不能拍脑袋定5.1 服务端接口的最小集预检、单分片、合并、进度查询前端做得再好后端接口设计不合理也白搭。DEMO阶段后端只需要提供四个接口接口方法路径作用预检POST/api/upload/check传文件Hash返回已上传分片、分片大小、uploadId上传分片POST/api/upload/chunk上传单个分片携带uploadId、分片序号、文件blob合并POST/api/upload/merge通知后端可以合并分片返回最终文件访问地址进度查询GET/api/upload/progress/:uploadId查询服务端收到的分片列表可用来校准前端进度这四个接口缺一不可。很多开发图省事把合并和最后一片上传合并成一个动作即最后一片传上去后后端自动触发合并。听着挺聪明实际上很危险最后一片传到了但结合前面的分片还没有完全落盘误触发合并就会拿到不完整的文件。宁可多请求一次也不要合并时机含糊。5.2 分片落盘与合并校验如何避免合并出损坏文件服务端收到每个分片后必须做两件事一是校验分片序号是否在合法范围内二是校验分片的实际字节数是否和文件头记录的一致。金融场景对文件完整性要求极高我甚至在DEMO里就让后端为每个分片额外计算一次CRC32或MD5和前端随分片携带的校验值比对不匹配直接拒绝。分片落盘策略我推荐临时文件块方案每个上传任务在存储目录下创建/uploadTemp/{uploadId}/目录分片按chunkIndex命名例如000.part、001.part每个分片写入完成后记录一条分片完成的元数据文件路径、字节数、校验值合并时按分片序号顺序把每个.part文件按二进制拼接成大文件合并过程有一个性能问题必须提前知道如果直接用fs.readFileSync挨个读再写几百个分片性能很差。建议用流式管道例如Node.js里的fs.createReadStream配合pipe方法。另外合并完成之后要对整个文件再算一次Hash和前端算出的文件Hash比对一致才算合并成功。这一步每个金融项目都不能省否则文件内容在传输过程中被篡改或损坏等业务跑起来才发现就晚了。5.3 网关、超时、限流联调阶段最常见的三个坑第一个坑是代理网关的body大小限制。很多金融机构的前端请求要经过统一的API网关网关默认限制POST请求体大小通常只有几MB。分片方案本身已经把单次请求体控制在分片大小以内但如果你的分片是64MB网关照样拦。要么把分片改小要么让运维给这个上传接口单独放开限制。DEMO阶段我就吃过亏调了一天发现所有分片都超时后来抓包看到网关直接返回413 Payload Too Large。第二个坑是请求超时时间。一般业务接口的网关超时是30秒但对上传分片来说即使是8MB的分片在弱网下完全可能传超过30秒。所以联调时一定要确认这个上传接口的超时时间单独调长通常是2到5分钟。前端axios里的timeout也要相应调长不然你自己的请求先断了。第三个坑是并发连接数。如果生产环境走的是HTTP/1.1且前面还有Nginx那并发4个分片已经是比较稳妥的上限。并发数不是越大越好越大越容易触发服务端的连接数限制和Nginx的worker_connections瓶颈。DEMO里建议从3开始压再逐步调大结合服务端监控的CPU和内存表现找一个平衡值。6. 金融合规视角DEMO阶段就要把加密、审计、权限设计进去6.1 传输与存储加密不是加了HTTPS就万事大吉很多开发认为HTTPS上了传输就安全了这在金融合规面前明显不够。HTTPS保护的是链路但文件到了服务端之后如果不做应用层加密任何能接触到磁盘的人都可以直接拿走原始文件。金融场景常见的做法是链路层全链路HTTPS内部网关再做双向TLS。应用层敏感文件在上传前由前端或用服务端下发密钥用国密SM4或AES-256-GCM对分片内容进行加密服务端存的是密文读取时再解密。存储层对象存储开启服务端加密SSE或KMS密钥管理确保磁盘上的文件也是密文。在DEMO里我不会让前端真的做完整加密——因为浏览器侧加密性能有限一GB文件逐片加解密会非常慢。更合理的做法是让加密集中在服务端入口统一处理即前端上传的是原始分片服务端在接收到之后、落盘之前执行加密。这样既保证了存储安全又不影响前端的传输性能。但这里需要特别说明如果业务要求文件在传输过程中任何节点都不可见明文那就只能前端加密、服务端解密存储。代价是CPU消耗和复杂度大增DEMO阶段至少要把这条链路的性能跑出一个参考数据。你可以在DEMO验证报告里列一张表记录加密与不加密情况下1GB文件总耗时的差异让业务方来做决策。这才是金融人该有的做事方式用数据说话而不是空谈合规。6.2 审计日志上传流程里必须记的九个字段金融行业的审计要求一般会追溯到何时、何人、何操作、结果如何。上传模块的审计日志我在DEMO里预留了这些字段字段说明操作人ID当前登录用户唯一标识操作时间开始上传时间文件名原始文件名文件大小字节数文件Hash完整性校验用uploadId关联到具体上传任务分片总数总片数成功分片数最终成功的分片数上传结果成功/失败/暂停/超时重试次数等日志的采集点建议埋在上传流程的关键节点上预检通过、第一个分片开始、最后一个分片完成、合并且校验成功、任一分片失败重试、最终异常终止。这些日志不要只记异常正常流程也要记否则审计方无法核对为什么这个任务中间断了一天。日志上报推荐的模式是前端异步批量上报不阻塞上传主流程如果审计接口挂了也不能影响业务。6.3 权限与身份传递前端不要自己决定谁能传金融系统通常已经接入了统一权限中心前端在上传前要通过HTTP头或cookie把登录态传递过去由后端来校验这个用户有没有上传权限、文件类型是否在白名单里、目录是否允许写入。前端千万不要做根据角色hide上传按钮这种逻辑就以为安全了因为接口是可以被直接调用的。DEMO里的做法是用户选择文件后先调预检接口预检接口内部完成权限校验没有权限就直接返回403前端提示无上传权限请联系管理员根本不会进入分片上传流程。文件类型校验同理不能只在前端用suffix判断服务端必须用文件魔数Magic Number等二进制特征识别真实类型。为什么很简单一个攻击者可以随便把一个exe文件改名为.pdf传上来前端看到.pdf就放行但服务端如果也只看后缀那就出了大问题。DEMO阶段我就在服务端预检接口里加了对常见金融文件类型的魔数校验比如PDF的%PDF、ZIP的PK、Excel的D0CF11E0等。这个设计并不复杂但能堵住非常大的一类风险。7. DEMO实测与踩坑实录从能跑到能用的距离7.1 我跑的三个典型测试场景和结果DEMO写完之后光看能传上去还不算完你得用真实场景去压它。我记录过三个有代表性的实验第一个场景是500MB的银行流水文本文件普通内网环境带宽约50MB/s。分片大小为8MB并发3。实测结果总耗时约11秒CPU和内存都平稳整个上传过程页面无卡顿因为Hash计算在Worker里上传也是异步并发。这个场景验证了基本性能。第二个场景是模拟弱网用Chrome DevTools的网络面板把带宽限到1MB/s并设置20%的请求失败率。结果很快暴露了一个问题失败重试的退避逻辑没加抖动脉冲jitter多个分片同时重试导致服务端瞬时压力飙升。后来在重试间隔上加了随机抖动压力才降下来。第三个场景是强制中断2GB的压缩包传到60%时直接把电脑休眠再唤醒。恢复后重新进入页面选择同一个文件预检接口返回了已上传分片列表前端精准跳过60%的分片只传剩下40%最后合并校验的Hash和前端计算的一致。这个场景如果过了断点续传的核心价值才算真正被验证。7.2 我在DEMO里踩过的五个具体的坑第一个坑是Blob.slice在火狐浏览器的兼容性问题。早期火狐不支持blob.slice()要用blob.mozSlice()来兼容。现在主流浏览器都支持了但如果你要兼容老旧政企环境里的浏览器内核还是得做特性判断。第二个坑是FileReader在读取超大文件时的内存问题。如果你一次性把整个500MB文件readAsArrayBuffer浏览器内存直接飙升甚至崩溃。正确做法是分片读取就像我在Worker里写的那样每次只读2MB。这和上传分片是两个维度的事情别混淆。第三个坑是FormData.append(file, blob, filename)时如果blob的type为空某些服务端框架可能无法正确识别Content-Type。我后来都手动给blob指定type: application/octet-stream避免后端解析错误。第四个坑是并发数为1时反而不稳定。听起来反直觉但实际情况是某些浏览器在串行上传时如果前一个请求因为网络原因pending住后面的请求永远发不出去。加一点并发反而能通过多路传输规避单连接被掐断的问题。第五个坑是进度条回退。服务端合并分片也需要时间如果合并完成后才置进度100%用户在传完最后一片后会看到进度条卡在99%好几秒。我处理的方式是第一合并前先把进度置为100%文案显示等待服务端合并第二服务端在merge接口里返回一个任务状态字段前端轮询或等通知后再更新状态。用户感知会好很多。7.3 验收时建议用到的一套完整检查清单DEMO阶段结束、准备进正式开发前我建议团队过一遍这个清单逐项打钩功能类1GB以上文件能完整上传断网恢复后能续传重复上传同一文件能秒传暂停之后能恢复删除文件后重新选择不影响任务。性能类上传超大文件时页面不卡顿内存占用不超过500MB以目标浏览器为准并发分片数可配置且能稳定运行日志上报不拖慢主流程。安全类无权限用户被预检接口拒绝上传接口限制了文件类型文件名带有危险字符如../、..\\被拦截分片内容校验失败能重传或终止所有关键操作已产生审计日志。兼容类Chrome最新两个版本、Edge、火狐、企业内网常用的国产浏览器如奇安信、360安全浏览器都能正常上传。故障演练类手动杀掉服务端进程观察前端是否会自动重试并保留已传分片重启服务端后能通过预检接口找回进度。这套清单是我从多个金融项目里总结出来的直接拿去用不会错。每过一项就代表DEMO离能上生产近了一步。8. 后续演进的可能性从能用到好用的几点建议DEMO只是起点真正落地到业务系统里还有几件事值得投入。第一是文件的秒传策略可以做得更细比如按文件Hash做内容去重不仅同一个用户重复传可以秒传不同用户传相同文件也可以秒传。金融机构的很多报表都是系统生成的内容相同的概率极高去重能省下大量存储和带宽成本。第二是上传任务的持久化。如果业务系统需要展示历史上传记录失败任务重新提交上传任务的关键状态就要落到业务数据库里而不只是靠服务端临时目录里的分片状态推断。我建议在上传任务结束时把uploadId、文件Hash、结果等同步一份到业务系统的文件管理表里这样后续要做查询、统计、导出门槛都很低。第三是断点续传和任务列表结合。用户传了一半退出系统下次进来应该在哪里看到这个未完成任务体验好的产品会有一个草稿箱式的待传列表点击就重新上传。这需要前端把未完成任务持久化到localStorage或者IndexedDB重新打开页面时读取并调用预检接口恢复。这个功能在移动展业场景下特别有用推销员在客户那里拍到一半影像资料回到办公室连上WiFi可以接着传。至于要不要上WebRTC点对点传输、要不要接对象存储的多段上传接口比如S3 Multipart Upload这些属于更进一步的话题取决于你的部署环境。但我始终认为先把分片、续传、校验、审计这套基础能力做扎实后面的优化才有资格谈。金融行业最忌讳的就是花架子一个能稳定跑通全链路、出了问题有日志可查、被人质疑安全能拿出证据的DEMO比一百个花里胡哨的界面都值钱。我自己的体会是做这类项目最怕的不是技术难点而是不知道要验证什么就闷头写代码。先把上面那七个问题列出来再对着设计做DEMO每一步都有验证的抓手后期生产环境的坑自然就少了大半。
