企业官网建设流程全解析

做中后台系统这些年，我接过最多的需求不是复杂图表，反而是“能预览就行”。业务方甩过来一句话：合同上传之后能不能直接看？课件 PPT 能不能在线打开？Excel 报表别让我下载了，页面上给我渲染出来。于是 Word、Excel、PDF、PPT、MP4、图片、文本……全都堆到前端头上。做完几个项目你会发现，这套东西看着零散，其实每个文件类型都有相对固定的解法：图片、文本、视频属于浏览器原生能搞定的一类；PDF 可以走原生 embed 或 pdf.js；docx、xlsx 这类办公文档要靠社区库；ppt 和老版 doc 最麻烦，纯前端硬啃不划算。这篇文章把我从选型、实现到踩坑的完整过程整理一遍，适合正在做中后台、低代码平台、在线网盘、课程系统的同学参考，面试前想系统梳理这类知识点的人也能用上。

1. 为什么前端文件预览是个“绕不开”的需求

1.1 不是炫技，是业务真的需要

很多时候，产品提“在线预览”不是跟风，而是被用户逼的。我做过一个合同审批系统，用户每天要审几十份合同，采购、销售、法务各环节都要看附件。如果每次都要下载下来、用本地 Office 打开、看完再关掉，审批效率至少要砍掉一半。后来加了一个“点击附件直接预览”的按钮，用户反馈立刻就不一样了。

类似的场景还有很多。比如在线教育平台，学员要看的课堂材料大多是 PPT 或 PDF，你不能让人先下载再自动跳转本地播放器；知识库系统里散落着大量 Word 文档和 Excel 表格，最好的体验就是点开就能读；招聘系统里候选人的简历可能是 PDF，也可能是 docx，HR 不想为了看简历再去装 Office；还有视频培训资料，网页端能直接播放是底线需求。

这类需求的关键词就三个：在线、直接、不用装软件。用户不在乎你底层用的是什么方案，他只希望“在浏览器里点一下，东西就出来”。所以前端预览不是某个系统的专属功能，而是几乎所有“带附件”的系统都躲不过去的一关。

1.2 技术路线的岔路口：纯前端还是服务端转换

很多人第一次接触文件预览，会下意识去搜“前端打开 word”“前端解析 ppt”，然后被一堆方案绕晕。这里我觉得最有效的思考方式是先分清楚两条路线。

纯前端路线的本质是：把文件交给 JavaScript 解析，再渲染到 DOM、canvas 或者 video 标签上。它最大的优势是不依赖额外服务，前端部署完就能用，成本低、响应快。缺点是不同格式的解析难度天差地别，图片、PDF、docx、xlsx 都有成熟的纯前端库，但老版 doc、复杂版式的 PPT 想纯前端还原就很难。

服务端转换路线的本质是：服务器上用 LibreOffice、Aspose 之类的工具，把原始文件转成 PDF、图片或者 HTML，前端只负责展示转换结果。它的优势是保真度高、不挑浏览器，看得见就能还原；缺点是必须有服务端配合，转换有延迟，格式多的时候还要做任务队列和缓存。

我在实际项目里定的原则很简单：

• 浏览器原生支持的，就用原生能力，比如图片、视频、文本。
• 原生支持不了的，优先找成熟的社区库，比如 pdf.js、docx-preview、SheetJS。
• 社区库都做不到的，再上服务端转换兜底，比如老版 doc、复杂 PPT。

这套原则的好处是能用最低成本覆盖 90% 的场景，剩下 10% 的硬骨头交给服务端，前端不会为了一个低概率格式把架构搞复杂。

2. 预览方案全景：先把武器库和基础 API 盘清楚

2.1 不同文件格式的选型对照表

我习惯在项目启动前先做一张选型表，把每种格式的推荐方案、实现成本、保真度列清楚，这样写代码的时候不会东一榔头西一棒子。下面这张表是基于我自己项目经验的整理，你可以直接拿去做技术方案。

表格排下来你会发现一个规律：越接近“纯文本”和“单页渲染”的格式越简单，越接近“办公排版”的格式越麻烦。图片、文本、视频本质上是浏览器已经帮你做了解析；PDF 是单页排版，PDF.js 这种成熟方案能兜住；Word、Excel、PPT 这种复合文档格式，解析和重排都是重活。所以选型不是越高级越好，而是够用就好。

2.2 Blob URL 与 FileReader：两个绕不开的基础 API

不管最后用哪个库，有四个浏览器 API 你是绕不开的，分别是URL.createObjectURL、FileReader、Blob.slice和TextDecoder。前两个几乎是所有预览方案的基石，我先把这个讲明白。

URL.createObjectURL(file)会生成一个临时 URL，指向浏览器内存里的文件对象，它的特点是零拷贝、不改变原始文件体积，性能很好。使用场景是图片、视频这种“能直接喂给标签”的文件。用完以后需要调用URL.revokeObjectURL(url)释放，否则会持续占用内存，预览多了页面会越来越卡。

FileReader则适合把文件内容读成文本、Data URL 或者 ArrayBuffer。比如读文本文件用readAsText，读 Excel 文件用readAsArrayBuffer再交给解析库。要注意readAsDataURL读出来的是 base64，同样一段内容体积会比原文件大 33% 左右，所以大文件尽量不要用 Data URL，能选 ArrayBuffer 或者 Blob URL 就选后者。

现在file.arrayBuffer()这个原生方法也很常用，写起来比 FileReader 简洁，但兼容性要看你项目目标浏览器。如果是内部管理系统，浏览器版本可控，我一般直接用file.arrayBuffer()；如果要兼容老环境，还是回退到 FileReader 更稳。

3. 基础格式实战：图片、文本、视频

3.1 图片预览：从 objectURL 到内存释放

图片是前端预览里最简单的一种，核心代码就几行：

<input type="file" id="fileInput" accept="image/*" /> <img id="previewImg" alt="预览" />

document.getElementById('fileInput').addEventListener('change', function (e) { const file = e.target.files[0]; if (!file) return; const url = URL.createObjectURL(file); const img = document.getElementById('previewImg'); img.src = url; img.onload = () => URL.revokeObjectURL(url); // 图片加载完成就可以释放 });

这里有个细节值得单独说：img.onload里revokeObjectURL是可以的，因为图片已经加载完成，浏览器不再依赖这个临时 URL 了。但如果图片后续还要用，比如点击放大、重新加载、或者切换预览对象，你就不能急着释放，应该等组件的销毁逻辑里统一处理。

我实际踩过的一个坑是缩略图列表。页面上有几十个附件，每个附件都生成了 objectURL，但没有及时 revoke，结果用户切页切了半天，浏览器直接崩溃。后来我把所有 objectURL 收集到一个数组里，在页面卸载或者列表刷新时统一回收：

const objectURLs = []; function generateThumb(file) { const url = URL.createObjectURL(file); objectURLs.push(url); return url; } function clearURLs() { while (objectURLs.length) { URL.revokeObjectURL(objectURLs.pop()); } }

另外，如果产品需要生成缩略图而不是原图预览，建议用 canvas 把图片压小一点再展示，既能加快首屏速度，又能减少内存压力。图片本身是位图，展示尺寸远远小于文件分辨率的场景非常常见，压缩带来的观感损失几乎可以忽略。

3.2 文本预览：编码识别与大文件分段读取

文本预览看起来简单，实际上有一个特别容易被坑的地方：编码。浏览器环境的file.text()和FileReader.readAsText默认按 UTF-8 解码，但现实中还有很多配置文件、日志文件是 GBK 或 GB2312 编码，直接读出来全是乱码，用户第一反应就是“这个预览功能是坏的”。

解决办法是手动指定编码。把文件读成 ArrayBuffer，再用TextDecoder解码：

const buffer = await file.arrayBuffer(); const text = new TextDecoder('gbk').decode(buffer);

TextDecoder在浏览器里是原生支持的，第二个参数传'gbk'就行。如果文件编码不确定，可以引入 jschardet 或者 encoding-japanese 这类库做自动识别，识别完再决定用哪个 decoder 解码。不过自动识别不是 100% 准确的，遇到解析不到的文件还是得提供“下载”兜底。

还有一个问题是超大文本。一个几百 MB 的日志文件，如果一次性读进内存再渲染，页面会卡到没法操作。正确做法是分段读取，用Blob.slice每次切 1MB 出来，读完一段追加一段：

const CHUNK_SIZE = 1024 * 1024; // 1MB let offset = 0; async function readLargeText(file) { const container = document.getElementById('textContainer'); container.textContent = ''; while (offset < file.size) { const chunk = file.slice(offset, offset + CHUNK_SIZE); const text = await chunk.text(); container.textContent += text; offset += CHUNK_SIZE; // 可以在这里做滚动位置记录，避免每次追加都跳回顶部 } }

注意不要用字符串无限拼接当容器内容，如果文本行数特别多，DOM 节点和渲染压力都会上来。更稳的做法是只展示前几千行，超过部分提示“文件过大，仅预览部分内容，请下载查看”。

3.3 视频预览：video 标签与 Range 分片请求

视频预览比前面几个略复杂一点点，因为它在浏览器里的表现高度依赖编码格式和服务端配置。核心代码倒是很少：

<video id="videoPlayer" controls preload="metadata" style="width: 100%;" ></video>

const video = document.getElementById('videoPlayer'); video.src = URL.createObjectURL(file);

本地文件预览用 objectURL 完全没问题。但线上视频预览，比如从 OSS 或 CDN 拉地址，就不是右键能搞定的了。最大的问题是“拖拽播放”。很多同学会遇到视频能播开头，但一拖进度条就转圈圈，那是因为服务端没有支持 Range 请求。

Range 是 HTTP 协议里的一个请求头，浏览器播放视频时不会一次下完整份文件，而是用Range: bytes=0-这种请求分段拉取数据。服务端要返回Accept-Ranges: bytes和206 Partial Content，拖到哪个位置就向后端请求哪个片段。Nginx、OSS 默认都支持 Range，但有些自定义文件服务或者 CDN 节点没有开启，前端怎么折腾都没用，这种情况要推动后端配置。

编码格式也是一个坑。MP4 文件内部也有讲究，H.264 + AAC 是兼容性最好的组合，Chrome、Firefox、Safari 基本都能播；如果是 H.265/HEVC 编码，Safari 可能没问题，但 Chrome 在很多系统上不支持；WebM 格式则相反，Safari 兼容性较差。所以在做视频预览时，最好是后端或上传端统一限制格式，比如“只允许上传 H.264 编码的 MP4”，省得前端做一堆兼容分支。

4. PDF 预览：原生 embed、pdf.js 三选一

4.1 原生 embed/iframe：零依赖但短板明显

如果只是内部系统临时用一下，最快的方式是把 PDF 地址直接塞进 embed 或 iframe：

<embed :src="pdfUrl" type="application/pdf" style="width: 100%; height: 100%;" />

零依赖，后端返回一个 PDF 地址，前端一行代码就能预览。Chrome 和 Edge 会调用内置的 PDF 阅读器，自带工具栏，用户能翻页、缩放、打印，体验其实不差。

但它的短板也很明显。首先是 UI 不统一：Chrome 和 Firefox 的 PDF 工具栏长得不一样，Safari 更是基本裸奔，很多功能都没有。其次是无法定制：你想统计用户翻到了第几页，想看用户停留时长，想给 PDF 加水印或者限制打印，只靠 embed 一个标签完全做不到。还有兼容性：老浏览器，比如 IE 11，直接就不支持 embed 渲染 PDF。如果你的系统明确只给内部办公使用、浏览器是可控的 Chrome，这个方案可以；否则就得往下看 pdf.js。

4.2 pdf.js 分页渲染：能定制、能统计，但要管理好 canvas

pdf.js 是 Mozilla 团队开源的 PDF 解析渲染引擎，也是目前前端 PDF 预览的标杆方案。它能把 PDF 的每一页渲染到 canvas 上，灵活度和可控性都远超原生 embed，企业系统里做预览组件基本首选它。

引入方式有两种。一种是直接引 CDN：

<script src="https://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/pdf.min.js"></script>

另一种是 npm 装包，然后在代码里用import * as pdfjsLib from 'pdfjs-dist'。下面是核心的渲染逻辑：

const loadingTask = pdfjsLib.getDocument(pdfUrl); const pdf = await loadingTask.promise; // 先渲染第一页 const page = await pdf.getPage(1); const viewport = page.getViewport({ scale: 1.5 }); const canvas = document.getElementById('pdfCanvas'); const ctx = canvas.getContext('2d'); canvas.width = viewport.width; canvas.height = viewport.height; const renderContext = { canvasContext: ctx, viewport: viewport }; await page.render(renderContext).promise;

注意pdfjsLib.getDocument返回的是一个 loadingTask，用await loadingTask.promise才能拿到 pdf 对象。渲染每一页需要先getPage(n)拿到页面对象，再调用page.render。这里的scale控制清晰度，一般我会用window.devicePixelRatio做适配，让高分屏下不至于模糊。

把多页 PDF 渲染出来的思路，就是循环所有页码分别创建 canvas 元素，但这里有一个性能陷阱：PDF 文件动辄几十上百页，全部渲染成 canvas 会导致 DOM 节点爆炸，内存直接爆掉。最好的做法是类似图片懒加载，只渲染用户当前能看到的那几页，配合滚动容器动态创建和销毁 canvas。

4.3 中文渲染、字体加载与虚拟滚动

pdf.js 最恶心的问题之一是中文字体渲染异常。表现是文字变成方框、乱码，或者有些字符渲染不出来。这通常是因为 PDF 文件里嵌的字体子集不支持，或者 pdf.js 缺少对应的字体映射数据。解决办法是配置 CMap 资源目录：

pdfjsLib.GlobalWorkerOptions.workerSrc = '/pdfjs/pdf.worker.min.js'; const loadingTask = pdfjsLib.getDocument({ url: pdfUrl, cMapUrl: '/pdfjs/cmaps/', cMapPacked: true });

CMap 是 PDF 字符映射表，pdf.js 源码包里自带cmaps目录，把它部署到静态资源目录，然后指定cMapUrl就行。如果你是自己搭的 pdf.js，这个配置很容易漏；如果你用的 vue-pdf、react-pdf 这类封装库，它们一般已经处理好了，但遇到极端文件仍然可能中招。

虚拟滚动就涉及更多细节了。我通常用一个固定高度的滚动容器，监听scroll事件，计算当前可视区域对应 PDF 的哪些页，然后只渲染这些页面的 canvas。已经滚出屏幕的页会把它从 DOM 中移除，并释放对应的 canvas 内存。如果你不想手写这么复杂的逻辑，可以在社区里找一些基于 pdf.js 做好的预览组件，但大概率还是要二次改造，因为业务方总会提“我要加页码水印”“我要标注”这类的定制需求。

5. Word 预览：docx 和 doc 是两条路

5.1 docx-preview：保真度最高的纯前端方案

docx 是 Office Open XML 格式，本质上是一个 ZIP 压缩包，里面装着各种 XML 描述文件。前端解析 docx，靠的是 docx-preview 这样的库。这个库会把 docx 解压、解析 XML，然后重排成 HTML，能支持分页、表格、图片、页眉页脚，样式还原度在开源库里算很不错的。

安装以后核心代码非常少：

npm install docx-preview

import { renderAsync } from 'docx-preview'; async function previewDocx(url) { const res = await fetch(url); const arrayBuffer = await res.arrayBuffer(); const container = document.getElementById('wordContainer'); container.innerHTML = ''; await renderAsync(arrayBuffer, container); }

renderAsync支持传入 ArrayBuffer、Blob 或者文件对象，第二个参数就是挂载的容器。docx-preview 还支持第三个样式容器，用来注入样式；第四个参数可以控制渲染选项，比如是否显示分页符。如果只有一份 docx 文件放在本地，也可以直接renderAsync(file, container)，不用先转 ArrayBuffer。

实际使用中要注意两个问题。第一是渲染大文档时页面会卡，因为需要同时解析和生成大量 DOM，建议在渲染前显示 loading 遮罩，渲染完成再隐藏；第二是图片较多的 docx 会比较吃内存，上传前限制单个文件体积能缓解不少。

5.2 mammoth：适合“内容优先”的报告场景

mammoth 是另一个 docx 预览方案，但它的思路不一样——它把 docx 转成干净的 HTML，而不是尽量还原原排版。这意味着它更适合“内容优先”的场景，比如政策文件、通知公告、纯文字报告，它能提取出标题、段落、列表、表格这些结构，抛弃复杂的样式。

import mammoth from 'mammoth'; const result = await mammoth.convertToHtml({ arrayBuffer }); document.getElementById('preview').innerHTML = result.value;

用 mammoth 的优点是快、轻、输出干净，不会像 docx-preview 那样动不动渲染一堆带内联样式的复杂 DOM。缺点也明显：一些 Word 的高级排版细节，比如文本框、艺术字、复杂页眉页脚，它可能直接丢失或变样。

所以这两个库怎么选，取决于业务诉求。如果业务是“用户上传自己的 Word 合同，期望界面和本地打开差不多”，用 docx-preview；如果业务是“平台后台管理文章，上传的 Word 只是内容来源，展示时用自己站点的样式”，用 mammoth 反而更合适，因为输出 HTML 更好做统一样式管理。

不管用哪个库，我都要强调一个问题：渲染出来的内容等于把文件里的 HTML 插进了你的页面。如果文件来自不可信的第三方，里面隐藏了恶意脚本，不处理就直接 innerHTML 进去，等于给攻击者留了一个 XSS 入口。我的习惯是渲染后统一用 DOMPurify 消毒一遍：

import DOMPurify from 'dompurify'; const cleanHTML = DOMPurify.sanitize(result.value); container.innerHTML = cleanHTML;

5.3 老版 doc：别指望纯前端了

doc 和 docx 虽然只差一个字母，但完全是两回事。doc 是老的二进制复合文档格式，没有公开的、稳定的纯前端解析方案。网上能找到的 doc 解析库要么年久失修，要么只支持读取纯文本，遇到带图片表格的文档基本废了。

我的建议很直接：不要在前端硬啃 doc。最合理的做法是后端做转换，先把 doc 转成 PDF，前端再复用 PDF 预览组件。转换工具可以用 LibreOffice 的命令行模式，服务端安装一次，以后所有 doc 文件都走这个通道。

如果系统没有服务端转换能力，前端能做的就是给出友好提示：当前格式暂不支持在线预览，请下载后查看。这比硬撑一个五秒钟白屏体验好得多。说到底，用户不会因为你不能预览而生气，但会因为点开一片空白而骂人。

6. Excel 预览：从 xlsx 解析到网页表格

6.1 SheetJS 的解析流程：从 ArrayBuffer 到 HTML

Excel 预览在办公系统里出现频率极高，日报、报表、数据汇总全是 xlsx。前端最常用的库是 SheetJS，它的老版本包名叫xlsx，社区版是免费的，核心能力是解析和生成电子表格。

npm install xlsx

import * as XLSX from 'xlsx'; async function previewExcel(url) { const res = await fetch(url); const arrayBuffer = await res.arrayBuffer(); const workbook = XLSX.read(arrayBuffer, { type: 'array' }); const firstSheetName = workbook.SheetNames[0]; const sheet = workbook.Sheets[firstSheetName]; // 方式一：直接转 HTML，快速展示 const html = XLSX.utils.sheet_to_html(sheet); document.getElementById('excelContainer').innerHTML = html; // 方式二：拿成 JSON 数据，自己渲染表格 const rows = XLSX.utils.sheet_to_json(sheet, { header: 1 }); }

XLSX.read会解析文件字节流，返回 workbook 对象，workbook.SheetNames是工作簿里所有 sheet 的名字，取第一个 sheet 通常就够了。sheet_to_html是最省事的做法，它能快速生成一个带基础样式的 HTML 表格，适合截图式预览；sheet_to_json则适合需要按业务逻辑处理数据的场景，比如拿到数据后再喂给表格组件。

如果你的预览需求只是“看数据”，sheet_to_html基本够用。但如果你要做的是“在页面上能编辑、能筛选”，那就别用 HTML 字符串，直接把sheet_to_json的结果交给专业表格组件，比如 vxe-table、AG Grid，这样功能更完整。

6.2 样式、合并单元格、公式的处理策略

SheetJS 社区版有一个众所周知的短板：读不到单元格的完整样式。你能拿到数据、类型、公式，但拿不到字体颜色、背景色、边框这些视觉信息。所以sheet_to_html输出的样式非常简陋，基本只有表头和边框，跟本地 Excel 打开完全是两个观感。

这里要看实际场景。如果业务方只是要快速看数据，简陋一点没关系，用户能接受；如果业务方要完全还原样式，那 SheetJS 社区版就不够用了，需要走付费版或换成 exceljs，或者干脆服务端把 Excel 转成 PDF 再预览。我的排序通常是：数据重要优先 SheetJS，样式重要优先转换方案。

合并单元格方面，SheetJS 会把合并信息放在sheet['!merges']数组里。用sheet_to_html时它已经帮你处理了合并逻辑，不用手工调；但如果你用sheet_to_json自己渲染表格，就得遍历!merges，给对应的 td 加rowSpan和colSpan，这块很容易漏，一漏整个表格就错位了。

公式的处理上，SheetJS 解析出来的cell.f是公式字符串，cell.v是当前计算值。社区版默认读取文件里缓存的值，所以大多数场景下直接展示v就行。但如果你对公式进行了修改并重新计算，社区版在部分场景下可能算不准，这点要留意。

6.3 大数据量表格的分页/虚拟滚动

Excel 动不动就是几万行数据，前端拿到之后直接渲染是灾难。我见过一个线上事故，用户上传了一个 8 万行的 Excel，页面直接用表格组件渲染，浏览器卡死了，后面一直流传这个功能是坏的。

我的实践经验是三层防线。第一层，预览时限制行数，比如只展示前 1000 行，超过部分在底部提示“数据量过大，仅预览部分内容”；第二层，如果确实要看全部数据，让用户切到下载，别在浏览器里硬扛；第三层，如果产品非要在线看全量数据，那就必须上虚拟滚动表格组件，比如 vxe-table 的虚拟滚动模式，它能保证页面上只渲染可视区域的 DOM，这样几万行也能流畅滚动。

服务端最好也配合做一道，比如给预览接口加startRow和endRow参数，前端需要多少拉多少。有人会觉得纯前端解析本地文件不需要服务端分页，但 xlsx 文件从接口拉回来以后，还是可以自己按行切片渲染的，不一定要整个 sheet 一次性渲染成 DOM。

7. PPT 预览：这条路能走，但期望值要摆正

7.1 pptxjs / pptx2html 的现状

PPT 是办公预览里最难啃的一块。纯前端解析 PPT 的原理是解压 pptx 的 ZIP 包，解析 slide 的 XML，再把文字、图片、形状重新排列到页面 DOM 里。这听起来可行，但 PPT 的版式复杂度高得吓人，母版、占位符、渐变色、动画、组合形状、SmartArt 随便来一个，开源库就顶不住。

社区里能搜到的方案主要有pptxjs和pptx2html，但它们的定位更像 demo 级别的解析器，简单幻灯片还能看，复杂 PPT 直接版式错乱。把这样的预览组件放到生产环境，用户传上来一个带母版和动画的课件，渲染出来字体不对、位置漂移，体验非常差。

所以我的态度很明确：PPT 预览的纯前端方案只适合做功能验证，不适合做正式交付。如果有人坚持要纯前端，你先问他三个问题：要不要还原动画？要不要还原母版？要不要兼容所有上传文件？如果有一个要，纯前端路线就得放弃。

7.2 更稳妥的路线：服务端转 PDF 或图片

PPT 预览最稳、也是我实际项目里最终采用的路线，是服务端将 pptx 转成 PDF 或者图片，前端再复用 PDF 预览能力。

服务端处理我推荐 LibreOffice，支持 headless 模式，转换命令大致是这样：

libreoffice --headless --convert-to pdf --outdir /output/path /input/path/demo.pptx

转换完成后，前端拿到的不再是 pptx 文件，而是一个 PDF 地址，直接交给第 4 章写好的 PDF 预览组件就完事了。这么做有几个附带好处：一是移动端体验也统一了，PDF 在手机上的缩放阅读本来就比一个不可控的 HTML 排版好得多；二是文件安全更好管控，PDF 是最终产物，原始 PPT 可以限制下载权限；三是可以做缓存，同一个 PPT 转换一次后，后续预览直接读缓存，性能非常好。

如果需要缩略图式的课件预览，比如在线教育平台的章节列表要显示每页的样子，也可以让服务端把每页转成 PNG 图片，前端做缩略图和翻页展示。这样比 PDF 更轻量，但实现成本高一些，需要服务端维护图片生成和存储。

7.3 一个“前端为主、服务端兜底”的整合思路

在 PPT 这个模块上，我最后采用的是一个前端和服务端配合的分层方案。上传 PPT 的同时，服务端异步把文件转成 PDF；前端预览时先判断有没有转换产物，有就展示 PDF，没有就提示“正在转换，请稍后刷新”，同时保留下载按钮。这样用户点开课件，绝大多数情况都能直接看到内容，少数转换失败的也能下载。

这套流程的好处是把复杂度隔离在了服务端，前端只管“有 PDF 就预览，没 PDF 就提示”。不再需要为 PPT 专门写一个渲染引擎，也不担心用户上传的某个奇葩文件把页面搞崩。如果你正在设计自己的预览中心，我强烈建议把 ppt 和 doc 这两类“硬骨头”都收敛到服务端转换通道，前端只需要做好降级体验就行。

8. 踩坑实录：三个月做了六个预览模块的总结

8.1 大文件与内存泄漏：objectURL 忘了 revoke 的代价

我在文章开头提到过缩略图列表把浏览器搞崩的案例，这里再展开说说。那是一个附件管理页面，每条附件记录对应一个图片缩略图，我们直接用URL.createObjectURL生成了缩略图地址，但漏了在合适时机调用URL.revokeObjectURL。用户滚动列表、切换目录，每次操作都生成新 URL，旧的却一直占着内存。半天下来，浏览器任务管理器里内存占用到了 2GB，页面开始卡顿，最后直接崩溃。

从那以后，我在团队里定了一个强制规范：所有用createObjectURL生成 URL 的地方，必须登记到一个统一管理函数里，页面销毁或者记录切换时统一释放。代码评审看到直接裸写createObjectURL的一律打回去。视频预览也是一样，不要同时给多个 video 元素创建 objectURL，用哪个就创建哪个，换源前先清掉旧的。

8.2 跨域、沙箱与安全：iframe 不是随便嵌的

如果把第三方 PDF 地址直接塞进 iframe，很容易遇到跨域问题。有些浏览器的策略行为不同，跨域 PDF 在 iframe 里可能直接显示不出来，或者只显示一个下载按钮。这时候前端要么换 pdf.js 自己拉文件渲染，要么让服务端做代理转发，把文件流转换成同源地址再预览。我通常优先 pdf.js，因为代理转发会占用服务端带宽。

安全方面也有两个必踩的坑。第一个是渲染不可信文件转换出来的 HTML 时忘记消毒，Word、Excel 解析库生成的 HTML 里可能带着脚本标签或者事件属性，直接插进页面就有 XSS 风险。我在这件事上吃过亏，后来所有innerHTML赋值之前都过一遍 DOMPurify。第二个是 iframe 嵌入外部资源时没有限制权限，可以用sandbox属性做隔离：

<iframe :src="previewUrl" sandbox="allow-scripts allow-same-origin" ></iframe>

需要哪个权限就显式加哪个，不要图省事全放开，更不要把无关的allow-top-navigation这类权限带进来。

8.3 常见问题速查表

最后把三个多月里积累的问题整理成一张速查表，放着以后排查用：

8.4 一点个人心得

回到最开始那句话，前端文件预览本质上是“用最合适的手段，帮用户低成本获取文件内容”。别追求所有格式都 100% 还原，那是 Office 产品要解决的问题，不是预览组件要解决的问题。判断标准应该是：典型文件能打开、关键内容能看清、异常情况有提示、实在不行能下载。这四条做到，业务方已经很满意了。

还有一个工程化建议，把各种预览能力封装成统一的<FilePreview>组件，对外只暴露file和type两个属性和可控的宽高，内部按文件类型分发到不同的实现。这样新增一种格式时，只改组件内部，业务方代码一行不用动，后边接各种业务系统会省非常多事。最后，不管预览方案选得多好，都别忘了在界面角落里放一个下载按钮——线上预览永远只能接近本地打开，但下载永远是最可靠的兜底。