webassembly与indexeddb应分工协作：wasm专注cpu密集型计算，indexeddb仅负责异步数据持久化；须避免在idb事务中执行复杂wasm逻辑，推荐worker+offscreencanvas+wasm+idb组合，并分块处理大数据以保障性能与稳定性。
WebAssembly（WASM）与IndexedDB结合，适合在浏览器中处理中等规模数据的离线计算+持久化场景，但需谨慎设计，否则易陷入“看似高性能、实则阻塞或低效”的陷阱。
WASM负责计算密集型任务，IndexedDB只做数据搬运
WASM擅长执行数学运算、图像处理、加密解密、物理模拟等CPU密集型逻辑；IndexedDB本质是异步键值存储，不参与计算。二者分工应明确：WASM线程（或主线程）完成计算后，将结果交由IndexedDB写入；读取时也仅作数据加载，计算仍交由WASM。避免在IndexedDB事务回调里调用复杂WASM函数，否则会延长事务时间，触发QuotaExceededError或写入失败。
- 推荐用
OffscreenCanvas+ WASM做图像处理，再把结果数组存入IndexedDB - 不推荐在
indexedDB.open().onsuccess中直接调用WASM模块的processLargeArray() - 大数组建议分块传输：WASM输出Uint8Array → 转为Blob → 存入IndexedDB（支持二进制原生存储）
规避主线程阻塞，优先使用Worker + WASM + IndexedDB组合
WASM虽运行在沙箱中，但默认同步执行；若计算耗时超50ms，仍会导致页面卡顿。IndexedDB的put/get虽异步，但其回调仍在主线程执行。因此，高可靠方案是：将WASM模块加载并运行于Web Worker中，Worker内通过postMessage与主线程交换IndexedDB操作指令。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- Worker中初始化WASM（
WebAssembly.instantiateStreaming），预编译缓存wasm module - 主线程通过
indexedDB.open建立连接后，把db对象的transaction权限不直接传给Worker（不可行），而是封装成消息协议，如{type:'save', key:'result_123', data:...} - 使用
idb库（如idb v7+）可简化Promise化封装，配合Worker更易管理生命周期
IndexedDB容量与WASM内存模型需协同规划
IndexedDB单条记录最大约2GB（实际受浏览器和设备限制，通常500MB内更稳妥）；WASM线性内存默认64KB起，可动态增长，但grow操作有开销。若WASM需处理百MB级中间数据，应避免全部驻留内存——可采用“流式分段”策略：
- WASM模块设计为接受
startOffset和chunkSize参数，每次只处理一段数据 - 每段计算完立即通过
postMessage发送至主线程，由主线程批量写入IndexedDB（使用transaction.objectStore().add()多条合并） - 对超大结构化数据（如地理栅格、基因序列），考虑用IndexedDB的
binary类型+压缩（如WASM内集成zstd-wasm）再存储
性能验证不能只看“计算快”，要测端到端延迟与稳定性
真实高性能体现在：首次加载不卡顿、重复运行内存不泄漏、离线状态下可恢复计算进度、大数据量下IndexedDB写入不频繁失败。建议用Chrome DevTools的Performance面板录制完整流程，并重点关注：
- WASM模块加载耗时（尤其
instantiateStreaming是否启用HTTP/2 + 缓存头） - IndexedDB写入队列堆积情况（在Application → IndexedDB查看实时大小变化）
- Memory面板中JS heap与WASM memory是否随计算次数线性增长（泄漏迹象）
- 在“Network → Offline”下测试整个流程是否仍可运行（验证离线能力）
不复杂但容易忽略：WASM与IndexedDB不是简单叠加就能高性能，关键在数据流节奏控制、线程边界划分和错误降级策略（例如WASM编译失败时回退JS实现，IndexedDB满额时自动清理旧快照）。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
