HTML5上传性能优化关键在于减少干扰：合理控制分片粒度（如4MB起始）、避免readAsDataURL预览、用URL.createObjectURL替代Base64、采用fetch直传Blob、服务端需支持流式处理。
HTML5 上传性能优化的核心不在“加功能”，而在“减干扰”——控制分片粒度、避免重复编码、跳过不必要的预处理，上传速度往往能提升 2–5 倍。
用 File.slice() 分片上传，别依赖第三方库自动切片
很多上传库默认按 1MB 切片，但对大文件（如 >500MB 视频）反而拖慢整体进度：小片导致 HTTP 请求头开销占比升高，且并发数受限时容易阻塞。手动控制更稳妥：
-
slice()比ArrayBuffer.slice()更轻量，直接返回Blob，不触发内存拷贝 - 建议起始分片大小设为
4 * 1024 * 1024（4MB），再根据网络类型动态调整（如 3G 环境降为 2MB） - 避免在主线程反复调用
file.slice(start, end)生成大量临时Blob；可复用同一File实例，仅变更参数
上传前跳过无意义的 readAsDataURL() 预览
用户选完文件就立刻调 readAsDataURL()，看似友好，实则把几 MB 到几百 MB 的二进制转成 Base64 字符串，吃光主线程、卡死 UI，还浪费内存。真正需要预览时才读：
- 图片缩略图用
URL.createObjectURL(file)直接创建本地 URL，零拷贝、毫秒级响应 - 如需压缩，用
createImageBitmap()+canvas.toBlob()，绕过 Base64 中间态 - 视频/音频封面提取也应延后到上传启动前，且限制分辨率（如不超过
640x360）
用 XMLHttpRequest.upload.onprogress 替代轮询式状态检查
有些实现用 setInterval 定期查 xhr.readyState 或服务端回调接口，不仅不准，还增加无效请求。原生上传事件更可靠：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
-
upload.onprogress提供实时loaded和total，精度达字节级 - 注意：
loaded可能大于total（服务端未返回Content-Length时），需加判断：if (e.lengthComputable) { /* 正常计算 */ } else { /* 显示「上传中…」不定进度 */ } - 不要在
onprogress里频繁更新 DOM；用requestIdleCallback()节流渲染
禁用 FormData.append() 自动包装，改用 fetch() + body: blob
传统 FormData 会把文件包装成 multipart/form-data，引入额外边界字符串和编码开销，服务端解析也更重。现代 API 支持直传原始二进制：
- 若服务端接受
application/octet-stream，直接传file.slice(...)返回的Blob：fetch('/upload', { method: 'POST', body: chunk }) - 需携带元信息（如文件名、分片序号）时，改用自定义 header：
headers.set('X-File-Name', file.name)，而非塞进FormData - 注意：Safari 16.4+ 才完整支持
fetch()上传大文件的进度事件，旧版本仍需回退到XMLHttpRequest
最常被忽略的一点：上传性能瓶颈往往不在前端代码，而在服务端是否开启 Transfer-Encoding: chunked 或是否对 multipart 解析做了流式处理。前端再快，卡在服务端 buffer 里也没用。
