createObjectURL无法导出TB级数据，因其要求全量Blob加载至内存，超出浏览器2–4GB限制，且无流式处理、分块写入或内存释放机制。
直接用 URL.createObjectURL 导出 TB 级原始数据在前端是不可行的——它不处理数据流，也不支持分块生成或释放内存，强行加载 TB 数据进内存会导致浏览器崩溃、卡死甚至被系统强制终止。
为什么 createObjectURL 无法胜任 TB 级导出
URL.createObjectURL 的作用是为 Blob 或 File 对象创建一个临时 URL 引用，但它本身不产生数据、不压缩、不分片、不流式写入。关键限制包括：
- 输入必须是完整构建好的
Blob，意味着整个 TB 数据需先加载到内存（或至少被 JS ArrayBuffer / TypedArray 持有）——现代浏览器单页内存上限通常在 2–4 GB，远低于 TB 量级； - 即使使用
new Blob([chunks], {type: '...'})，传入的chunks数组仍需全部存在于 JS 堆中，浏览器内部拼接时还会额外拷贝； - 调用后若未及时
URL.revokeObjectURL()，Blob 引用持续占用内存，加剧风险； - 无暂停、恢复、进度反馈、错误重试等流控能力，不适合超大文件场景。
真正可行的 TB 级前端导出方案
必须绕过“全量加载”，改用流式生成 + 分块传输 + 增量写入。核心思路是：不把数据全塞进 JS 内存，而是让浏览器从可流式读取的数据源（如 Fetch ReadableStream、Worker 中的生成器、或 IndexedDB 渐进读取）按需拉取并写入文件。
-
服务端配合流式接口：后端提供 HTTP 流式响应（
Content-Type: application/octet-stream+Transfer-Encoding: chunked），前端用fetch().then(res => res.body)获取ReadableStream，再通过WritableStream（需WritableStreamDefaultWriter）写入FileSystemFileHandle.createWritable()（仅 Chromium 支持）； -
利用 Streams API + File System Access API：用户选择保存位置后，获得
fileHandle，打开可写流，循环从数据源（如 Web Worker 中分批生成的 ArrayBuffer）写入，全程无大内存驻留； -
降级方案：分卷下载 + 客户端合并：服务端将 TB 数据切为多个 GB 级
.part001、.part002文件，前端并发下载，再用Streams API或FileReader顺序读取并Blob合并（注意：合并操作仍需总和内存，仅适合最终合成小文件或仅做校验）； -
Web Worker + 动态 Blob 构造（仅限百 MB 级）：若数据可分段生成（如日志拼接、加密结果流），Worker 每次产出一个
Uint8Array，主线程用new Blob([chunk])创建子 Blob 并createObjectURL追加到<a download>下载，但此法仍受限于单次 chunk 大小与总累积内存，不适用于 TB。
最小可行流式导出示例（基于 File System Access API）
以下代码假设你已有 Web Worker 逐块生成数据（例如每块 8MB）：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
立即学习“前端免费学习笔记（深入）”；
// 主线程
async function startExport() {
const handle = await window.showSaveFilePicker({
suggestedName: 'data.bin',
types: [{ description: 'Binary Data', accept: { 'application/octet-stream': ['.bin'] } }]
});
const writable = await handle.createWritable();
const worker = new Worker('generator.js');
worker.postMessage({ cmd: 'start' });
worker.onmessage = async ({ data }) => {
if (data.chunk instanceof ArrayBuffer) {
await writable.write(new Uint8Array(data.chunk));
} else if (data.done) {
await writable.close();
alert('导出完成');
}
};
}
⚠️ 注意：该 API 目前仅 Chromium 系浏览器支持（Chrome/Edge ≥ 86），且需 HTTPS 或 localhost 环境；Safari 和 Firefox 尚未实现 showSaveFilePicker。
替代路径：不导出，而是就地处理 + 按需提取
对真正 TB 级原始数据，更合理的前端策略常是：
- 用
WebAssembly或WebGL在内存映射视图（SharedArrayBuffer+BigUint64Array）中做局部计算，只导出结果摘要（如哈希、统计值、采样帧）； - 借助
OPFS（Origin Private File System）存储中间块，避免反复下载，再按需组装轻量输出； - 引导用户使用桌面客户端（Tauri/Electron）或命令行工具（curl + dd），由原生进程处理流式 IO。
不复杂但容易忽略：TB 级数据的“前端导出”本质是个伪命题——浏览器不是文件服务器。务实做法是明确边界：前端负责调度、流控、交互与轻量转换；重 IO、大内存、持久化任务交由服务端或原生层完成。
