写PDF预览功能的时候踩过不少坑这次把Vue3 PDF.js的完整接入过程整理出来。从环境配置到核心代码从中文乱码到性能优化把我实际开发中遇到并解决的问题都记录下来包括一些排查思路和避坑经验希望对正在做类似功能的朋友有帮助。1. 整体设计思路为什么选择pdf.js及功能规划1.1 pdf.js技术特性与选型分析PDF.js是Mozilla团队开源的一个PDF文档解析与渲染库它的核心能力是在浏览器端通过JavaScript和HTML5的Canvas技术实现PDF文件的解析和展示不需要安装任何第三方插件。我在实际项目里选用它主要看重几个方面解析能力足够准确对标准PDF格式的支持比较完善渲染效果清晰可以做到按矢量绘制而不是简单的图片展示社区活跃度高遇到问题能找到参考资料。在Vue3项目里集成PDF.js和之前Vue2时代最大的区别在于模块化方式和响应式系统的交互逻辑。PDF.js从3.x版本开始提供了ESM模块格式配合Vite构建工具可以做到按需引入这让打包体积得到了很好的控制。还有一点比较关键Vue3的Proxy响应式机制对PDF.js内部对象的处理方式天然更友好不像Vue2的Object.defineProperty那样容易在数据劫持上出问题。如果只是偶尔预览一个PDF文件也可以考虑用浏览器自带的iframe或者embed标签直接打开但它有几个明显的局限性浏览器自带预览的样式不可控不同浏览器表现不一致移动端兼容性差而且无法实现自定义的翻页、缩放、搜索功能。PDF.js则把整个渲染流程交给我们控制可以自由设计交互方式。我这次的目标是做一个功能比较完整的PDF预览组件包含文件加载与解析、多页渲染、缩放操作、页码跳转、旋转查看、文本复制选择、目录导航。其中多页渲染和缩放操作是重头戏很多兼容性问题都集中在这两个功能上。1.2 Vue3 Vite环境下pdf.js接入方式选型在Vite构建的Vue3项目中接入PDF.js有两条主流路线一条是直接通过npm安装pdfjs-dist包在组件里import使用另一条是使用vue-pdf-embed这类封装好的第三方组件。如果对功能要求简单、追求开发速度用封装组件当然更方便。但一旦涉及到特殊需求比如自定义工具栏、特定交互效果、性能调优封装组件的灵活度就不够了。我最终选择了直接使用pdfjs-dist原因有三个功能完全可控渲染流程每一步都是自己调用API出了bug知道从哪里排查体积更优化相比全量引入的封装组件只打包需要的模块学习价值高理解了底层API不管是后续换框架还是做深度定制都能快速上手。先看下基础安装命令npm install pdfjs-dist # 如果涉及本地文件预览还需要安装文件读取相关工具 npm install file-saver安装完成后检查版本确保和Vue3的兼容性。我这里当时安装的是3.11.174版本运行稳定没有出现Webpack构建时的那些兼容问题。高版本的4.x也测试过API变化不大但部分旧代码可能有调整生产环境建议锁定版本号避免意外更新引发兼容性问题。在Vite中如果需要用到node_modules里的worker文件需要在vite.config.js里配置optimizeDeps// vite.config.js import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], optimizeDeps: { include: [pdfjs-dist] } })这一步不是必须的但如果遇到开发环境下加载异常可以优先检查这里。2. 核心功能开发PDF加载解析与页面渲染2.1 Worker配置的三种方案及避坑建议PDF.js的解析过程默认在Worker线程中执行这样UI主线程不会被阻塞翻页时页面不会卡顿。Worker的配置是个很容易掉坑的地方我测试过三种方案分别说一下。第一种方案使用CDN地址配置Workerimport * as pdfjsLib from pdfjs-dist pdfjsLib.GlobalWorkerOptions.workerSrc https://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/pdf.worker.min.js这种方式最简单不用处理本地文件拷贝但需要联网。内网部署或者离线环境下会失效生产环境不太建议。第二种方案让Vite直接处理Worker文件import * as pdfjsLib from pdfjs-dist import workerUrl from pdfjs-dist/build/pdf.worker.min.js?url pdfjsLib.GlobalWorkerOptions.workerSrc workerUrl这个方式充分利用了Vite的?url后缀特性构建时会自动把worker文件复制到输出目录并生成正确的URL。我的项目用的就是这个方案开发和生产环境都很稳定。第三种方案使用new URL的方式pdfjsLib.GlobalWorkerOptions.workerSrc new URL( pdfjs-dist/build/pdf.worker.min.js, import.meta.url ).toString()这种方式也比较推荐new URL会在构建时被Vite识别并正确处理。设置完Worker后建议在浏览器开发者工具里验证一下是否生效打开Application/Sources面板能看到pdf.worker文件才算成功。如果Worker加载失败GET请求会报404任务会退回到主线程执行功能倒是能跑但页面会有明显的卡顿感。2.2 加载PDF文件并解析文档Worker配置完成后就可以开始加载PDF文件了。实际开发中常见的PDF来源有三种网络URL、本地文件、Base64数据流。それぞれ的处理方式略有不同。如果是网络URL可以直接传入getDocument方法async function loadPdf(url) { const loadingTask pdfjsLib.getDocument(url) const pdf await loadingTask.promise return pdf }如果是本地文件需要先把文件内容读取为ArrayBufferasync function loadPdfFromFile(file) { const fileReader new FileReader() const fileData await new Promise((resolve, reject) { fileReader.onload () resolve(fileReader.result) fileReader.onerror reject fileReader.readAsArrayBuffer(file) }) const loadingTask pdfjsLib.getDocument({ data: fileData }) const pdf await loadingTask.promise return pdf }如果是Base64数据需要先做一步转换function base64ToUint8Array(base64) { const raw atob(base64) const uint8Array new Uint8Array(raw.length) for (let i 0; i raw.length; i) { uint8Array[i] raw.charCodeAt(i) } return uint8Array } async function loadPdfFromBase64(base64String) { const loadingTask pdfjsLib.getDocument({ data: base64ToUint8Array(base64String) }) const pdf await loadingTask.promise return pdf }拿到pdf对象后可以读取文档的基本信息比如页数、标题、作者等const pageCount pdf.numPages const metadata await pdf.getMetadata() console.log(页数:, pageCount) console.log(标题:, metadata.info?.Title)这里有个容易出错的地方getDocument返回的是PDFDocumentLoadingTask对象页面的渲染一定要等待loadingTask.promiseresolve之后才能进行。我见过不少新手同学忘了await直接拿loadingTask去调numPages结果自然是undefined。2.3 页面渲染详解从PDFPage到Canvas加载完成后核心工作就是把每一页渲染到Canvas上。PDF.js的渲染API设计得比较清晰但不注意细节的话很容易出现渲染空白、模糊或者错位的问题。来看完整的渲染过程async function renderPage(pdf, pageNum, canvas, scale 1.5) { try { // 获取页面对象 const page await pdf.getPage(pageNum) // 计算视口尺寸 const viewport page.getViewport({ scale }) // 设置canvas的物理像素尺寸注意不是CSS尺寸 const context canvas.getContext(2d) canvas.width viewport.width canvas.height viewport.height // 渲染 const renderContext { canvasContext: context, viewport: viewport } await page.render(renderContext).promise } catch (error) { console.error(页面渲染失败:, error) } }关于getViewport({ scale })这个方法它返回的viewport对象包含了viewport.width、viewport.height、scale等信息。这里scale值直接决定渲染清晰度我们一般把它理解为像素比更准确。显示屏幕通常都是高清屏devicePixelRatio是2如果直接用scale 1渲染屏幕上看起来就是模糊的。实际使用时我建议把缩放和清晰度分开处理。清晰度通过devicePixelRatio来控制用户缩放通过独立的scale来控制function calculateViewportScale(baseScale 1) { const dpr window.devicePixelRatio || 1 return baseScale * dpr } // 渲染时 const viewport page.getViewport({ scale: calculateViewportScale(currentScale) }) canvas.width viewport.width canvas.height viewport.height还有一个很影响体验的细节canvas设置尺寸后会把画布内容清空所以在重新渲染前如果需要保留旧内容可以先把旧内容保存成图片// 渲染前保存当前状态 const previousDataUrl canvas.toDataURL() // 修改尺寸 canvas.width newWidth canvas.height newHeight // 如果需要先绘制旧内容作为背景 const img new Image() img.src previousDataUrl context.drawImage(img, 0, 0)2.4 多页PDF的遍历渲染策略一个PDF可能有很多页渲染策略需要考虑性能。我调试过两种方案一种是按页循环逐页渲染一种是用Promise.all并发渲染所有页。两种都有问题要处理。先看按页循环的版本async function renderAllPages(pdf, container) { for (let i 1; i pdf.numPages; i) { const page await pdf.getPage(i) const viewport page.getViewport({ scale: 1.5 }) const canvas document.createElement(canvas) canvas.width viewport.width canvas.height viewport.height canvas.style.width 100% canvas.style.marginBottom 16px container.appendChild(canvas) await page.render({ canvasContext: canvas.getContext(2d), viewport }).promise } }这种方案的问题是逐页等待如果当前页渲染慢后面的页都会被阻塞。但好处是内存占用低每次只处理一页。Promise.all并发方案速度快很多但所有页面同时渲染如果PDF页数多内存占用会迅速飙升低端设备可能直接崩溃。折中的方案是分组并发每次并发渲染3-4页async function renderPagesInBatch(pdf, startPage, batchSize 3) { const endPage Math.min(startPage batchSize - 1, pdf.numPages) const tasks [] for (let i startPage; i endPage; i) { tasks.push(renderPageToCanvas(pdf, i)) } const canvases await Promise.all(tasks) return canvases }这里我的经验是如果只是做PDF预览功能优先使用按需渲染的方式也就是只渲染当前显示的那一页和前后各一页。等用户翻页的时候再加载新的页。如果是要一次性展示全部内容类似那种文档流式的浏览分组并发的方案体验会更好。我的项目采用的是一次性渲染全部页到页面流式展示因为页数通常不多而且可以在页面加载后立即看到全部内容。页面渲染完要记得释放资源特别是长时间使用的场景function cleanupPage(page) { if (page) { page.cleanup() // 释放渲染时占用的临时资源 } }如果页面对象是通过pdf.getPage()获取的它不会被自动回收。多次翻页操作后不清理的话内存会缓慢增长。这个在开发工具里看Memory面板的曲线图就可以验证。3. 功能增强缩放、旋转与文本选择3.1 缩放功能的高质量实现缩放在PDF预览里属于高频操作用户经常会需要放大看细节或者缩小看整体。PDF.js的缩放不是简单的CSS缩放而是要重新调整viewport大小然后重新渲染canvas。我封装了一个缩放控制方法const zoomLevels [0.5, 0.75, 1, 1.25, 1.5, 2, 3, 4] let currentZoomIndex 2 // 默认100% function zoomIn() { if (currentZoomIndex zoomLevels.length - 1) { currentZoomIndex reRenderAllPages(zoomLevels[currentZoomIndex]) } } function zoomOut() { if (currentZoomIndex 0) { currentZoomIndex-- reRenderAllPages(zoomLevels[currentZoomIndex]) } } async function reRenderAllPages(scale) { const pdf getCurrentPdf() // 保存的pdf对象 const container document.getElementById(pdf-container) container.innerHTML for (let i 1; i pdf.numPages; i) { await renderPage(pdf, i, createCanvasElement(scale), scale) } }这种整页全部重新渲染的方式在小页数PDF上表现很好。但如果PDF页数很多每次缩放都全量重新渲染体验会比较卡。后来我优化成只重新渲染当前可视区域内的页面通过监听scroll事件判断哪些canvas在视口范围内只对这些页面执行重新渲染其余区域保留原样。这个优化让大文件的缩放流畅了不少。缩放体验还有一个加分项缩放比例显示。我通过一个ref绑定缩放百分比在zoomIn和zoomOut后更新这样用户清楚当前处于什么缩放级别。关于缩放中的毛边问题可以给canvas加两条CSS规则来缓解canvas.pdf-page { image-rendering: -webkit-optimize-contrast; image-rendering: optimizeQuality; }这两行可以让缩放后的边缘更平滑一些实测在Chrome和Edge上都有效。3.2 旋转操作的实现细节旋转功能实现起来比想象中要微妙。PDF.js的viewport本身没有直接的旋转参数但getViewport方法可以传入rotation参数const viewport page.getViewport({ scale: 1.5, rotation: currentRotation // 0, 90, 180, 270 })所以旋转的核心就是维护一个currentRotation变量在渲染时把它传给getViewport然后重新渲染所有页面。旋转操作要注意canvas的尺寸变化。旋转90度后页面的宽高是互换的canvas的width和height要跟着切换。不能只改样式否则会出现内容被裁切的问题。function rotateClockwise() { currentRotation (currentRotation 90) % 360 reRenderAllPages() }重新渲染的时候我们需要检查一下canvas的宽高是否和viewport匹配function updateCanvasSize(canvas, viewport) { const dpr window.devicePixelRatio || 1 canvas.width Math.floor(viewport.width * dpr) canvas.height Math.floor(viewport.height * dpr) canvas.style.width ${viewport.width}px canvas.style.height ${viewport.height}px }如果旋转后canvas宽高不更新渲染结果就会有一半是空的这个问题我在初版调试时折腾了不少时间。核心原因就是我只改了viewport没有同步canvas的物理尺寸。3.3 文本选择启用TextLayer有些PDF内容是可复制的比如合同文件、论文文档。PDF.js支持把这些文本内容以Layer的方式叠加在Canvas上让浏览器可以选中和复制文字。默认情况下Canvas渲染出来是一张图片文字不能直接选择。启用TextLayer可以解决这个问题。PDF.js的文本提取能力依赖getTextContent接口然后通过TextLayer来渲染async function renderTextLayer(page, container, viewport) { const textContent await page.getTextContent() // 创建一个和canvas重叠的div作为文本层容器 const textLayerDiv document.createElement(div) textLayerDiv.className text-layer textLayerDiv.style.width ${viewport.width}px textLayerDiv.style.height ${viewport.height}px container.appendChild(textLayerDiv) // 渲染文本到该层 await pdfjsLib.renderTextLayer({ textContentSource: textContent, container: textLayerDiv, viewport: viewport, textDivs: [] }).promise }关键样式.text-layer { position: absolute; top: 0; left: 0; overflow: hidden; opacity: 0.2; line-height: 1; } .text-layer span { color: transparent; position: absolute; white-space: pre; transform-origin: 0% 0%; } .text-layer ::selection { background: rgba(0, 0, 255, 0.3); }这里要注意文本层必须绝对定位在Canvas上并且尺寸要和Canvas完全一致。如果文本层和Canvas对不齐会出现文字和图片内容错位的视觉问题。我测试下来opacity设为0.2是比较好的平衡点可以看到选中效果又不影响阅读。文本层的坐标变换是最容易出问题的。PDF.js的textContent里每个文本项有自己的transform矩阵renderTextLayer方法会自动处理这些变换。但如果你自己写定位逻辑很容易踩坑。建议直接用官方提供的renderTextLayer别自己造轮子。3.4 工具栏和用户交互设计一个实用的PDF预览器还需要好用的交互界面。我的工具栏包含上一页/下一页、页码输入框、总页数展示、放大/缩小按钮、缩放百分比展示、旋转按钮。这里分享一个在Vue3里实现的小细节页码输入框需要和当前页码双向绑定template div classpdf-toolbar button clickprevPage :disabledcurrentPage 1上一页/button input v-model.numbercurrentPageInput typenumber min1 :maxpageCount changejumpToPage / span/ {{ pageCount }}/span button clicknextPage :disabledcurrentPage pageCount下一页/button button clickzoomIn放大/button span{{ zoomPercentage }}%/span button clickzoomOut缩小/button button clickrotateClockwise旋转/button /div /template滚动或翻页后更新页码的逻辑function updateCurrentPage(pageNum) { currentPage.value pageNum currentPageInput.value pageNum }4. 中文乱码、特殊字体和资源加载问题4.1 中文PDF渲染乱码的原因分析中文PDF渲染乱码这个问题我在接入PDF.js后遇到了不止一次。场景是这样的本地写的一个包含中文的PDF在浏览器里预览时中文部分要么是空白要么显示成方块或乱码英文和数字正常。排查后发现大多数情况下是因为PDF文件内嵌的中文字体没有正确加载。PDF.js为了控制打包体积默认没有包含完整的CMap和字体解析信息需要额外配置。解决方案是引入cmaps目录并设置cMapUrl参数import * as pdfjsLib from pdfjs-dist // 设置CMap目录 pdfjsLib.GlobalWorkerOptions.cMapUrl https://cdn.jsdelivr.net/npm/pdfjs-dist3.11.174/cmaps/ pdfjsLib.GlobalWorkerOptions.cMapPacked true或者使用直接挂载本地文件的方式通过Vite的?url或其他方式让它被正确打包。不过CDN方式在局域网内使用有风险需要确保能访问外网否则还是会乱码。最好是下载cmaps目录放到本地静态资源目录然后pdfjsLib.GlobalWorkerOptions.cMapUrl /cmaps/ pdfjsLib.GlobalWorkerOptions.cMapPacked true这里cMapPacked设置为true表示读取.bcmap格式文件体积更小。如果你已经把pdfjs-dist/build/pdf.worker.min.js配置好了但中文还是乱码优先检查cMapUrl是不是配置正确。注意cMapUrl末尾的斜杠不能省否则路径拼接会出错。4.2 嵌入字体的加载策略PDF文件里嵌入的字体类型有标准14种字体如Times、Helvetica、Courier和自定义嵌入字体。标准字体通常不会出现问题自定义嵌入字体在预览时偶尔会显示错位或者样式异常。对于嵌入字体PDF.js会尝试从PDF文件字节流中解析并渲染。这个过程主要依赖FontFace浏览器API。如果页面是HTTPS环境一般没问题。但如果是本地开发环境http://localhost某些浏览器对FontFace的使用有限制可能会影响字体加载。我的调试建议是打开浏览器的Console面板看有没有和font相关的warning。常见的提示是FontFace was not loaded之类的。处理方式是把PDF预览页面的环境和生产保持一致使用HTTPS访问。还有一种情况是字体子集subset的PDF类似那种只嵌入了用到的部分字符。PDF.js在解析这类文件时偶尔会需要额外的标准字体数据。如果需要彻底解决建议在服务端把PDF统一转成带有完整字体的版本再传给前端这个方法能一劳永逸地解决字体相关的大多数问题。4.3 大文件加载的性能优化大PDF文件比如几百MB在加载时会占用大量内存和CPU资源页面容易出现卡顿甚至崩溃。这里结合我做过的优化整理几个有效的方案。一个是懒加载策略。pdf.getDocument会解析整个PDF的结构信息但不一定会把每一页都完整渲染。所以对于大文件优先考虑按需渲染。进入某一页时才真正调用pdf.getPage(pageNum)去解析那一页的数据。这个思路可以把初始加载时间从几秒缩短到几百毫秒。还有Worker线程数调整。PDF.js默认使用单个Worker线程可以通过GlobalWorkerOptions.workerPort创建多个Worker但需要谨慎配置。实际测试中多个Worker对CPU多核有帮助但对于I/O密集型的PDF解析收益有限。配置不当反而增加内存开销所以建议默认单Worker即可。如果要显示loading进度可以监听getDocument返回的loadingTask.onProgressconst loadingTask pdfjsLib.getDocument(url) loadingTask.onProgress (progressData) { const { loaded, total } progressData const percent Math.round((loaded / total) * 100) updateProgressBar(percent) } const pdf await loadingTask.promise4.4 网络URL的跨域问题处理通过URL加载远程PDF会遇到跨域限制。PDF.js底层是用fetch获取资源跨域请求如果不被目标服务器允许就会失败。处理方案一是让后端配置CORS在响应头加上Access-Control-Allow-Origin: *二是后端做代理把PDF文件先拉到我们的服务器再由前端请求同域地址。后面这种方案在不能改对方服务器配置的情况下很常用。如果PDF有权限控制比如需要带Token才能访问那就不能用简单的URL方式加载。可以先把PDF文件通过接口下载为Blob然后用URL.createObjectURL生成临时URL传入getDocumentconst response await fetch(pdfUrl, { headers: { Authorization: Bearer ${token} } }) const blob await response.blob() const objectUrl URL.createObjectURL(blob) const loadingTask pdfjsLib.getDocument(objectUrl)注意用完后要URL.revokeObjectURL(objectUrl)释放内存。5. 常见问题排查与优化实践5.1 基础报错速查表报错信息问题原因解决方案Cannot read properties of undefined (reading numPages)pdf对象还没加载完成就拿它做操作确认await loadingTask.promise之后才使用pdf对象PDFWorker is not enabledWorker没有配置成功检查GlobalWorkerOptions.workerSrc是否设置正确InvalidPDFException文件不是合法的PDF格式检查文件流数据是否完整尝试另存为标准PDF再试MissingPDFExceptionURL地址无法访问或者404确认网络地址可访问确认跨域配置PasswordExceptionPDF被加密用getDocument({ password })传密码UnknownErrorException渲染过程中出现未知异常查看浏览器Console的详细堆栈信息5.2 渲染白屏排查思路渲染结果是白屏这个是最让人头疼的问题之一。我整理了一套排查顺序先看Console有无报错。有报错的话优先处理报错常见的是某个API找不到或者Worker加载失败。再看canvas元素是否创建成功。如果canvas创建了但内容是空白可能是canvas的宽高设置成了0。用开发者工具的元素选择器选一下canvas看元素尺寸显示是否正常。再看网络面板worker文件是否加载成功。如果worker文件返回404在Localhost环境下很可能是因为路径处理不当。检查设置的workerSrc和实际文件路径是否匹配。然后是渲染返回值问题。page.render方法返回的是RenderTask对象它有promise属性。忘记await也可能导致后续操作提前执行。确保如下写法const renderTask page.render(renderContext) await renderTask.promise最后看PDF文件本身是否损坏。可以用Adobe Acrobat或者浏览器自带的PDF预览打开对比如果原文件都不能正常显示就不应该怀疑代码。5.3 Vue3开发中内存泄漏和重复渲染处理Vue3项目里使用PDF.js要注意组件卸载时的资源释放。如果组件被销毁但PDF.js还在后台渲染会浪费资源。可以在onUnmounted里做清理script setup import { onUnmounted, ref } from vue let pdfInstance null let loadingTask null const isComponentActive ref(true) onUnmounted(() { isComponentActive.value false if (loadingTask) { loadingTask.destroy() } if (pdfInstance) { pdfInstance.destroy() } }) /script多次快速点击“下一页”“上一页”会触发多个渲染任务并发执行可能造成页面内容错乱。可以用一个简单的渲染ID来标记当前的渲染请求确保只有最新的渲染生效let renderTaskId 0 async function renderCurrentPage() { const currentTaskId renderTaskId const page await currentPdf.getPage(currentPage.value) const viewport page.getViewport({ scale: currentScale.value }) const renderTask page.render({ canvasContext: canvasRef.value.getContext(2d), viewport }) // 如果期间用户又操作了丢弃这次渲染结果 try { await renderTask.promise if (currentTaskId ! renderTaskId) return updateUI() } catch (e) { if (e?.name RenderingCancelledException) return throw e } }还有pdf.destroy()和loadingTask.destroy()的区别。loadingTask.destroy()主要是在加载过程中取消任务pdf.destroy()是释放已加载文档的所有资源。组件销毁时两者最好都调用一下。5.4 打包体积优化按需引入与CDN配合pdfjs-dist打包体积不小如果不做处理所有模块都会打进去。看一下构建后的chunk大小pdf核心模块大概有几百KB再加worker文件整个应用首屏压力会比较大。可以通过CDN方式按需引入!-- index.html -- script srchttps://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/pdf.min.js/script !-- 可选的worker脚本 -- script srchttps://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/pdf.worker.min.js/script然后在代码里通过window.pdfjsLib访问。这种方式的优点是不影响应用的构建体积利用CDN的缓存加速。缺点是如果CDN不稳定或用户网络受限会影响功能。如果不想用CDN也可以配置Vite的manualChunks把pdfjs-dist单独分包// vite.config.js build: { rollupOptions: { output: { manualChunks: { pdfjs: [pdfjs-dist] } } } }这样浏览器可以独立缓存pdfjs相关代码其他业务代码更新时不会导致pdfjs重新下载。5.5 移动端适配的细节处理移动端使用PDF预览时触摸事件的响应和PC端差异很大。主要体现在两个方面缩放交互方式和canvas渲染清晰度。移动端一般通过pinch双指捏合来缩放如果用按钮缩放体验不好。可以借助vueuse的onPointerDown等API来实现手势缩放核心逻辑是监听两个触摸点之间的距离变化然后映射到缩放级别。关于清晰度移动端设备通常devicePixelRatio更高常见3倍屏如果不把设备像素比考虑进去渲染的canvas在屏幕上会非常模糊。前面提到的计算viewport时通过window.devicePixelRatio || 1来放大scale这个处理在移动端尤其重要。另外移动端的滚动容器会有橡皮筋效果如果PDF页面多滚动性能需要优化。可以考虑把Canvas的will-change设置为transform来提升滚动性能。6. 实操心得总结整理一下做这个PDF预览功能后的几个感受第一个是GlobalWorkerOptions.workerSrc要放在最前面设置并且确认设置成功后面所有基于PDF.js的功能都会受它的影响。很多奇怪的问题最后都指向Worker配置。第二个是渲染Canvas时一定要记得设置设备的devicePixelRatio这是决定预览清晰度的关键。很多人忽略了这一点预览出来的PDF文字都是虚的。第三个是中文字体乱码的排查思路优先从cMapUrl入手。性能方面如果一个功能涉及到多次重新渲染全部页面比如缩放、旋转、切换页码一定要思考“是不是有更轻量的方式”比如只重新渲染当前可见页。最后PDF.js的版本升级比较频繁不同版本API可能有调整锁版本确实是个好习惯升级时要有针对性地做回归测试。这些经验都是从一个接一个的实际问题中积累的把这个教程分享出来希望能让后来的人少踩一些坑。如果后续你还遇到其他和PDF相关的问题也欢迎一起交流。