一个做过 Office 产品的人告诉你：为什么看到“纯前端高保真”我第一反应是怀疑

​前几天，我写过一篇《为什么 BaseMetas FileView 没有坚持“纯前端预览”路线》的文章。文章发出后，收到不少朋友私信交流，也有不少同行分享了自己正在关注或者评估的纯前端预览方案。

恰好最近几个月，市场上陆续出现了几款新的纯前端文档预览产品。

宣传语几乎如出一辙：

• 无需服务端转换
• 浏览器直接打开 Word
• 高保真还原
• 所见即所得
• 轻量化集成
• 前端原生渲染

很多开发者看完之后都很兴奋。

因为这似乎意味着：

文档预览终于摆脱了转换服务、转换集群和复杂部署。

甚至有人开始认为：

转 PDF 的时代要结束了。

作为一个这些年一直在做文档预览、Office 处理、在线文档相关产品的人，我想说：

大家可能高兴得有点早。

大家讨论的是“前端技术”，而企业需要的是“文档结果”

最近关于纯前端预览的讨论非常热闹。

但很多讨论其实跑偏了。

大家讨论的是：

• WebAssembly
• Canvas
• SVG
• 浏览器渲染
• 前端架构

而企业真正关心的是：

打开后的文档是不是和 Word 里面看到的一样。

用户不会关心你是不是用了 WASM。

也不会关心是不是零转换。

用户只会问：

为什么这里跑版了？

为什么这里分页变了？

为什么这里图片位置不对？

为什么目录页码错了？

对于企业来说：

结果比技术路线重要得多。

大多数人低估了 Word 的复杂度

很多没有做过 Office 产品的人容易产生一种错觉：

DOCX 不就是 XML 吗？

实际上：

解析 DOCX 很简单。

显示内容也不难。

真正困难的是：

如何按照 Word 的规则把它排出来。

这是两个完全不同的问题。

一个真实的企业 Word 文档里面可能同时存在：

• 页眉页脚
• 分节符
• 自动目录
• 自动编号
• 浮动图片
• 文本框
• Shape 图形
• 批注修订
• 页码
• 脚注尾注
• 中文排版规则
• 表格嵌套
• 表格跨页
• 多栏布局
• 不同页面方向

这些元素并不是独立存在的。

而是会互相影响。

一个图片位置变化。

可能导致分页变化。

分页变化又可能导致目录变化。

目录变化又可能导致页码变化。

最终整个文档重新排版。

这也是为什么：

Word 本质上是一个排版系统，而不仅仅是一个文件格式。

Word 最难的从来不是解析，而是排版

很多产品宣传：

支持 DOCX 在线预览。

实际上这句话价值有限。

因为解析 DOCX 和实现 Word 完全不是一回事。

如果不转换成 PDF。

而是直接展示源文件。

那么实际上需要自己实现：

• 字体度量
• 行布局
• 段落布局
• 页面布局
• 分页算法
• 中文排版规则
• 浮动对象布局
• 表格布局
• 图形布局

简单来说：

你实际上是在重新实现一个 Word。

这也是为什么做过 Office 产品的人看到“纯前端高保真 Word 预览”时，第一反应通常不是兴奋，而是怀疑。

因为他们知道这里面的技术门槛有多高。

为什么市场上真正做到高保真排版的厂商屈指可数

这些年文档行业发展下来。真正能够做到复杂 Office 文档高保真排版的厂商其实并不多。

国内大家熟悉的无非就是：

• Microsoft
• 金山办公
• 永中软件

本质原因并不是别人不想做。

而是：

排版引擎本身就是 Office 软件最核心、最昂贵的技术资产之一。

这里面包含几十年的兼容性积累。

数百万真实文档的验证。

无数企业客户问题的修复。

无数边界场景的打磨。

这不是一个浏览器组件能够快速替代的。

更不是几个月开发周期就能补齐的。

Demo 能通过，不代表企业文档能通过

最近为了验证一些产品宣传中的：

• 高保真
• 精准还原
• 完美兼容

我专门找了一批 Office 行业常见测试文档。

这些文档不是刻意制造的极端案例。

而是 Office 产品团队日常测试兼容性时经常使用的文件。

结果非常有意思。

演示文件基本都没问题。

真实企业文档开始大面积翻车。

案例一：空格宽度计算和文本框显示

案例二：项目编号、页码错误

案例三：分页位置变化

留给大家自己测试

案例四：表格跨页异常

留给大家自己测试

案例x：XXXXX

留给大家自己测试

从技术角度来说：

这叫排版兼容性问题。

从普通用户角度来说：

只有一句话：

怎么和 Word 打开不一样？

而这恰恰是企业客户最无法接受的问题。

为什么 PDF 至今仍然是主流方案

很多人觉得：

转换 PDF 是历史包袱。

实际上恰恰相反。

PDF 能够成为今天企业预览领域的主流方案，并不是因为技术落后。

而是因为它解决了最核心的问题：

排版一致性。

PDF 本身就是最终排版结果。

它已经完成了：

• 字体计算
• 行布局计算
• 分页计算
• 图形布局计算

浏览器需要做的事情只有一个：

展示。

因此对于绝大多数企业场景来说：

DOC/DOCX
        ↓
    转 PDF
        ↓
 浏览器预览

至今仍然是最可靠、最稳定、风险最低的方案。

这也是为什么 OA、BPM、合同管理、档案管理、知识库、电子签章等系统大量采用这种模式。

不是因为他们不会做纯前端。

而是因为他们更关注结果。

纯前端预览会成功吗？

我的答案是：

一定会。

但有一个前提。

这个前提不是支持多少格式。

也不是渲染速度有多快。

而是：

谁先解决 Word 的高保真排版布局问题。

因为企业场景中最重要、最频繁、最有价值的文档，始终是 Office 文档。

尤其是 Word。

如果有一天某个产品真的能够在浏览器里做到：

• 与 Word 一致的分页
• 与 Word 一致的布局
• 与 Word 一致的兼容性

那么纯前端预览一定会迎来真正爆发。

但在此之前。

所有绕不开排版引擎的问题，最终都会变成兼容性问题。

写在最后

我并不反对纯前端预览。

恰恰相反。

我认为这是未来方向。

但作为一个长期做文档产品的人，我更倾向于把现实说清楚。

当前阶段很多产品解决的是：

如何把内容显示出来。

而企业真正需要解决的是：

如何把文档正确显示出来。

这两者看起来只差几个字。

背后却隔着一个完整 Office 排版引擎的距离。

在这个问题真正被解决之前。

对于绝大多数企业级场景而言：

Word 转 PDF 预览，依然是目前最成熟、最稳定、最可落地的方案。

至于那些宣传“完全兼容 Word”“高保真纯前端预览”“直接替代 Office 排版引擎”的产品。

建议不要先看宣传页。

先拿几份真正的企业文档测一测。

因为文档行业有一个非常现实的规律：

Demo 展示的是能力上限。

企业文档验证的是能力下限。

而决定产品能否进入生产环境的，恰恰是后者。

相关资料

商业版

BaseMetas 预览产品商业版介绍

BaseMetas 预览体验（企业网盘入口）

社区版

• BaseMetas Fileview 产品介绍：https://fileview.basemetas.cn/docs/product/summary
• BaseMetas Fileview 在线体验：https://file.basemetas.cn
• BaseMetas Fileview GitHub：https://github.com/basemetas/fileview

​