1. 先搞懂：OFD和PDF的"家底"差别在哪
1.1 OFD内部到底装了什么
我第一次接到OFD预览需求的时候，第一反应是去查有没有像pdf.js那样成熟的渲染方案，结果搜了一圈发现社区方案屈指可数，这才意识到问题出在格式本身。
OFD（Open Fixed-Layout Document）是国内版式文档格式标准（GB/T 33190-2016）定义的文件格式，主要用在电子发票、电子证照、政务审批、金融回单这些场景。它和PDF最大的共同点是"版式固定"——不管在什么设备上打开，排版都不变。但它和PDF有个根本性的区别：OFD本质上是一个ZIP压缩包。
解压一个常见的OFD文件，你会看到这样的结构：
├── OFD.xml // 入口文件，声明文档基本信息和根节点 ├── Doc_0/ │ ├── Document.xml // 文档级描述，包含页面分块索引 │ ├── Pages/ │ │ ├── Page_1/ │ │ │ └── Content.xml // 第一页的矢量绘制指令 │ │ ├── Page_2/ │ │ │ └── Content.xml │ │ └── ... │ ├── PublicRes/ // 公共资源：字体、图片、颜色空间 │ └── DocumentRes/ // 文档级资源引用 └── ...每一页的Content.xml里面记录的是矢量绘图指令，可以理解为"用路径描述文字和图形"，和PDF内部的内容流类似，里面包含文字的排版位置、字体的引用、图形绘制指令、图片的引用与变换矩阵等信息。
理解这个结构对选型特别重要，因为这意味着前端渲染OFD，本质上要做的事情是：解析ZIP包里的XML描述，再把这些矢量指令翻译成浏览器能画出来的东西（Canvas或SVG）。
1.2 为什么浏览器不能直接打开OFD
浏览器原生能直接打开PDF，是因为各浏览器内核（或Chrome内置的PDF查看器）自带了完整的PDF渲染引擎。PDF从1993年发布到现在已经将近三十年，生态非常成熟，围绕它诞生了pdf.js、PDFium等一系列开源渲染方案。
OFD则完全不同。它出现得晚，应用范围又主要集中在国内政务和公共服务领域，浏览器厂商没有任何动力去内置OFD解析能力。换句话说，你在Chrome地址栏输入一个OFD文件的路径，浏览器只会把它当作普通文件下载下来，而不是展示内容。
这就带来一个连锁反应：前端要预览OFD，只能走"自己构建渲染管线"这条路。你不仅要把OFD解压、解析XML，还得处理字体加载、坐标变换、图形绘制这些底层问题。
1.3 这个"家底"决定了技术路线
ZIP容器 + XML + 矢量指令集，意味着前端方案有两种大方向：
- 完全自研解析器：从ZIP解压开始，自己写XML解析、指令翻译、渲染器。工作量极大，不现实。
- 复用社区已有的解析内核：站在别人的肩膀上，把精力放在业务适配和体验优化上。这是绝大多数项目的选择。
所以接下来要解决的问题就是：社区里有哪些"肩膀"可以站，它们各自有什么脾气。这就是下一节要展开的方案选型。
2. 方案选型：四张牌怎么打才稳
2.1 ofd.js：社区主力，能扛标准OFD
目前GitHub上最活跃、使用范围最广的OFD前端渲染方案是ofd.js。它的底层逻辑是从pdf.js移植改造而来的：保留pdf.js的插件架构和渲染管线的框架，把PDF文档的解析部分替换成OFD的XML解析器，渲染输出部分则直接沿用Canvas渲染的方式。
ofd.js的用法非常接近pdf.js，核心就三个步骤：
// 1. 初始化，传入进度条容器 const ofd = window.ofd; ofd.init({ processBar: document.getElementById('progressBar') }); // 2. 解析文档，获取页数等信息 ofd.parse({ url: 'https://example.com/file.ofd', success(res) { const numPages = res.numPages; // 拿到页数后，一页一页渲染 renderPage(1); }, fail(err) { console.error('解析失败', err); } }); // 3. 渲染指定页 function renderPage(pageNum) { ofd.render({ url: 'https://example.com/file.ofd', pageNum, div: document.getElementById('pageContainer'), success() { console.log('第' + pageNum + '页渲染完成'); }, fail(err) { console.error('渲染失败', err); } }); }ofd.js的优点是能处理绝大多数符合国标规范的OFD文件，解析器经过社区修补，对字体嵌入、图片引用、路径绘制这些基础场景覆盖得相对完整。缺点是它本身没有太多体验层面的东西——没有缩略图、没有缩放控件、没有文本选择，一切交互都需要自己封装。
2.2 lofd：轻量级轮子，适合定制
如果你是后端转前端那种"必须把细节握在手里"的开发者，可以看看lofd。这个库的思路和ofd.js不一样，它只负责"把OFD页面解析成可操作的内部结构"，而把渲染层完全开放给你。你可以把解析出来的矢量指令转成Canvas绘制、SVG路径，甚至可以转成HTML元素。
lofd的代码量更小，没有pdf.js那种厚重的插件体系，学习和修改成本低。但代价是功能密度也低，复杂的OFD文件（多层嵌套的裁剪区域、复杂的渐变、特殊字体引用）处理起来往往需要自己补代码。
我的看法是：如果项目里的OFD文件来源单一、结构规范（比如都是自家系统导出的电子发票），lofd是个好选择。如果文件来源五花八门（政务平台下载、第三方系统推送、用户手工上传），优先选ofd.js，它的兼容性兜底能力更强。
2.3 后端转换：把OFD"翻译"成浏览器认识的格式
这段时间我也调研过永中、福昕这些厂商提供的文档转换服务，思路是后端把OFD转成PDF或者图片，前端再用现成的PDF预览方案（pdf.js）或者直接展示图片。
这个方案的优势非常明显：前端代码量最小，兼容性最好，几乎不会踩渲染的坑。尤其是"转成PDF"这条路，市面上成熟的PDF预览组件太多了，交互、体验、移动端适配都有人替你趟过。
但它的劣势也很突出：
- 需要额外的服务端成本，而且转换通常有排队时间，用户等待体验差。
- 转换质量不可控，复杂的OFD文件转出来的PDF可能出现字体乱码、图层错位。
- 如果业务要求"只能在线预览、不允许下载"，转成PDF后文件被下载的风险反而更高，因为浏览器对PDF的下载支持太友好了。
所以后端转换更适合"内部系统、文件规范、可接受秒级延迟"的场景，不太适合直接暴露给外部用户的公共服务。
2.4 商业SDK：钱能解决大多数兼容性问题
商业SDK（比如某些办公套件厂商提供的Web预览组件）在兼容性上确实比开源方案强一大截，对加密OFD、带电子签章、复杂的版式文件的还原度都很高。如果你有预算，而且对预览保真度有硬性要求（比如法律文书、审计底稿），商业SDK是值得考虑的方向。
不过商业SDK的集成方式通常是加载一个大体积的JS文件或者私有协议脚本，对CSP（内容安全策略）严格的项目不太友好，而且授权费是按项目或者按并发数算的，规模大了是一笔不小的开支。
2.5 我最终的选择和理由
结合我手头的项目背景——Vue3技术栈、文件主要来自用户上传、部署环境无法保证连通外部转换服务——我最后选了ofd.js + 自己封装组件的路线。前端独立完成解析和渲染，不依赖后端，部署简单，对用户来说上传文件后立刻就能看到内容，体验也最顺。
接下来就是这次实践的重头戏：如何把ofd.js这个"偏原生"的库，磨合进Vue3的组件体系里。
3. Vue3组件封装：从"能跑"到"好用"
3.1 全局引入与npm包的坑
ofd.js发布在npm上，包名就是ofd，但你要有心理准备：它不是一个标准ESModule模块，没有export default这种导出方式。直接import ofd from 'ofd'然后调用ofd.init()，大概率会报ofd is undefined。
原因是ofd.js的构建产物是UMD格式，导出的全局对象挂在window.ofd上。在Vue3项目里有两种稳妥的引入方式：
第一种，在index.html里用script标签直接引入：
<script src="/ofd.min.js"></script>然后把ofd.min.js放到public目录下。这种方式最省心，不受构建工具影响，页面加载时全局变量就位了。
第二种，在组件里动态加载：
// 动态加载UMD脚本 function loadScript(src) { return new Promise((resolve, reject) => { const script = document.createElement('script'); script.src = src; script.onload = resolve; script.onerror = reject; document.head.appendChild(script); }); } // 使用 await loadScript('/ofd.min.js'); const ofd = window.ofd;我推荐第二种，按需加载，不会拖慢首屏。但要注意：window.ofd不是响应式对象，不要把它放进reactive或ref里，直接用一个普通的模块级变量持有它就好了。
3.2 组件完整实现：解析、渲染、缩放、翻页
下面是我在实际项目中封装的OfdPreview.vue，核心逻辑注释都在，你可以直接拿去改：
<template> <div class="ofd-preview"> <!-- 顶部工具栏 --> <div class="ofd-toolbar"> <button :disabled="currentPage <= 1" @click="prevPage">上一页</button> <span>{{ currentPage }} / {{ totalPages }}</span> <button :disabled="currentPage >= totalPages" @click="nextPage">下一页</button> <select v-model.number="scale" title="缩放比例"> <option :value="0.5">50%</option> <option :value="0.75">75%</option> <option :value="1">100%</option> <option :value="1.25">125%</option> <option :value="1.5">150%</option> </select> </div> <!-- 进度条区域：ofd.js 会往这个容器里插入进度节点 --> <div v-if="loading" ref="progressRef" class="ofd-progress"></div> <!-- 渲染容器 --> <div ref="containerRef" class="ofd-page-container"> <canvas ref="canvasRef"></canvas> </div> <div v-if="errorMessage" class="ofd-error">{{ errorMessage }}</div> </div> </template> <script setup> import { ref, watch, onMounted, onBeforeUnmount } from 'vue'; const props = defineProps({ // OFD文件的访问地址，支持 http(s) 或 blob url url: { type: String, required: true }, // 初始缩放比例，默认1 initialScale: { type: Number, default: 1 } }); const emit = defineEmits(['load', 'error']); const containerRef = ref(null); const progressRef = ref(null); const canvasRef = ref(null); let ofdInstance = null; // 持有 window.ofd 的引用 let parsedDoc = null; // 解析后得到的文档信息 let objectUrl = null; // 用于存手工创建的blob url const currentPage = ref(1); const totalPages = ref(0); const scale = ref(props.initialScale); const loading = ref(false); const errorMessage = ref(''); // 从远程加载ofd.js的UMD脚本 async function ensureOfdLoaded() { if (window.ofd) return window.ofd; await new Promise((resolve, reject) => { const script = document.createElement('script'); script.src = '/ofd.min.js'; script.onload = resolve; script.onerror = reject; document.head.appendChild(script); }); return window.ofd; } // 根据容器宽度和页面比例，计算canvas的实际像素尺寸（乘以devicePixelRatio） function resizeCanvasToPage(pageWidth, pageHeight) { const container = containerRef.value; const canvas = canvasRef.value; if (!container || !canvas) return; const dpr = Math.min(window.devicePixelRatio || 1, 2); // 限制最大2倍，防止大屏上内存爆炸 const maxWidth = container.clientWidth; // 以宽度为基准，等比缩放高度 const viewWidth = maxWidth * scale.value; const viewHeight = viewWidth * (pageHeight / pageWidth); canvas.width = Math.floor(viewWidth * dpr); canvas.height = Math.floor(viewHeight * dpr); canvas.style.width = viewWidth + 'px'; canvas.style.height = viewHeight + 'px'; } function renderPage(pageNum) { if (!ofdInstance || !parsedDoc) return; const canvas = canvasRef.value; if (!canvas) return; const page = parsedDoc.pages[pageNum - 1]; if (!page) return; resizeCanvasToPage(page.pageWidth, page.pageHeight); loading.value = true; ofdInstance.render({ url: props.url, pageNum, div: canvas, success: () => { loading.value = false; emit('load', { pageNum }); }, fail: (err) => { loading.value = false; errorMessage.value = `第${pageNum}页渲染失败`; emit('error', err); } }); } function prevPage() { if (currentPage.value <= 1) return; currentPage.value--; renderPage(currentPage.value); } function nextPage() { if (currentPage.value >= totalPages.value) return; currentPage.value++; renderPage(currentPage.value); } async function init() { if (!props.url) return; errorMessage.value = ''; try { ofdInstance = await ensureOfdLoaded(); ofdInstance.init({ processBar: progressRef.value }); loading.value = true; ofdInstance.parse({ url: props.url, success: (data) => { parsedDoc = data; totalPages.value = data.numPages || 0; loading.value = false; if (totalPages.value > 0) { currentPage.value = 1; renderPage(1); } }, fail: (err) => { loading.value = false; errorMessage.value = 'OFD解析失败，请确认文件格式'; emit('error', err); } }); } catch (err) { loading.value = false; errorMessage.value = 'OFD渲染引擎加载失败'; emit('error', err); } } watch(() => props.url, () => { currentPage.value = 1; init(); }); watch(scale, () => { // 缩放比例变化时，重新渲染当前页 if (parsedDoc) { renderPage(currentPage.value); } }); onMounted(init); onBeforeUnmount(() => { // 如果这个url是我们自己通过createObjectURL创建的，卸载时回收 if (objectUrl && props.url.startsWith('blob:')) { URL.revokeObjectURL(objectUrl); objectUrl = null; } }); defineExpose({ nextPage, prevPage }); </script>3.3 组件设计中的几个关键决策
为什么把进度条容器单独用一个ref传进去？ofd.js的init方法接受一个processBar参数，解析文件时它会往这个容器里插入进度节点。如果你不传，就完全没有加载反馈，大文件解析时用户会以为页面卡死了。所以这个进度条容器必须存在，而且要在init之前就渲染到DOM上。
为什么使用canvas而不是div容器？ofd.js的render方法支持传一个div，也支持传canvas。传div时内部会动态创建canvas并塞进div里，好处是可以省去手动管理canvas尺寸的麻烦。但我选择自己控制canvas，原因是我想精确控制devicePixelRatio，避免高分屏上渲染出来发虚。这个问题在后面的"实战排雷"里还会细说。
为什么把scale监听后直接重新渲染整页？缩放最直接的实现方式就是改canvas的CSS尺寸再重新渲染。注意ofd.js渲染是直接把内容画到canvas上，不是PDF那种"画矢量、看缩放"的模型。所以改尺寸后必须重绘，否则画布内容会因为缩放模式不一致而模糊或拉伸。
3.4 Vue3组合式API的适配技巧
在封装这个组件时，有两个Vue3特有的坑值得提一下：
不要在reactive里放非响应式对象。上面代码里我用的是普通变量let ofdInstance = null来持有window.ofd，而不是reactive({ ofd: null })。因为ofd.js内部有大量对象引用和回调，放进reactive里纯属增加代理开销，还可能因为Proxy代理导致内部逻辑异常。
组件卸载时一定要清理Blob URL。如果调用方传入的是URL.createObjectURL(file)生成的blob url，组件卸载时应该主动URL.revokeObjectURL。这个操作平时不写也不报错，但在反复上传、预览文件的应用里会累积内存泄漏。上面的onBeforeUnmount里已经处理了。
4. 原生JS里的即时预览：脱离框架也能撑起功能
4.1 一个完整的原生页面长什么样
如果项目不是Vue3，或者你只是想在简单的工具页面上快速接入OFD预览，完全不需要引入框架，原生JS就够了。我做过一个不依赖任何框架的OFD预览工具页，功能包含：本地文件选择、进度条、翻页、缩放，整个实现不到200行。
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>OFD本地预览工具</title> <style> body { font-family: sans-serif; max-width: 900px; margin: 40px auto; } .toolbar { display: flex; align-items: center; gap: 12px; margin-bottom: 16px; flex-wrap: wrap; } .progress { width: 100%; height: 6px; background: #eee; border-radius: 3px; margin-bottom: 12px; overflow: hidden; } .page-container { border: 1px solid #ddd; min-height: 200px; display: flex; justify-content: center; background: #f5f5f5; padding: 16px; } .page-container canvas { box-shadow: 0 2px 8px rgba(0, 0, 0, 0.15); background: #fff; } </style> </head> <body> <h1>OFD 文件预览</h1> <div class="toolbar"> <input type="file" id="fileInput" accept=".ofd,application/octet-stream"> <button id="prevBtn" disabled>上一页</button> <span id="pageInfo">0 / 0</span> <button id="nextBtn" disabled>下一页</button> <select id="scaleSelect"> <option value="0.5">50%</option> <option value="1" selected>100%</option> <option value="1.5">150%</option> </select> </div> <div id="progress" class="progress"></div> <div id="pageContainer" class="page-container"></div> <script src="./ofd.min.js"></script> <script> let currentPage = 1; let totalPages = 0; let currentBlobUrl = ''; const ofd = window.ofd; const fileInput = document.getElementById('fileInput'); const prevBtn = document.getElementById('prevBtn'); const nextBtn = document.getElementById('nextBtn'); const pageInfo = document.getElementById('pageInfo'); const scaleSelect = document.getElementById('scaleSelect'); const container = document.getElementById('pageContainer'); // 选择本地文件后，通过Blob URL交给ofd.js解析 fileInput.addEventListener('change', function (e) { const file = e.target.files[0]; if (!file) return; // 如果之前有blob url，先释放掉 if (currentBlobUrl) { URL.revokeObjectURL(currentBlobUrl); } currentBlobUrl = URL.createObjectURL(file); loadOfd(currentBlobUrl); }); function loadOfd(url) { ofd.init({ processBar: document.getElementById('progress') }); ofd.parse({ url, success(res) { totalPages = res.numPages; currentPage = 1; pageInfo.textContent = `${currentPage} / ${totalPages}`; prevBtn.disabled = true; nextBtn.disabled = totalPages <= 1; renderPage(currentPage); }, fail(err) { alert('解析OFD文件失败'); console.error(err); } }); } function renderPage(pageNum) { // 渲染前先清空容器，双保险 container.innerHTML = ''; const canvas = document.createElement('canvas'); container.appendChild(canvas); const scale = parseFloat(scaleSelect.value); const baseWidth = container.clientWidth - 32; // 先设置canvas显示尺寸，等ofd.js渲染完成后它会填充实际内容 canvas.style.width = baseWidth * scale + 'px'; canvas.style.height = baseWidth * scale * 1.414 + 'px'; // A4比例兜底 ofd.render({ url: currentBlobUrl, pageNum, div: canvas, success() { // 渲染完成后根据实际页面比例修正高度 // 实际项目中这里可以读页面宽高比重新设置尺寸 }, fail(err) { console.error('渲染失败', err); } }); pageInfo.textContent = `${pageNum} / ${totalPages}`; prevBtn.disabled = pageNum <= 1; nextBtn.disabled = pageNum >= totalPages; } prevBtn.addEventListener('click', () => { if (currentPage > 1) { currentPage--; renderPage(currentPage); } }); nextBtn.addEventListener('click', () => { if (currentPage < totalPages) { currentPage++; renderPage(currentPage); } }); scaleSelect.addEventListener('change', () => { if (totalPages > 0) { renderPage(currentPage); } }); </script> </body> </html>4.2 本地文件预览的关键：Blob URL
原生方案里最核心的一个技巧是用URL.createObjectURL(file)生成临时访问地址。这一步让本地文件拥有了一个可以被ofd.parse和ofd.render正常请求的URL，规避了"浏览器不允许网页直接读取本地文件内容"的限制。
有两个容易被忽略的点：
Blob URL要及时回收。每次选择新文件后，先把上一次生成的currentBlobUrl用URL.revokeObjectURL释放掉，否则每次选文件都产生一个新的Blob URL，内存只增不减。这在长时间使用工具页时尤其明显。
不要直接用FileReader读ArrayBuffer喂给ofd.js。虽然OFD本质是ZIP，理论上可以手动解析，但ofd.js对外公开的API是基于URL的，它内部会自己发请求拉取文件。你如果非要走ArrayBuffer路线，就得自己解析ZIP、自己找XML、自己写渲染逻辑——绕了一大圈，得不偿失。
4.3 无框架场景下的状态管理
原生JS写起来虽然自由，但状态管理全靠手动同步。上面的代码里，currentPage、totalPages、currentBlobUrl这些变量分散在几个函数里，一旦功能扩展（页数跳转、文档切换、错误重试），代码会迅速变乱。
我的建议是：如果预览功能只是工具页里的一个小模块，原生写法完全够用。如果这玩意儿会在多个页面复用，还是乖乖封装成组件或者类。我实际项目里就把原生版本写成了OFDPreview类，在外层做了一层简单的封装，内部维护同一套状态，对外暴露load(url)、destroy()、prev()、next()方法。这样既保留了原生JS的轻量，又不用跳回框架的重模式。
5. 实战排雷：最容易翻车的几个细节
5.1 大文件卡顿：indexedDB缓存和懒加载
OFD文件动辄几十MB，一次解析几百页，如果全部预渲染，浏览器基本就会卡成幻灯片。实际项目里我踩过这个坑：测试机上解一个120页、30MB的OFD，首屏等了将近十秒，用户直接打投诉电话。
最终的优化组合是懒渲染 + 邻近预渲染：
- 只渲染当前页面，翻页时才渲染下一页。
- 在翻页后的空闲时间（
requestIdleCallback），预渲染当前页的前后各一页，把画好的canvas缓存进内存。 - 如果项目对首屏速度要求高，还可以先把前五页预渲染，后续页面按需处理。
- 对于重复打开同一文件的情况，可以用IndexedDB缓存解析结果，避免二次打开时重新下载解压。不过ofd.js本身不支持缓存，得自己在业务层做文件级别的缓存。
这些优化听起来简单，但效果非常明显。把预渲染范围控制在前后一页后，我的测试机从十秒降到两秒内可交互。
5.2 文字发虚：canvas必须乘以devicePixelRatio
如果你直接用CSS把canvas撑到容器宽度，然后用ofd.js渲染，会发现文字边缘明显发虚，尤其在高分屏上惨不忍睹。
原因很简单：CSS像素和物理像素不是一对一的关系。MacBook Pro的Retina屏devicePixelRatio是2，意味着一个CSS像素对应2x2个物理像素。如果你把canvas的width属性设为CSS宽度本身，canvas内部的实际绘图分辨率只有CSS像素量级，浏览器放大到物理像素时必然模糊。
正确的做法在Vue组件代码里已经展示过了：
const dpr = Math.min(window.devicePixelRatio || 1, 2); canvas.width = viewWidth * dpr; canvas.height = viewHeight * dpr; canvas.style.width = viewWidth + 'px'; canvas.style.height = viewHeight + 'px';为什么要把dpr限制到2？因为devicePixelRatio是3甚至更高的设备（比如某些安卓旗舰机）上，如果完全按3倍物理像素渲染，canvas内存占用会膨胀接近9倍，遇到大页面很容易触顶内存。限制到2既能保证视觉清晰度，又能控制内存开销，这是性能和画质之间的一个合理平衡点。
5.3 字体缺失：部分OFD文件渲染出来是方块
这是OFD预览里最隐蔽的坑。OFD文件内部引用字体时，有两种情况：引用系统字体（宋体、黑体、思源之类）和嵌入字体文件（otf/ttf）。如果文档引用了一个本机没有安装的字体，渲染出来的文字就会变成占位方块，而且ofd.js不会报错，看起来像是渲染成功、实际内容废了。
排查的路径是这样的：
- 先用
winrar或7-zip解压OFD文件，打开Doc_0/DocumentRes/目录，检查里面有没有.ttf或.otf文件。 - 如果有嵌入字体，说明渲染引擎理论上能读到，但ofd.js对字体解析的支持可能有限。
- 如果只有字体名引用没有嵌入文件，说明这是引用系统字体，渲染时就依赖本机字体库。
应对方案有几个层次：
- 如果OFD文件是自家系统导出的，规约它嵌入字体，这是根治方案。
- 前端可以在页面加载时用
FontFaceAPI动态加载常用的候选字体（比如思源宋体、思源黑体），减少缺字概率。 - 如果字形缺失已经发生，一般只能退回"告知用户"的层面，或者走后端转换服务。
5.4 跨域与本地文件的权限边界
ofd.js的parse和render内部是通过fetch或者XMLHttpRequest去拉取文件流的，所以跨域问题绕不开。请求OFD文件的服务器必须返回正确的CORS头，否则浏览器会直接拦截响应，表现为"解析失败"。
本地File预览不受跨域限制，因为blob:URL和页面同源。但要注意：如果文件来自第三方系统的直链，且对方没开CORS，前端是没法直接预览的。这种情况要么让后端把文件内容拉回来再转成Blob传给前端，要么让后端配置CORS。
另外还有个细节：不要在组件的init阶段过早传递进度条容器。如果进度条容器还没挂载到DOM上，ofd.js拿到的processBar参数就是null，后续解析进度就没了反馈。Vue3里onMounted之后再调init是安全的，因为此时DOM已经渲染完毕。
5.5 多页面场景的URL切换竞态
如果一个预览区域需要支持"点击左侧列表 -> 加载不同OFD文件"的操作，而且用户点得很快，就会遇到竞态问题：上一次文件解析还没完成，新的解析请求已经发出，等那一次回调返回时，可能已经覆盖了当前页面的状态。
处理办法是在组件里加一个loadToken：
let loadToken = 0; function init(url) { const currentToken = ++loadToken; // ...异步解析与渲染 // 每一个回调里都检查 currentToken === loadToken }这样旧的请求即使回调回来了，也会因为token不匹配而被丢弃。这个技巧比"防抖"更彻底，因为它不是延迟请求，而是直接让过期的响应失效。
个人体会：什么时候该停下来评估方案
最后说点我自己的判断。OFD前端预览这个需求，技术本身不算难，难的是各种兼容性擦屁股。如果你接手一个类似的"预览某种稀罕格式文件"的需求，我建议先花半天时间回答这三个问题：
文件从哪里来？如果是自家系统产生的，你完全可以通过规范生成端逃掉很多渲染坑。比如生成时呼入字体，设置好页面尺寸，这比前端加十层兼容逻辑都有效。
业务对保真度的容忍度有多高？内部审批场景可能只需要"能看个大概"，这种场景开源方案完全够用。但如果是面向办事群众的公共服务，渲染效果差一点就可能引来投诉，这时候商业SDK或者后端转换的可靠性优势就体现出来了。
你的前端到底能不能扛住解析逻辑？OFD解析和渲染本质上是计算密集型任务，低端移动设备上解析一个几十MB的文件，性能和功耗都是一次考验。有条件的话，把解析放到Web Worker里会舒服很多，但这又增加了一层复杂度。
我在这个项目里把ofd.js、原生JS封装和Vue3组件三套东西都磨合了一遍，最大的收获是：不管踩了多少坑，方案选型时多花的时间永远是最值的。现在这套方案在项目里跑了大半年，线上几百家机构在用，每月预览量几十万次，稳定性基本可控——但每次版本迭代，我都会下意识提醒自己再去看看官方仓库有没有新提交、社区有没有新的替代方案。前端技术更迭快，一个方案只要还在被依赖，就值得被持续关注。
