WASM预编译无法实现百万行Excel全量计算的真正“即时”，本质受限于内存、解析开销与浏览器执行模型；实际通过预编译+增量计算+按需加载将感知延迟压至100ms内。
WASM 预编译无法让 Web 端真正“即时”处理百万行 Excel 的全量计算——这不是工具链的问题，而是内存、解析开销与浏览器执行模型的根本限制。所谓“即时”，实际是通过预编译 + 增量计算 + 按需加载的组合策略，把用户感知延迟压到 100ms 内。
为什么 xlsx 解析本身就会卡住主线程
原生 JS 解析一个 100 万行 × 10 列的 .xlsx 文件，即使跳过样式和公式，仅读取原始单元格值，也会触发数百万次对象创建和字符串解码（Base64 → Uint8Array → string）。Chrome 对单次 JS 执行超过 50ms 就会标记为“长任务”，UI 直接卡顿。
- 避免用
SheetJS的XLSX.read(data, {type: 'array'})一次性加载整表：它默认构建完整Workbook对象树，内存占用常超 500MB - 改用流式解析入口：
XLSX.stream.to_json（需搭配readable-streampolyfill）或直接对接 WASM 解析器（如wasm-xlsx的parse_sheet_stream） - 关键约束：Excel 的
.xlsx是 ZIP 容器，必须先解压xl/worksheets/sheet1.xml或xl/sharedStrings.xml，这部分 ZIP 解压在 WASM 中仍需调用 JS 的DecompressionStream（Chrome 110+）或pako，不能完全绕过 JS
wasm-xlsx 的预编译边界在哪
wasm-xlsx（或类似 Rust 编译的 calamine-wasm）能把 XML 解析、数字格式转换、基础公式 AST 构建等 CPU 密集操作移入 WASM 线程，但它的预编译产物不包含 Excel 结构语义——比如“哪些单元格是公式引用源”“哪些区域被条件格式锁定”，这些仍需运行时分析。
- 预编译只固化解析逻辑，不固化数据；每次打开新文件，WASM 模块仍要重新扫描
sharedStrings表、重建索引映射表（str_table）、重算所有依赖图 - 公式计算不能全量预编译：像
SUMIFS这类带动态区域的函数，其求值范围必须在用户修改某列后实时重推，WASM 只能提供eval_formula函数，而非预存结果 - 实测：100 万行纯数值表，
wasm-xlsx解析耗时约 320ms（WebAssembly.compile 后首次 instantiate 耗时另计），比纯 JS 快 3.2×，但离“即时”仍有差距
真正降低感知延迟的三个落地动作
用户说的“即时”，本质是“改一个单元格，光标不抖、滚动不卡、公式结果秒出”。这靠的不是更快的全量计算，而是隔离、裁剪与缓存。
- 用
Worker+SharedArrayBuffer把 WASM 实例和主内存隔离：避免 GC 波及 UI 线程，尤其当表格对象频繁增删时 - 对公式引擎做“懒依赖注册”：只在用户聚焦某单元格时，才用 WASM 的
get_formula_deps(cell_addr)提取它直接引用的单元格地址，而非启动全表依赖分析 - 启用列级缓存：对非公式列（如 ID、时间戳），用
TypedArray直接映射 WASM 内存页；修改时仅 memcpy 对应 offset，不触发 JS 对象序列化 - 禁止自动重算全表：监听
input事件后，只调用wasm_module.recalc_cells(["A1", "B5", "C1000000"])，传入变更单元格列表，由 WASM 内部按拓扑序增量更新
最易被忽略的是 shared string 表的复用——如果多个 Sheet 共用同一份 sharedStrings.xml，但 WASM 模块每次解析都重建字符串池，内存会指数增长。必须在 Worker 初始化时，用 postMessage({type: 'init_str_pool', data: str_array}) 主动注入并复用池子。
