——从 Open File Viewer 聊聊”体验体系化”的底层逻辑

> 前端做文件预览，基本都踩过坑。PDF 一个库，Word 一个库，Excel 一个方案，图片视频自己写，压缩包直接下载，复杂一点的 CAD、3D、GIS 文件，很多项目干脆放弃。

最近看到一个开源项目 Open File Viewer，体验比我预期好很多。

它不是单纯做 PDF 预览，也不是又封装一个图片预览组件，而是一个面向 Web 产品的前端文件预览 SDK。核心思路很直接：把各种文件预览统一放进一个可控容器里，让你可以在弹窗、抽屉、详情页、审批流、附件中心里直接预览，而不是动不动跳页面或者强制下载。

看完之后我想聊的不是”这个库有多好”，而是：这个项目无意中揭示了一个前端工程化的底层问题——”能用”和”能用好”之间，差的不只是功能，而是一套体系。

—

🔥 先说痛点：为什么前端文件预览这么难做

做过后台系统的人都知道，文件预览是个”看起来简单，做起来要命”的需求。

表面需求：用户点一个附件，打开看看。

真实需求： – 加载状态（loading、error、unsupported） – 多文件切换（上一个/下一个） – 下载、全屏、搜索、打印 – 主题适配（dark mode） – 工具栏扩展（审批、归档、收藏、分享、打标签） – 格式兜底（不支持的格式怎么办） – 性能（大文件、多文件并发）

以前怎么做？ – PDF 用 pdf.js – 图片用 lightbox 或者自己写 – Office 用微软的在线预览或者 LibreOffice 转换 – 视频用 video.js – 压缩包……直接下载吧 – CAD、3D、GIS……算了吧

最后结果是：功能是能用，但体验很割裂。 有的跳出当前 tab，有的打开新页面，有的强制下载，有的样式完全不统一。

说白了，就是能用，但不好用。

🎯 Open File Viewer 的核心价值：不是”能预览”，是”能体系化地预览”

这个库最吸引人的点，不是”支持 110 种格式”（虽然这个数字很吓人），而是它把文件预览做成了一套体系。

具体来说，它解决了三个问题：

1. 统一容器：预览不再是”跳出去”

以前做文件预览，最常见的体验是：用户点附件 → 新 tab 打开 → 看完关掉 → 回到原页面。

这个流程的问题不是”不能预览”，而是预览脱离了业务上下文。

Open File Viewer 的思路是：预览应该在当前业务场景内完成——弹窗、抽屉、详情页、审批流、附件中心。用户看完文件，直接就能做下一步操作（审批、归档、收藏、分享），不需要”先关掉预览，再回到业务页面，再找到那个按钮”。

这才是”能用好”和”能用”的本质区别：前者把预览当成业务流程的一部分，后者把预览当成一个独立功能。

2. 插件机制：扩展性不是”加功能”，是”加能力”

以前做文件预览，通常是在业务代码里写一堆判断： – PDF 走 PDF 逻辑 – 图片走图片逻辑 – Word 走 Word 逻辑 – 都不支持就下载

格式少的时候还能撑住，格式一多就很难维护。

Open File Viewer 把这些能力拆成了插件： – `imagePlugin()` – `videoPlugin()` – `audioPlugin()` – `textPlugin()` – `pdfPlugin()` – `officePlugin()` – `archivePlugin()` – `emailPlugin()` – `drawingPlugin()` – `cadPlugin()` – `model3dPlugin()` – `gisPlugin()` – `fallbackPlugin()`

每个插件只负责一类文件，核心只负责识别文件、匹配插件、挂载渲染和处理状态。

更重要的是，它支持自定义插件。 公司内部经常会有一些奇怪格式，比如 `.report`、`.logx`、`.schema`、`.flow`。以前遇到这种文件，只能在业务代码里硬写判断。现在可以单独写一个插件，把它放进插件列表里，让它优先匹配。

这样主流程不会被污染，业务特殊格式也能独立维护。

这才是文件预览库该有的扩展方式：不是”我帮你把所有格式都做了”，而是”我帮你把扩展机制做好了，你自己加”。

3. 自定义工具栏：预览不是”看完就关”，是”看完继续做”

很多预览库 Demo 看着还行，一接业务就不够用了。

默认就几个按钮：下载、全屏、关闭。

可真实系统里，用户预览文件之后，往往还要继续做操作： – 看完合同，直接审批 – 看完资料，直接归档 – 看完文档，直接收藏 – 看完附件，直接分享 – 看完文件，打标签或标记已读

Open File Viewer 的工具栏可以分层定制： – 只改文案（Download → “下载”） – 调整按钮顺序 – 换图标 – 增加业务按钮 – 完全替换整套工具栏

这对 OA、CRM、ERP、审批系统、网盘、知识库特别有用。因为这些系统里的文件预览，本质上经常是业务流程的一部分。工具栏能不能扩展，决定了这个组件到底只是一个 Demo，还是能真正放进业务系统。

🧭 从”能用”到”能用好”：前端工程化的下一个战场

看完这个项目，我想聊一个更大的话题：前端工程化的下一个战场，不是”功能实现”，而是”体验体系化”。

过去十年，前端工程化的主线是： – 组件化（React、Vue） – 工程化（Webpack、Vite） – 类型化（TypeScript） – 状态管理（Redux、MobX、Zustand）

这些解决的都是”怎么把代码写好”的问题。

但接下来十年，前端工程化的主线应该是：怎么把体验做好。

具体来说： – 统一容器：不是”这个功能在哪实现”，而是”这个功能在什么上下文里实现” – 插件机制：不是”我帮你把所有场景都做了”，而是”我帮你把扩展机制做好了” – 工具栏定制：不是”给你几个按钮”，而是”给你一套按钮的治理规则”

这才是”体验架构师”该干的事：不是写代码，而是定义”代码怎么组织、能力怎么扩展、体验怎么治理”。

️ 一个血淋淋的现实：110 种格式不等于 110 种完美预览

文章里提到 Open File Viewer 支持 110 种文件格式，这个数字很吓人。

但我要泼一盆冷水：110 种格式覆盖，不等于每一种都已经做到高保真完美预览。

– 图片、音视频、文本、代码、PDF 这类基础格式，已经是比较明确的预览能力 – Office、电子书、邮件、压缩包属于基础到增强预览 – CAD、3D、GIS、设计稿这类复杂格式，更偏识别、基础预览和持续增强

但这个方向是对的。

文件预览本来就不是靠一个库把所有复杂格式一次性做到完美，尤其是 Office、CAD、设计稿这种格式，本身就很复杂。

真正重要的是先把预览入口、容器、状态、插件协议和兜底机制统一起来。只要底座统一，后面复杂格式就可以继续增强，可以接 WASM，也可以接服务端转换。

这才是”体系化”的价值：不是”我现在能做什么”，而是”我未来能怎么扩展”。

🏗 给不同阶段的工程师一句话

如果你在做后台系统（OA、CRM、ERP）： – 别再用”新 tab 打开 PDF”这种远古方案了。文件预览是业务流程的一部分，不是独立功能。找个能嵌入当前页面的方案，让用户”看完直接做下一步”。

如果你在做开源组件库： – 别只想着”我支持多少格式”，想想”我的扩展机制够不够灵活”。用户真正需要的不是”你帮我做所有事”，而是”你帮我做好底座，我自己加”。

如果你是前端负责人： – 文件预览这种”看起来简单”的需求，其实是检验团队”体验体系化”能力的试金石。如果你们连文件预览都做不好（跳 tab、强制下载、样式不统一），那更复杂的体验治理（设计系统、性能预算、无障碍）就更别想了。

💡 最后说一句

前端文件预览，真的不应该再靠一堆零散库硬拼了。

Open File Viewer 的价值不只是”能预览多少格式”，而是把文件预览做成了一套体系： – 110 种文件格式覆盖 – 自定义工具栏 – 插件机制 – 15+ 内置预览插件 – 支持自定义插件 – 支持 Vanilla JS / React / Vue / Svelte – 统一容器内预览 – 统一状态和 fallback

这才是我觉得它好用的地方：它不是”又一个预览库”，而是”预览这件事终于有人体系化了”。

> 如果你觉得这个项目对你有帮助，也欢迎去 GitHub 点个 Star 支持一下。开源项目不容易，大家的每一个 Star，都是继续迭代下去的动力。

项目链接 – 官网：https://open-file-viewer-workspace.void.app/ – GitHub：https://github.com/xushanpei/open-file-viewer – npm：https://www.npmjs.com/package/@open-file-viewer/core

相关阅读 – [“AI 前端工程师”是风口吗？](https://helloxin.cn/archives/81.html) —— 前端工程师的转型方向：从”写页面”到”掌控体验” – [别用 ChatGPT 的方式用 Codex](https://helloxin.cn/archives/78.html) —— AI 助手下半场：空间治理与工具链管理