office-open-xml-viewer：用 Rust + WASM 在浏览器里渲染 DOCX、XLSX、PPTX

很多团队一碰到 Office 文档预览，第一反应还是把文件丢给后端转 PDF，或者直接嵌一个第三方在线预览服务。

这样做当然省事，但代价也很明显：

预览链路依赖服务端转换；
大文件和并发时，成本容易抬高；
私有文档要经过外部服务，合规压力会变大；
前端几乎拿不到可编排的渲染能力，只能嵌一个黑盒。

今天想记下的 yukiyokotani/office-open-xml-viewer，做的是另一条路：直接在浏览器里解析和渲染 DOCX、XLSX、PPTX。它把解析器写在 Rust 里，再编译成 WebAssembly，前端用 Canvas 2D 做渲染，而且不只给一个现成 viewer，还把底层文档对象暴露出来，让你自己组装文档浏览 UI。

按 GitHub 仓库页面和最新 release 页面在 2026-06-23 的公开信息，这个仓库当前约有 546 stars、16 forks，主要语言是 TypeScript，仓库创建于 2026-04-18，最近公开更新时间为 2026-06-23。项目采用 MIT 许可证，最新 release 是 v0.66.0，发布时间同样是 2026-06-23。

项目概览

属性	详情
仓库	yukiyokotani/office-open-xml-viewer
定位	在浏览器中渲染 DOCX / XLSX / PPTX 的前端文档查看器
Stars	546
Forks	16
主要语言	TypeScript
创建时间	2026-04-18
最近更新时间	2026-06-23
License	MIT
最新版本	v0.66.0
版本日期	2026-06-23
在线演示	ooxml.silurus.dev

它解决的不是“文档能不能打开”，而是“前端能不能真正接管文档渲染”

这个项目最有意思的点，是它不是那种“给你一个 iframe 或截图结果”的预览器。

README 里给出的主轴很明确：

解析器由 Rust + WebAssembly 提供；
渲染器使用 Canvas 2D API；
三种格式都暴露了 headless engine；
调用方可以把结果画进自己的 canvas，而不是被迫使用固定 UI。

这意味着它更像一套 可编排的前端文档渲染基础件。你可以做的不只是“显示一份文件”，还包括：

自己设计滚动式文档阅读器；
给 PPT 做缩略图导航；
给 XLSX 做 master-detail 视图；
把文档页面接进已有的前端工作台，而不是另开一个预览页。

如果你做的是知识库、审批系统、内部文档平台、在线网盘、合同查看器或教育类内容系统，这种能力比“能打开 Office 文件”本身更重要。

三种格式一起做，而且不是停留在最简 demo 级别

从 README 的能力描述看，@silurus/ooxml 不是只挑一个格式做样板。

它同时覆盖：

DocxViewer
XlsxViewer
PptxViewer

并且分别提供：

面向直接使用的 viewer；
面向二次开发的 DocxDocument、XlsxWorkbook、PptxPresentation。

这种分层很关键。很多文档预览项目的问题就在于，上层组件能跑，下层能力不可复用。一旦你想定制交互，整个方案就要重来。

office-open-xml-viewer 的做法更像是：

上层先给你可用 viewer；
底层再给你文档对象和渲染入口；
你可以保留它的解析能力，但换掉默认界面。

这让它既适合快速接入，也适合后期深度定制。

真正值得注意的地方，是它把浏览器端渲染做成了“主线程可让渡”的模式

README 里一个很实用的设计，是 off-main-thread rendering。

默认情况下，项目会把解析放到 worker 里，渲染仍放在主线程；如果你显式传 mode: 'worker'，则解析和渲染都可以在 Web Worker 内完成，主线程只负责接收 ImageBitmap 再显示出来。

这件事对真实产品非常重要。因为 Office 文件预览最容易踩的坑，不是“能否显示”，而是：

大文档切页时主线程卡顿；
幻灯片复杂时拖慢整个页面交互；
表格和图形较多时滚动不流畅。

它这里给出的不是一句“我们很快”，而是一套更工程化的处理方式：

用 Worker 和 OffscreenCanvas 把重活移走；
主线程只保留输入和滚动响应；
需要时用 ImageBitmap 作为绘制结果。

如果你做的是浏览器端重预览场景，这比单纯拼 benchmark 数字更有说服力。

它不只是看文字，还在认真补 Office 文档里最麻烦的部分

看最新的 v0.66.0 release 说明，会发现作者不是只在修一些表面问题。

这版重点包括：

DOCX 连续分节、多栏排版的布局修正；
跨 section 的 header / footer 继承；
超长 token 在窄列中的换行处理；
连续段落边框与段间距的更接近 Word 的行为；
新增 EMF 图形栅格化支持。

这类改动很能说明项目阶段。因为 Office 文档渲染真正难的，往往不是第一屏能不能出字，而是：

复杂 section 和分页规则；
多栏布局；
图形、公式、嵌入对象；
与 Word / PowerPoint / Excel 接近的视觉结果。

能持续在这些角落里补行为，说明这个项目已经开始从“能演示”走向“能处理真实文件”。

公式、字体和 bundle 体积这些现实问题，它也考虑得比较诚实

README 里还有几个我觉得很加分的细节。

第一，它没有把所有能力一次性硬塞进默认包，而是明确告诉你：

包是 ESM-only；
可以按 docx、xlsx、pptx 子路径分别导入；
数学公式引擎是单独入口；
OMML 公式渲染依赖 MathJax 和 STIX Two Math，但只有在你显式引入时才会进入 bundle。

这比很多“功能看起来很全，但默认包巨大无比”的方案靠谱得多。因为前端实际落地时，你经常只需要其中一种格式，或者只想先把预览链路跑通。

第二，它对 worker mode 的限制说得也很直接。比如 README 明说：

worker mode 更适合保持界面响应；
但单次渲染未必比主线程更快；
OMML 公式在 worker mode 下会被跳过。

这种表述很工程，不神化，也更容易拿来做真实取舍。

安全和隐私边界写得比较清楚

对文档查看器来说，安全边界比 demo 漂亮更重要。

README 里给出的几个默认策略值得记一下：

文档内容只画到 HTMLCanvasElement，不把源文件中的脚本、链接或表单注入 DOM；
ZIP 解压对单个 entry 默认设了上限，用来防御 zip bomb；
默认不做网络请求，也不带 telemetry；
只有在显式开启 useGoogleFonts 时，才会去请求 Google Fonts；
XML 解析使用的库默认不解析外部实体。

这些设计不代表你可以在任何场景里“完全无脑信任上传文档”，但它至少说明项目在用浏览器原生渲染 Office 文件时，没有忽略典型风险面。

它的边界同样明确：这不是 Office 在线编辑器，也不是 100% 替代桌面 Office

我反而觉得这点挺重要。office-open-xml-viewer 的价值，不在于把自己包装成“浏览器里完整复制 Microsoft Office”，而是专注在 查看、渲染、嵌入和前端集成 这条线上。

所以它更适合的场景是：

文档预览；
前端文档阅读器；
内部平台的 Office 文件展示；
幻灯片和表格内容的嵌入式浏览；
二次开发自己的 viewer 界面。

如果你的目标是：

强编辑能力；
完整批注协作；
与桌面 Office 完全一致的排版和行为；
覆盖所有边缘格式特性；

那它显然不是直接替代品。

但如果你的需求是“把 Office 文档可靠地带进浏览器前端，而且希望自己掌控交互和界面”，这个项目就非常对路。

为什么我觉得它值得关注

我觉得这个项目值得跟，不只是因为它会预览 DOCX/XLSX/PPTX，而是因为它踩在一个很实际的空档上：

很多产品都需要浏览器端 Office 预览，但真正可编排、可前端集成、能自己掌控渲染链路的方案并不多。

office-open-xml-viewer 的路线很清楚：

用 Rust + WASM 做解析；
用 Canvas 2D 做浏览器渲染；
提供 viewer，也提供 headless engine；
允许主线程和 worker 模式之间按场景切换；
在复杂布局、公式、图形和安全边界上持续往前补。

这让它看起来不像一次性的玩具仓库，更像一个正在长成的前端文档渲染基础设施项目。

小结

yukiyokotani/office-open-xml-viewer 最有意思的地方，不只是“能在浏览器里看 Office 文件”，而是它把 解析、布局、Canvas 渲染、worker 化和二次开发接口 都整理成了一套前端可接入的能力。

如果你正在做文档平台、知识库、审批系统、网盘、教育内容系统，或者任何需要把 DOCX、XLSX、PPTX 带进浏览器前端的产品，这个项目很值得继续跟一段时间。