移动端H5选择超大视频卡死主因是主线程阻塞于文件读取、元信息解析和预览生成；应禁用自动预览、改用Web Worker轻量解析moov box、分片上传并流式校验，辅以超时保护与兜底提示。

移动端 H5 中选择超大视频（如 4K、1GB+）时，页面卡死通常不是因为“播放”，而是发生在 文件读取、元信息解析、预览生成 这一阶段。浏览器在调用 FileReader.readAsArrayBuffer() 或 URL.createObjectURL(file) 后，若直接尝试解析视频头、抽帧、计算时长/分辨率，极易触发主线程长时间阻塞，尤其在中低端安卓机上表现明显。

避免主线程解析视频元数据

用户点击「选择视频」后，不要立刻调用 file.duration、file.width 等属性（这些在未解码前不可靠），更不要用 ffmpeg.wasm 或 mediainfo.js 在主线程解析完整视频。

• 仅通过 file.size 和 file.type 做初步校验（例如限制 ≤500MB、仅允许 video/mp4 或 video/quicktime）
• 如需获取时长/分辨率，改用 Web Worker + 轻量解析库（如 mp4box.js 的 probe 模式），只读取 moov box，不加载媒体数据
• 对超大文件，可跳过元信息展示，直接进入上传流程，后台服务返回真实时长后再更新 UI

禁用自动预览与缩略图生成

很多 H5 页面会在选中后立即用 createObjectURL + 标签加载并调用 captureStream() 或 drawImage() 抽帧——这是卡死主因。

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

• 取消所有「选中即预览」逻辑；如必须展示封面，优先使用手机系统自带的缩略图（file.webkitGetAsEntry + getFile 获取 thumbnail，但兼容性有限）
• 若需自动生成封面，延后到上传完成后的服务端处理，或使用轻量 WebAssembly 库（如 @ffmpeg/ffmpeg 的 exec 模式）在 Worker 中执行，且限制只抽第 1 帧、输出 200×150 JPEG
• 避免在 change 回调里创建 video 元素并调用 load() —— 它会触发完整解析流程

分片上传 + 流式校验

真正让页面“不卡”的关键是：把耗时操作从“前端一次性处理”改为“后端分担 + 前端流式响应”。

• 使用分片上传（如 TUS 协议或自定义分片），每片 ≤5MB，上传同时校验 MD5（前端 Web Crypto API 计算分片哈希，不读全文件）
• 上传过程中显示进度条，禁用所有交互按钮，避免用户重复触发
• 首片上传成功后，后端快速返回视频基础信息（时长、宽高、编码格式），前端再决定是否继续或提示转码
• 对确认超大的文件（>800MB），可直接提示“建议使用 App 上传”，避免前端硬扛

兜底与体验优化

即使做了以上处理，仍需应对极端情况：

• 为 添加 capture="environment" 属性，强制调起相机直录（规避相册大文件）
• 监听 input 元素的 abort 和 error 事件，及时清理 objectURL 防止内存泄漏
• 设置超时保护：若文件读取/解析超过 3 秒，中断并提示“视频过大，建议压缩后重试”
• 在 iOS 上注意 webkitdirectory 不可用，避免误用目录选择导致崩溃