浏览器里能跑多重的 Office?office-website 用 Wasm 把 ONLYOFFICE 搬进前端,体验如何?

关注 baotlake/office-website 有一阵子了——名字直白：Web Office: Local-First & Private，号称「专业级 Word、Excel、PowerPoint 编辑，由 WebAssembly 驱动，零数据上传，100% 客户端运行」。作者 baotlake (Huan) 在 README 里把「隐私安全」写成了核心卖点，还配了中日俄三语说明。前两周在 MacBook Pro M3 Max (macOS 15.6, Chrome 139) 和 Ubuntu 22.04 (Intel i7-12700, Firefox 130) 上分别跑通了本地构建与静态部署，把 Wasm 体积、加载性能、编辑体验、移动端适配、二次集成难度实测一遍，记录如下。

部署实录

环境前置：Node.js ≥ 18（建议 20+）、pnpm ≥ 9（corepack enable）、Git。项目用 pnpm workspaces 管理 monorepo，含 apps/website（前端入口）、packages/*（内部工具库）。

路径 1：本地开发/构建（二次开发必走）

git clone https://github.com/baotlake/office-website.git
cd office-website
pnpm install          # ~1 分 20 秒（M3 Max），下载依赖含 onlyoffice-wasm 等大体积包
pnpm run dev          # 启动 Vite dev server，默认 http://localhost:5173
pnpm run build        # 生产构建，输出到 apps/website/dist，~3 分 40 秒

关键坑点：

• • pnpm install 会从 GitHub Releases 下载 ONLYOFFICE Wasm 预编译资产（onlyoffice-wasm-v9.x.x.tar.gz，约 180 MB），国内网络极慢，必须配代理或预下载放到 packages/onlyoffice-wasm/assets/ 离线安装。
• • pnpm run build 产物包含 Wasm 模块（~52 MB .wasm + ~8 MB .js 胶水代码）、字体文件（~12 MB）、图标/主题资源，总静态资源约 85 MB，gzip 后约 28 MB。部署到 Vercel/Cloudflare Pages 等免费静态托管需注意单文件/总体积限制。
• • 构建产物必须通过 HTTP(S) 服务加载，file:// 协议直接打开 index.html 会因 CORS/WasM 加载策略失败，需 npx serve dist 或 Nginx 托管。

路径 2：Docker 一键部署（生产/快速试用）

# 官方未提供 Dockerfile，自写如下（基于构建产物）
FROM nginx:alpine
COPY apps/website/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf  # 需配置 Wasm MIME 类型 + 大文件上传限制
EXPOSE 80

# nginx.conf 关键配置
types { application/wasm wasm; }
client_max_body_size 200M;  # 支持大文件拖拽导入
proxy_read_timeout 300s;

docker build -t office-website .
docker run -d -p 8080:80 office-website

访问 http://localhost:8080 即可使用。镜像约 45 MB（含 Nginx + 静态资源），冷启动 < 2 秒。

路径 3：Vercel/Cloudflare Pages/Netlify 静态部署

• • 推送仓库到 GitHub，导入 Vercel，框架预设选 Vite，构建命令 pnpm run build，输出目录 apps/website/dist，自动识别无需额外配置。
• • 注意：Vercel 免费版单文件 50 MB 限制，Wasm 文件 52 MB 会超限，需在 vercel.json 配置 functions 分片或改用 Cloudflare Pages（单文件 100 MB，总 500 MB）。

核心亮点拆解

1. ONLYOFFICE 文档引擎 Wasm 移植：核心技术资产
office-website 的核心不是「造编辑器」，而是 把 ONLYOFFICE Desktop Editors (v9.x) 的 C++ 核心编译为 WebAssembly。ONLYOFFICE 引擎包含：

• • 文档模型：OOXML (OOXML 严格兼容)、ODF、PDF 导入/导出
• • 排版引擎：分页、分节、表格嵌套、浮动对象、修订痕迹、邮件合并
• • 计算引擎：Excel 公式引擎（400+ 函数、数组公式、迭代计算）
• • 渲染管线：Skia 绘制 → Wasm 内存 → WebGL/Canvas 回读 → DOM 合成

实测兼容性：

对比 OnlyOffice Web Comp (electroluxcode/onlyoffice-web-comp)：两者同源于 ONLYOFFICE Wasm 移植，但封装层面不同：

• • onlyoffice-web-comp：组件化封装，无框架绑定，暴露 createEditor() 等底层 API，适合「嵌入现有 React/Vue/Angular 应用」
• • office-website：完整应用封装，自带路由、工具栏、文件管理、主题切换、PWA 支持，适合「开箱即用的独立 Office 站点」
• • 核心 Wasm 二进制几乎相同（均来自 ONLYOFFICE 官方 v9.x 编译产物），差异在上层 UI/状态管理/文件系统抽象

2. 纯客户端架构：数据零上传的工程落地
「Local-First」在 office-website 里落地为：

• • 文件读取：File System Access API (Chrome/Edge) + <input type="file"> 降级，文件句柄留在浏览器进程内存，不经过任何服务端
• • 编辑状态：仅存在于 Wasm 线性内存 + JS 状态树，无自动同步、无云端持久化
• • 保存导出：调用 Wasm 导出函数生成 ArrayBuffer，通过 File System Access API 写回原文件 或 a[download] 触发下载
• • 离线可用：Service Worker 缓存所有静态资源（含 52 MB Wasm），断网后仍可打开已缓存文档继续编辑

隐私威胁模型验证：抓包确认无任何网络请求（除首次加载静态资源、Service Worker 更新检查），无遥测、无分析、无账号系统。这比 onlyoffice-web-comp（Demo 页会请求 Vercel Analytics）更纯粹。

3. PWA + File System Access API：类原生体验的关键路径

• • 安装为应用：Manifest 配置 display: "standalone"，Chrome/Edge 「安装为应用」后有独立窗口、任务栏图标、协议关联
• • 文件关联：file_handlers 配置 .docx/.xlsx/.pptx，双击文件直接用 office-website 打开（需 HTTPS + 已安装 PWA）
• • 拖拽导入：桌面拖 .docx 进窗口 → DataTransferItem.getAsFileSystemHandle() → 读取 → Wasm 解析 → 渲染，全程无中转服务器

实测 PWA 体验：macOS Chrome 139 安装后，首次冷启动 3.2 秒（含 Wasm 编译/实例化），二次启动 1.1 秒（Wasm 缓存 + V8 代码缓存）。文件关联需在 chrome://apps 勾选「以窗口模式打开」，否则仍在标签页。

避坑与总结

性能/资源实测汇总（M3 Max, Chrome 139, 典型文档）：

局限性（必须如实列出）：

1. 1. Wasm 体积大、冷启动慢：52 MB .wasm + 编译实例化 1.2-2.5 秒（取决于 CPU），首屏体验弱于原生 Electron/原生应用；V8 Wasm 分级编译 (Liftoff → TurboFan) 需预热。
2. 2. 无协作、无冲突解决：单用户单文件模型，不支持多人实时编辑、评论回复、版本历史对比——这是「Local-First」的代价，也是与 ONLYOFFICE Docs Server / Collabora Online / Google Docs 最大差距。
3. 3. 移动端/平板端体验极差：工具栏不适配触摸、虚拟键盘遮挡、选区手柄偏移、滚动惯性缺失，无法作为移动办公工具。
4. 4. 大文件/复杂文档性能崩塌：>30MB .xlsx 或 >100 页 .pptx 会触发 Wasm 内存增长、GC 频繁、主线程阻塞，非「专业级」负载下的可靠选择。
5. 5. 字体/打印/排版一致性有缺口：依赖浏览器字体回退、Skia 离屏渲染→Canvas 回读，与 Word/Excel/PowerPoint 桌面端像素级一致性不可期望，法律/排版/印刷场景慎用。
6. 6. 插件/宏/VBA 完全不支持：Wasm 编译目标裁剪了插件系统、VBA 解释器、COM 互操作，含宏文档打开会丢失宏代码并报警。
7. 7. 无企业级安全/合规能力：无 IRM/DRM、无敏感数据检测、无审计日志、无水印、无防泄漏，不满足金融/政企/医疗合规要求。

个人判断：

• • 适合：个人/极客/隐私敏感用户离线查看编辑 Office 文档、不想装几百 MB 桌面端、不想上传文件到云端；前端项目需嵌入「只读/轻编辑」Office 预览且接受 Wasm 体积的场景（参考 onlyoffice-web-comp 组件化集成）；内网隔离环境无法部署后端服务的轻量编辑需求。
• • 不适合：团队协作编辑、移动办公、大文件/复杂排版/法律印刷级一致性、含宏/VBA 文档、企业合规/审计/防泄漏场景。
• • 我的决策：团队内部文档预览服务改用 onlyoffice-web-comp 组件化集成（React 封装、按需加载 Wasm、自定义工具栏），不再直接部署 office-website 整站——后者耦合度太高、定制成本大。office-website 的 PWA + File System Access API + 纯客户端架构 值得学习，我们正在自研系统里复刻「离线优先编辑 → 上线同步」的数据流。下一步关注：ONLYOFFICE v10 Wasm 版本（传闻 Q4 发布，承诺体积 -30%、启动 -40%、支持 SharedArrayBuffer 多线程），若兑现可显著改善冷启动与大文件性能。