纯前端方案是怎么工作的
纯前端预览的思路很直接：把 Office 文件下载到浏览器，用 JavaScript 解析 OOXML（docx、xlsx、pptx 本质上是 ZIP 包 + XML），再把 XML 里的段落、表格、图片按自己的规则画到页面上。
它的优势也很明显——不需要服务端资源，文件不出浏览器。对于结构简单的文档，效果相当不错。
问题在于，Office 文件里记录的不只是「内容」，还有一整套排版规则。前端方案要做的是重新实现一遍排版引擎，而这正是难的地方。
五道绕不开的坎
- 分页与分栏：分页位置取决于字体度量、行高、段前段后间距与孤行控制，前端很难完全复现，常见结果是页码错位、表格被截断。
- 字体与中文排版：原文件用的字体在访问者电脑上未必存在，字体替换会连带改变行宽与分页位置，中文文档尤其明显。
- Excel 表格布局：合并单元格、冻结窗格、条件格式、公式结果与图表，任何一项缺失都会让财务与报表场景无法使用。
- PPT 动画与触发器：动画时间轴、触发器与切换效果无法用静态解析还原，课件与会展类文件会直接失去价值。
- 复杂公式与图表：OMML 公式、嵌入图表、SmartArt 与形状组合，在前端基本只能降级为图片或直接丢失。
同一份文档的对照
| 文档类型 | 纯前端常见结果 | 服务端渲染结果 |
|---|---|---|
| 公文 / 合同 | 页码与签章位置偏移 | 版式与签章位置一致 |
| 财务 Excel | 公式结果为空、图表缺失 | 公式计算、图表重绘 |
| 培训 PPT | 动画全部丢失 | 动画按时间轴播放 |
| 工程图纸 | 不支持或严重失真 | 矢量渲染、无极缩放 |
什么时候纯前端够用
不必全盘否定纯前端方案。以下场景它确实是性价比最高的选择：
- 附件以 PDF、图片、Markdown、纯文本为主，几乎没有 Office 重排版文件；
- 内部工具、临时查看、低代码平台的附件预览；
- 对文件不出浏览器有极高要求，且能接受排版降级；
- 原型阶段验证交互流程，还不涉及正式交付。
混合架构的思路
实际项目里更常见的做法是混合：轻量格式（PDF、图片、文本）走浏览器本地渲染，重排版格式（Word、Excel、PPT、OFD、CAD）交给服务端。这样既保留了轻量场景的低成本，又能保证正式文件的还原度。
USDOC 的取法是把两类能力统一到一个预览地址上：调用方只需要拼接文件地址，由服务端判断格式并选择合适的渲染链路，业务系统不必为不同格式写两套逻辑。
落地建议
验收文档预览时，不要只看「能不能打开」，而要拿业务里最复杂的那份文件去试：跨页表格、带批注的合同、有动画的课件、带公式的报表。
如果这份最复杂的文件能还原到位，其余的通常不会出问题；如果它打开了但版式是歪的，那说明路线选错了，早换比晚换便宜。
