为什么我们仍然坚持做纯前端文档预览

这篇文章，原本只是想写一次最近更新。

写着写着，心里却慢慢有了一点别的感觉。因为这几年的很多画面，都会在整理文字的时候冒出来：有人深夜还在对一份 Word 的目录，有人反复打开同一页 PPT，只为了确认一个图形到底偏了几像素，也有人在客户真实文件里一点点找规律，直到某个一直不对的页面终于像了，群里才会有人很轻地说一句：这次差不多了。

嗯，这些话说出来，好像有一点矫情。

但对我们来说，Flyfish Office Preview 并不是一个突然冒出来的产品，也不是一个简单包装之后拿出来售卖的工具。它更像是我们这几个技术人，沿着一条不算热闹、甚至有些辛苦的路，一点一点走出来的结果。

我们坚持做纯前端文档预览，不是因为这条路轻松。

恰恰相反，是因为我们做得越久，越能感受到企业文件预览里那些被低估的痛点：部署不能太重，文件不能随便出内网，预览不能依赖一整套庞大的在线办公服务，系统接入不能为了一个预览功能改得面目全非。

所以，我们一直在想一件很朴素的事情：能不能让文件就在本地解析，让预览就在浏览器里完成，让客户拿到的是一套边界清楚、源码可用、安全可控、足够轻量的能力。

这件事不华丽，但很重要。

一切要从 2022 年那篇文章说起 🌱

最早的起点，大概要回到 2022 年。

那时候，我们在 CSDN 上写过一篇文章，叫《纯前端文档预览，有这一篇就够了》。现在回头看，那篇文章带着很明显的热情，也带着一点年轻时常有的笃定。我们当时只是觉得，前端项目里做文件预览这件事，应该有一条更轻、更直接的路径。

后来，我们做了 file-viewer。

那个阶段，我们更多是在做整合。我们把当时可以用的 Vue 组件能力组织起来，支持 Vue2，也支持 Vue3，又通过组合式 API 尽量统一维护。那段时间，确实收到了很多朋友的喜欢和支持。有人希望兼容更多格式，有人希望接入方式更顺手，有人希望样式更稳定，也有人带着真实业务文件来问我们：这个地方还能不能再像一点？

说实话，那段时间挺辛苦的，但也很开心。

因为每一个反馈背后，都不是抽象的“用户需求”，而是一个真实系统、一份真实文件、一段真实工作流。我们慢慢意识到，文档预览不是把文字显示出来就结束了。很多时候，企业用户真正关心的是：它能不能在客户现场跑起来，能不能在内网环境里用起来，能不能让一份文件打开以后，尽量保留它原本该有的秩序。

也正是从那个时候开始，我们心里有了一个越来越清楚的判断：如果一直停留在整合层面，我们能解决很多“有没有”的问题，却很难长期解决“像不像”“稳不稳”“能不能交付”的问题。

于是，我们开始走向自研。

这一步说起来简单，真正走进去之后，才知道它意味着什么。

它意味着不能再把问题都归结为某个开源库的限制，意味着每一次渲染异常都要自己拆，意味着一个段落、一个制表符、一个图形、一张表格，都可能变成需要反复追下去的细节。

也意味着，这个项目从那一刻开始，变得更重，也更像我们自己的东西了。

为什么我们不满足于只做集成 🧭

我们并不否认集成方案的价值。

像 jit-viewer、vue-office-view 这类项目，确实帮助很多前端项目快速完成了文件预览入口。我们自己最早也走过类似路线，也很清楚这种方式在早期验证、快速接入、降低门槛上有它自己的意义。

只是，随着我们接触的真实文件越来越多，看到的问题也越来越具体。

一个 Word 目录里的点线错位，背后可能不只是一个样式问题，而是段落缩进、制表位、超链接结构和页面容器共同作用的结果。

一个 PPT 图形位置不对，背后可能牵涉 DrawingML、母版、组合图形、裁剪区域、坐标换算和渲染层级。

一个表格撑破页面，背后可能有单元格宽度、行高、边框、内边距、浮动对象、分页策略和缩放方案。

这些问题，不会因为“再接入一个组件”就自然消失。

它们需要有人愿意趴在真实文件上，一页一页看，一行一行调，一次一次对照原始文档。很多时候，外人看到的只是一个页面终于正常了，但我们自己知道，那个页面背后可能已经经历过很多次推翻和重来。

所以，我们选择完全自研。

不是因为我们觉得这条路更容易，也不是因为我们想把话说得很漂亮。只是我们越来越确定，企业文档预览如果想走得更远，核心能力必须掌握在自己手里。

纯前端、本地解析、源码可用、安全可控，这些词听起来并不热闹，但落到企业项目里，它们就变成了很实在的价值：文件不需要交给远端转换链路，部署不需要引入庞大的在线办公套件，系统集成也可以保持更轻的边界。

对很多 OA、档案、合同、网盘、知识库、CRM、SaaS 附件预览场景来说，这种轻量，可能正是它们真正需要的东西。

最近这轮，我们又把哪些地方往前推了一点 🔧

这次更新，并不是简单换一个版本号。

我们围绕 DOCX、PPTX、老版 PPT、MS-DOC 和 Demo 展示体验，又做了一轮比较集中的打磨。很多改动如果只写成技术列表，看起来会有些冷冰冰；但落到真实使用里，它们其实都在指向同一个目标：让文档打开之后更像原来的样子，让用户阅读时少一点疑惑，让项目交付时多一点底气。

在 DOCX 上，我们继续处理目录制表符、段落缩进、符号项目符号、EMF 图形、OMML 公式、数学修订痕迹、表格和分页等细节。

这些听起来都是很小的点，但它们会直接影响一份 Word 文档的正式感。企业里大量存在的测试报告、接口规范、验收材料、项目文档和档案说明，往往并不花哨，却对结构和版式非常敏感。标题有没有层级，目录点线有没有对齐，编号有没有变成奇怪符号，表格有没有撑破页面，都会影响用户对这个预览能力的第一判断。

在 PPTX 上，我们继续补 DrawingML 文本布局、PowerPoint 表格、组合装饰元素、表格样式、OLE fallback、EMF / DIB 资源等内容。

PPT 的难点和 Word 不太一样。Word 更像一份连续的文档，而 PPT 是一页一页被设计出来的画面。文字框、背景、图形、组合对象、表格、裁剪和层级关系，都会共同决定它最后像不像一页真正的演示文稿。

如果少了一个装饰元素，或者某个图形偏了一点，用户也许说不出具体原因，但会立刻觉得这个页面“不太对”。

所以我们这一轮在 PPTX 上花了不少时间，就是希望那些更复杂、更接近真实业务的页面，也能慢慢呈现出它原本的画面感。

我们也没有放下老版 PPT 和 DOC。

真实客户的文件从来不会只给你新格式。很多企业里，历史 .ppt、.doc 仍然大量存在，而且这些文件往往承载着更长时间的项目资料、归档资料和内部模板。它们不一定好处理，却很难绕开。

这一轮里，我们继续补老版 PPT 的母版布局、旧图形、分组图片裁剪、字体 fallback、段落间距、日期字段和短文本布局；也继续推进 DOC 里的目录、列表、表格、符号、页眉页脚、浮动对象和文档模型表达。

这些工作看起来不够“新潮”，但对企业场景来说，它们常常非常实际。

Demo 也不只是换了一个界面 ✨

这一次，我们还认真整理了 Demo。

以前的 Demo 更像一个测试页：选文件、点渲染、看结果。它可以验证功能，但还不够像一个真正给用户看的产品。

我们后来越来越觉得，Demo 其实是第一层信任。

用户第一次打开产品时，看到的不是代码结构，也不是我们背后的解析链路，而是页面给他的直观感受：它是不是清楚，是否有秩序，状态是不是明确，出了问题能不能知道问题在哪里。

所以这次 Demo 做了更产品化的整理。左侧导航按文档、演示、表格分组，Word / PowerPoint / Excel 使用更清楚的主题区分，内置样例和上传入口放到更直观的位置，渲染状态、耗时、模型和 WASM 状态集中展示，诊断信息也调整成抽屉形式，让预览区尽量保持干净。

还有一个比较重要的变化，是按需加载。

只有在选择对应格式之后，相关模块才会进入页面。这样做并不只是为了技术上好看，而是希望产品本身更轻，让用户在打开页面时少承担一些不必要的资源成本。

这三年，我们其实经历了很多不太好讲的时刻 🌧️

如果只写技术更新，这篇文章会比较容易写。

列出格式，列出能力，列出优化点，再放几张截图，看起来就像一篇标准的产品发布文章。

但这不是我们真正想说的话。

我们确实已经辛苦开发了三年多。中间团队的人散了聚，聚了又换，有人离开，有人重新加入，有些阶段只剩下我和几个核心成员还在往前撑。

大家都知道这件事不好干。

纯前端 Office 预览不是一个特别容易被看好的方向。它不像 AI 应用那样站在风口上，也不像一个简单工具那样可以很快做出完整闭环。它要面对的是大量格式细节、历史文件、浏览器限制、部署环境、客户现场和无穷无尽的真实样例。

有时候，外面的人可能只看到我们说“又优化了一些细节”。

但真正做过的人会知道，所谓细节，往往就是最难的地方。

一个目录对齐，可能要追很久。

一个 PPT 图形，可能要拆好几层。

一个老格式文件，可能没有那么多现成资料可以查。

一些问题我们自己想不通，也会各方请教。为了把一些难题走通，我们联系过做 WPS 的前辈，请他们给我们提供思路。那种时候也会很清楚地感受到，文档预览这件事不是靠热情就能做好的，它需要经验，需要耐心，也需要承认自己还有很多不懂。

但是，当某个真实文件终于渲染得更像了，当某个客户反馈的问题终于被定位出来，当某个原本看起来绕不过去的格式细节终于有了眉目，那种满足感又非常真实。

它不是那种很热烈的兴奋。

更像是一个技术人心里很安静的快乐：这个地方，我们又往前挪了一点。

在 AI 时代，我们为什么还要做这种看起来有点“笨”的事情 🌊

现在的技术环境变化非常快。

AI 正在重塑很多软件的边界，大家也都在追逐更快、更聪明、更自动化的东西。放在这样的背景下，我们还在抠目录、表格、段落、图形、母版、EMF 记录，好像显得有一点慢。

甚至有时候，我们自己也会想：是不是太笨了？

但后来想想，这也许正是我们这个团队最真实的地方。

我们是一群技术人。我们不太擅长把故事讲得特别热闹，也不太擅长把产品包装成一个很宏大的概念。我们更熟悉的方式，是把一份文件打开，把不对的地方圈出来，然后一点点去调。

每一个样式的变化，每一个版式的修正，每一个异常文件的归因，都会让我们觉得，这个产品正在变得更像它应该成为的样子。

这听起来可能不够浪漫。

但对我们来说，这就是那枚年轻时种下的小小种子。

很多年前，我们只是希望前端也能把文档预览这件事做得更轻一点。几年过去了，这个想法没有被拔掉，反而在一次又一次真实文件的打磨里，慢慢长成了现在的 Flyfish Office Preview。

商业化不是突然开始的生意，而是为了让项目继续走下去 💬

我们现在认真做商业化，并不是因为这件事突然变轻松了。

恰恰相反，是因为它太消耗人了。

如果一个项目长期只有投入，没有稳定回流，最后很容易变成少数人的情怀支撑。情怀当然重要，但情怀不能让团队一直活下去，也不能让我们有足够精力继续看客户文件、继续修格式细节、继续维护部署环境、继续把产品做得更稳。

所以商业化对我们来说，不只是“卖一个产品”。

它更像是给这个项目一条继续往前走的路。也让这几个还在坚持的人，有一点更踏实的底气，把心里那件事继续做完。

我们希望购买 Flyfish Office Preview 的朋友，得到的不只是一个代码包，也不只是一个可以打开文件的预览页面。

你得到的应该是一套可以进入真实项目现场的能力：纯前端、本地实现、源码可用、轻量部署、安全边界清楚，并且有人愿意陪你一起把它接进业务系统里。

购买之后，我们也会继续把效果往前推 🤝

这里也想很认真地说一句：Flyfish Office Preview 不是卖完就结束。

在合理范围内，我们会根据购买客户的实际文件和真实需求，持续做更新和优化，尽力把预览效果推进到客户满意、项目可交付的程度。

这不是一句轻飘飘的承诺。

因为 Office 预览这种产品，如果只靠我们自己想象，很容易越做越偏。真实客户给出的每一份异常文件，都是下一轮优化的线索。

一个表格撑破页面，可能背后是行高计算的问题。

一个 PPT 图形缺失，可能背后是某一类 DrawingML 或 EMF 记录还没有覆盖。

一个目录点线错位，可能背后是制表位、段落缩进和超链接布局之间的关系还没有处理到位。

我们会认真看这些问题，也会尽量把它们沉淀成产品能力。只要需求真实、方向合理，并且对产品长期价值有帮助，我们都会持续投入。

这也是我们希望大家支持的原因。

这个产品不应该在一个封闭环境里独自生长。它需要真实用户，需要真实文件，需要真实反馈，也需要一批愿意给它机会的人。

售后也不是把文件发过去就结束 🛠️

做企业预览，很多真正麻烦的地方并不发生在演示页面里，而是发生在部署之后。

文件地址要登录态。

客户网关改了响应头。

iframe 嵌入之后高度不对。

CSP 或跨域策略拦住了资源。

某个历史 .doc 或 .ppt 里有少见对象。

某个客户模板里出现了很特殊的版式组合。

这些问题如果没有人陪同排查，会消耗很多项目时间，也会让原本只是“加一个预览”的需求，变成一件非常疲惫的事情。

所以我们的售后更像是部署陪跑。

从部署、域名、授权、文件访问，到样例文件定位、页面集成、疑难问题处理，我们愿意陪同完成整个过程，直到预览能力真正达到可使用、可验收、可交付的状态。

软件产品最终比较的，不只是功能列表。

也包括问题出现的时候，是否有人愿意认真接住，并且持续把它往前推进。

定制适配也会继续做 🧩

我们也会继续关注插件式适配能力。

比如可道云这类系统，它不是简单打开一个独立页面就结束。它需要从原系统文件列表进入预览，需要接收文件参数，需要处理鉴权，需要保持嵌入体验，还要尽量不破坏原有操作习惯。

我们会继续支持这类定制能力，包括可道云插件式适配、内网私有化部署、指定域名授权、文件接口鉴权打通、UI 风格融合、客户样例文件专项优化，以及按项目需求扩展预览入口。

我们不希望客户为了接入一个预览能力，就重新调整整个系统。

更理想的方式是：Flyfish Office Preview 像一块干净的模块，被放进原有业务流里，然后安静地工作。

最后，想认真说一句谢谢 🙌

如果你从 file-viewer 时代就关注过我们，真的很感谢。

如果你曾经提过需求、反馈过问题、拿真实文件让我们排查，也谢谢你。那些看起来麻烦的文件，很多时候正是产品往前走的机会。

如果你现在正在做 OA、档案、合同、知识库、网盘、CRM、SaaS 附件预览，或者你正在寻找一个更轻、更安全、更容易私有化交付的 Office 预览方案，也欢迎来看看 Flyfish Office Preview。

我们知道这条路不容易。

也知道很多人并不一定看好它。

但是既然已经走了这么久，既然它确实在越来越多真实文件里变得更好，既然我们心里那枚小小的种子还在，那我们就想继续把它做下去。

慢一点也没关系。

笨一点也没关系。

只要每一次更新之后，文档更像一点，部署更轻一点，客户更放心一点，我们就觉得这件事还有继续向前的意义。

产品主页：

https://product.flyfish.group^[1]

购买入口：

https://dev.flyfish.group/shop^[2]

售后邮箱：

wybaby168@gmail.com^[3]

微信客服：

Yous_Gift

希望 Flyfish Office Preview 能成为纯前端 Office 预览里，一个真正拿得出手、能够进入项目现场、也经得住真实文件考验的选择。

也希望你们能继续陪我们往前走。🌱

引用链接