簡介面向移動端H5開發(fā)者的Canvas畫板批注PDF預覽資源包專注解決在手機端實現(xiàn)PDF文檔渲染、手寫批注與標記保存等交互需求。資源以PDF.js解析流程為技術主線覆蓋從PDF文檔加載、頁面渲染到Canvas畫板觸控繪制的完整鏈路并給出批注導出與持久化的實現(xiàn)參考。包內(nèi)共150個文件其中JS腳本承擔核心解析與繪制邏輯HTML與CSS搭建頁面結構GIF動圖直觀演示操作過程PNG/JPG圖片提供界面預覽另含字體、Map及PDF樣例等輔助文件壓縮后僅2.4MB小巧輕量。已有1750人學習下載適合需要快速落地移動端PDF批注功能的前端工程師與H5開發(fā)者。參考該資源可避開跨域配置、坐標適配、移動端事件兼容等常見坑點并結合layui等前端組件快速集成對分頁渲染與批注存儲等性能優(yōu)化也給出方向提示能顯著縮短從零開發(fā)周期。1. canvas 移動端畫板批注 PDF 預覽為什么圖片方案在這里不可行做移動端 H5 PDF 預覽時我最早偷懶把 PDF 轉成圖片再鋪到頁面上直到接了一個 canvas 移動端畫板批注需求被打臉用戶要能在 PDF 上直接畫圈、寫意見畫完還要能導出和回放。圖片方案表面簡單可一旦涉及多頁預覽、放大后批注對位、換設備之后筆跡偏移就處處踩坑。這份資源給的是另一條路用 canvas 承載批注層和 PDF 渲染層分離再用一套坐標映射把屏幕上的筆跡還原到 PDF 原始坐標系。適合正在做 H5 文檔預覽、審批流、簽字確認這類場景的前端也適合想搞清 canvas 分層繪制的讀者。2. 工程拆解PDF 渲染層與畫板批注層先分開再談功能拿到資源后別急著跑起來先把它拆成三個模塊PDF 渲染、畫板繪制、坐標換算。很多半成品項目的問題就是這三塊糊在一個組件里滾動、縮放、畫條線互相打架。下面先看源碼包的核心結構再逐層說為什么選這種方案。2.1 源碼包里的核心模塊長什么樣這份資源解開后工程結構大致是這樣src/ ├── pages/ # 頁面入口預覽頁、批注頁 │ ├── preview.js │ └── annotate.js ├── core/ │ ├── pdfRender.js # PDF 加載、翻頁、渲染 │ ├── board.js # 畫板層、筆跡繪制與事件綁定 │ ├── coordTransform.js # 屏幕坐標與 PDF 坐標互轉 │ └── history.js # 批注記錄、撤銷棧 ├── utils/ │ ├── dpr.js # 設備像素比處理 │ └── storage.js # 批注數(shù)據(jù)本地保存 └── styles/ └── board.css # 圖層定位、觸摸行為樣式這個結構對應的是分層思路pdfRender.js只負責把 PDF 畫到頁面board.js只負責在透明 canvas 上畫線coordTransform.js是兩者之間唯一的溝通橋梁。這樣做的好處是后續(xù)換 PDF 渲染庫、改畫板樣式都不會牽連到坐標換算邏輯。跑通資源里的 demo 后建議先找到coordTransform.js把里面兩個核心函數(shù)讀一遍。這個文件是整個項目的命脈不管你只是想要“能畫”還是想要“畫了能存、存了能還原”最終都要回到這里。2.2 PDF 渲染為什么選 pdf.js 而不是后端轉圖移動端 PDF 預覽有三種常見做法后端把 PDF 轉成圖片一次性返回、前端用原生控件加載、前端用 PDF 渲染庫逐頁繪制。這里的資源選的是第三種并且用的渲染方案是 pdf.js。原因是批注場景對“坐標一致性”要求太高。如果你把 PDF 轉成圖片前端拿到的是一張位圖就算知道圖片寬高也很難定位“這個 PDF 的第 3 頁里某個表格區(qū)域”在哪個像素點因為 PDF 頁面里的文字和矢量圖形已經(jīng)被拍扁成圖片了。而直接用 PDF 渲染庫可以得到每一頁的 viewport 數(shù)據(jù)知道當前頁的原始尺寸、縮放比例這樣畫板上的一個點可以精確映射回 PDF 的坐標點。// 以頁面原始寬度為基準構造當前頁 viewport const baseViewport page.getViewport({ scale: 1 }); const availableWidth container.clientWidth; const scale availableWidth / baseViewport.width; const viewport page.getViewport({ scale }); const renderTask page.render({ canvasContext: pdfCanvasContext, viewport }); renderTask.promise.then(() { // 渲染完成后再啟用畫板避免用戶畫在空白頁上 board.enable(); });邏輯說明先拿 scale1 的原始 viewport 計算網(wǎng)頁容器寬度下的縮放比再用這個縮放比生成正式 viewport最后調(diào)用render。renderTask.promise是渲染完成的回調(diào)入口畫板必須等 PDF 頁真正畫出來后再允許落筆否則第一筆會落在白底上。參數(shù)說明baseViewport.width是 PDF 頁在縮放比例為 1 時的寬度單位是 PDF 點。availableWidth是頁面容器去掉左右 padding 后的實際寬度。這里用“寬度自適應”而不是固定縮放是為了讓 PDF 鋪滿不同寬度的手機屏防止窄屏上出現(xiàn)橫向滾動條。2.3 畫板層一個透明 canvas 如何蓋在 PDF 上畫板層不是新造一個頁面而是用 CSS 把一個透明 canvas 絕對定位在 PDF canvas 上方。兩層結構如下div idpdfContainer classpdf-container canvas classpdf-layer idpdfCan/canvas canvas classboard-layer idboardCan/canvas /div.pdf-container { position: relative; width: 100%; overflow: hidden; } .pdf-layer, .board-layer { position: absolute; inset: 0; width: 100%; height: 100%; } .board-layer { touch-action: none; /* 禁止瀏覽器處理這套手勢 */ z-index: 2; }邏輯說明pdf-layer負責顯示 PDF 頁面board-layer覆蓋在它上面透明背景只顯示用戶新畫的筆跡。touch-action: none很關鍵它告訴瀏覽器這塊區(qū)域的手勢不要滾動頁面、不要縮放頁面統(tǒng)統(tǒng)交給 JS 處理否則在手機上畫橫線會被系統(tǒng)識別成滾動操作。參數(shù)說明inset: 0是讓畫板層和 PDF 層嚴格貼合任何一層的 border、padding 都會導致坐標計算起步就錯。z-index不是越高越好畫板層只需要比 PDF 層高一級太高了反而遮擋其他彈層組件。資源里把兩個 canvas 的寬高都用 CSS 設置為 100%但 canvas 內(nèi)部的像素寬高并沒有寫死這是給 dpr 適配預留的空間后面第三章會細講。3. 移動端適配觸摸事件、dpr 縮放與滾動沖突畫板在 PC 端 mouse 事件能跑通一到手機就露餡。這章講三個最常見又最容易忽略的移動端適配點。3.1 pointer events 替代 mouse 事件資源里的畫板用的是 Pointer Events而不是分開監(jiān)聽 touch 和 mouse。原因很簡單現(xiàn)在的觸控筆、手指、鼠標都能統(tǒng)一觸發(fā) pointer 事件不用再寫一套“如果支持 touch 就怎樣否則就怎樣”的分支代碼。const board document.getElementById(boardCan); const ctx board.getContext(2d); let isDrawing false; let lastPoint null; board.addEventListener(pointerdown, (e) { isDrawing true; lastPoint getPos(e); board.setPointerCapture(e.pointerId); }); board.addEventListener(pointermove, (e) { if (!isDrawing) return; const cur getPos(e); ctx.beginPath(); ctx.moveTo(lastPoint.x, lastPoint.y); ctx.lineTo(cur.x, cur.y); ctx.stroke(); lastPoint cur; }); board.addEventListener(pointerup, (e) { isDrawing false; board.releasePointerCapture(e.pointerId); });邏輯說明pointerdown觸發(fā)時用setPointerCapture鎖定指針防止手指畫出畫板范圍后事件丟失pointermove里不斷從上一個點連線到當前點pointerup結束本次筆畫。這里沒有用mousedown/mousemove/mouseup因為觸摸屏上 mouse 事件是模擬出來的會帶來幾十毫秒延遲畫出來的線不跟手。參數(shù)說明e.pointerId表示當前觸點編號。在單指批注場景我們只取第一個觸點的坐標如果后續(xù)要支持雙指同時書寫就需要用 pointerId 區(qū)分筆畫本資源默認不做多筆并發(fā)。getPos的實現(xiàn)在后面 3.2 節(jié)會一起說這里先記住它返回的是相對畫板左上角的 CSS 坐標值不含 dpr 放大。3.2 dpr 不等于 1 時畫布尺寸怎么取舍iPhone 的物理像素寬度經(jīng)常是 CSS 寬度的兩倍或三倍如果 canvas 的寬高直接用 CSS 尺寸出來的線條會糊。原因是 canvas 的繪圖緩沖區(qū)比屏幕物理像素小瀏覽器把它拉伸上去就虛了。解決辦法是讓 canvas 內(nèi)部像素尺寸乘上 dpr。function setupCanvas(canvas) { const dpr window.devicePixelRatio || 1; const rect canvas.getBoundingClientRect(); canvas.width rect.width * dpr; canvas.height rect.height * dpr; const ctx canvas.getContext(2d); ctx.setTransform(dpr, 0, 0, dpr, 0, 0); return ctx; }邏輯說明canvas.width rect.width * dpr設置的是繪圖緩沖區(qū)大小getBoundingClientRect拿到的是實際排版后的 CSS 尺寸。ctx.setTransform(dpr, 0, 0, dpr, 0, 0)讓后續(xù)所有繪圖坐標都按 CSS 坐標計算繪制系統(tǒng)自動映射到物理像素。參數(shù)說明這里千萬不能用window.innerWidth計算畫布寬度因為畫板容器可能不是全屏可能底部有工具欄、頂部有標題欄。改成getBoundingClientRect后任何布局變化都能即時反映。另一個容易忽略的點是在dpr為 3 的高端機型上整頁 canvas 的像素總量可能達到 3000x6000這對 WebGL 或 canvas 合成都有壓力后面第四章會專門講內(nèi)存問題。3.3 畫板與頁面滾動的互斥處理移動端 PDF 往往超過一屏頁面需要上下滾動。當手指落在畫板層上時畫板要求“這一筆完全由 JS 接管不要滾動”當手指落在 PDF 頁面的空白區(qū)域或工具欄時頁面該滾還得滾。實現(xiàn)上用 CSStouch-action控制畫板區(qū)域并在事件里判斷是否繼續(xù)傳播。const isOnBoard (e) { const boardRect board.getBoundingClientRect(); return e.clientX boardRect.left e.clientX boardRect.right e.clientY boardRect.top e.clientY boardRect.bottom; }; board.addEventListener(pointerdown, (e) { if (!isOnBoard(e)) return; e.preventDefault(); isDrawing true; // 阻止頁面滾動邏輯由 touch-action 控制這里不用手動調(diào) stopPropagation });這里preventDefault()與touch-action: none是雙保險。但注意preventDefault放在pointerdown里只是避免后續(xù)行為真正避免滾動還是要靠touch-action。如果你用pointermove里preventDefault部分 iOS 版本會報 Illegal invocation正確做法是在 CSS 層就聲明這個區(qū)域不可滾動。還有一點是長按選擇。移動端瀏覽器長按 canvas 會觸發(fā)圖片保存菜單或文本選擇干擾批注體驗。資源里給.board-layer加了全局樣式-webkit-user-select: none; user-select: none; -webkit-touch-callout: none;這些樣式在 Android 和 iOS 上都能有效減少誤觸但 Android WebView 的某些版本仍可能彈菜單必要時要在contextmenu事件里preventDefault()。4. 避坑批注偏移、白屏、內(nèi)存暴漲的排查筆記這章寫的是我反復翻車后整理出來的排查筆記每個現(xiàn)象都按“現(xiàn)象 → 原因 → 解決”展開。如果你在復現(xiàn)資源時遇到問題優(yōu)先對照這里。4.1 現(xiàn)象寫出來的筆跡和手指差一大截現(xiàn)象在手機上用手指畫線筆跡明顯偏到右下角位置還隨滾動變化。原因多半是 canvas 的 CSS 尺寸與內(nèi)部像素尺寸不一致時坐標計算直接用了canvas.width做比例換算。比如畫布內(nèi)部寬度是 750CSS 寬度只有 375代碼里卻把offsetX/clientX直接當 canvas 坐標用畫出來的位置自然翻倍。解決在繪制前先做一次坐標換算把鼠標或指針的屏幕坐標轉換成畫板坐標系中的 CSS 坐標再交給繪圖 API。function getPos(e) { const rect board.getBoundingClientRect(); return { x: e.clientX - rect.left, y: e.clientY - rect.top }; }這里返回的是未乘 dpr 的 CSS 坐標配合 3.2 節(jié)的ctx.setTransform(dpr,0,0,dpr,0,0)使用。只要這兩處統(tǒng)一批注層就不會偏移。另一個常見錯誤是忽略按鈕和導航欄占位導致rect.top算錯所以監(jiān)聽事件時要綁定在畫板自身而非整個 document然后用getBoundingClientRect實時取值別緩存一個靜態(tài) rect 用到翻頁后。4.2 現(xiàn)象PDF 頁面白屏只出邊框不出內(nèi)容現(xiàn)象PDF 容器有陰影邊框但里面空白的控制臺沒有報錯。原因通常是 PDF Worker 加載失敗。pdf.js 的解析運行在 Worker 線程里如果資源的 worker 路徑配置不對主線程會靜默失敗渲染層拿不到頁面數(shù)據(jù)。解決檢查 worker 路徑是否指向正確的本地文件并在初始化后打印加載狀態(tài)。pdfjsLib.GlobalWorkerOptions.workerSrc ./static/pdf.worker.min.js; pdfjsLib.getDocument(pdfUrl).promise.then((doc) { console.log(document loaded, pages:, doc.numPages); }).catch((err) { console.error(load failed, err); });注意getDocument的參數(shù)如果是跨域地址服務端必須配置跨域響應頭Access-Control-Allow-Origin否則 Worker 拿不到數(shù)據(jù)。另一個白屏來源是未設置pdfRender.js里的canvasContext類型部分版本需要{ canvasContext: ctx }而非{ context: ctx }寫錯不會立刻報錯渲染結果卻是空白排查時優(yōu)先看網(wǎng)絡請求里.worker文件是否 200。4.3 現(xiàn)象翻頁幾十次后頁面卡頓明顯現(xiàn)象PDF 一共 100 頁來回翻頁 30 次后滑動開始掉幀內(nèi)存占用翻倍。原因是每一頁渲染都新建了renderTask翻頁時沒有銷毀上一次任務甚至每次翻頁都在同一個 canvas 上反復繪制但未清除畫布導致 GPU 緩沖和 JS 對象越積越多。解決渲染下一頁前先取消正在進行的渲染任務并清理畫布。if (currentRenderTask) { currentRenderTask.cancel(); currentRenderTask null; } pdfCtx.clearRect(0, 0, pdfCanvasEl.width, pdfCanvasEl.height); currentRenderTask page.render({ canvasContext: pdfCtx, viewport });renderTask.cancel()會拋出一個 AbortException所以調(diào)用處最好用.catch判斷一下避免異常被當成錯誤上報。另外不要為了省事把整本 PDF 的所有頁都渲染成 canvas 再切換顯示移動端 canvas 數(shù)量一多WebView 的位圖緩存會先被擊穿。資源里的方案是只渲染當前頁翻頁時銷毀上一頁最多保留上一頁做過渡動畫。4.4 現(xiàn)象viewport 縮放后出現(xiàn)模糊或毛邊現(xiàn)象PDF 放大 200% 后批注線條看起來比 PDF 頁面文字更模糊有的線段邊緣出現(xiàn)明顯鋸齒。原因是放大后 PDF 渲染庫會重新生成高分辨率 viewport但畫板層內(nèi)部像素尺寸沒有跟著更新導致批注層仍然用低分辨率緩沖區(qū)繪制。解決在縮放操作結束后重設畫板的寬高和 transform。function resizeBoardToPdf(pdfCanvas) { const rect pdfCanvas.getBoundingClientRect(); board.style.width rect.width px; board.style.height rect.height px; board.width rect.width * dpr; board.height rect.height * dpr; boardCtx.setTransform(dpr, 0, 0, dpr, 0, 0); }有一個細節(jié)canvas 重新設置width或height會清空內(nèi)容所以這步必須在畫板無筆跡時執(zhí)行或者在重設前先用getImageData保存一份離屏位圖重設后再putImageData復原。資源里用的是離屏 canvas 緩沖后面第六章會演示。5. 實戰(zhàn)批注坐標映射與 JSON 導出讓畫的東西可回放移動端畫板批注的真正門檻不是畫線而是“在不同頁面尺寸、不同縮放比例、不同設備上畫出來都能對得上原始 PDF”。這里的關鍵是永遠不要保存屏幕坐標保存 PDF 坐標。5.1 坐標轉換公式與代碼實現(xiàn)屏幕上的點(x, y)先換算成畫板 CSS 坐標再除以當前縮放比例得到 PDF 頁面坐標。反過來回放時把 PDF 坐標乘上當前 viewport 縮放比例即可。// 屏幕坐標 - PDF 坐標 function screenToPdf(screenX, screenY, rect, viewport) { const cssX screenX - rect.left; const cssY screenY - rect.top; return { x: cssX / viewport.scale, y: cssY / viewport.scale }; } // PDF 坐標 - 屏幕坐標 function pdfToScreen(pdfX, pdfY, rect, viewport) { return { x: pdfX * viewport.scale rect.left, y: pdfY * viewport.scale rect.top }; }邏輯說明viewport對象來自page.getViewport({ scale })viewport.scale就是頁面渲染時的縮放倍數(shù)。之所以用除法而不是pageWidth / rect.width是因為縮放后 PDF 的坐標和畫布 CSS 坐標是線性關系除法最簡單也最不依賴頁面布局。參數(shù)說明如果 PDF 頁面在容器內(nèi)做了水平居中還需要減去容器的scrollLeft和偏移量。資源里默認容器寬度等于容器本身所以不用額外減。但一旦你改成左右留白模式就必須把rect.left換成“PDF 實際顯示區(qū)域”的 left否則批注會整體向右偏。建議把這段函數(shù)寫在coordTransform.js里并加上單測因為后續(xù)所有功能都建立在它之上。5.2 批注數(shù)據(jù)結構設計一次畫線動作可以抽象成一條 stroke數(shù)據(jù)結構如下const stroke { id: stroke_20240320_1645, page: 3, type: pen, color: #ff5722, width: 3, points: [ { x: 128.34, y: 56.02 }, { x: 129.1, y: 58.5 }, { x: 130.2, y: 61.0 } ] };這里points存的是 PDF 坐標不是屏幕坐標。顏色和線寬也存原始值因為 PDF 頁面重新渲染時如果設備像素比不同線寬的視覺表現(xiàn)會變存儲原始值可以保證回放時一致。數(shù)據(jù)結構定好后導出就是一個JSON.stringify(strokes)。資源里提供了history.js內(nèi)部維護strokes數(shù)組和undoStack數(shù)組。每完成一筆就 push 一次每撤銷一次就把當前 stroke push 到undoStack并重新繪制剩余筆畫。注意撤銷不是簡單地strokes.pop()因為后續(xù)還有“重做”操作所以要保留被撤銷的數(shù)據(jù)。function addStroke(stroke) { strokes.push(stroke); undoStack.length 0; // 新筆畫會清空重做棧 redrawAll(); } function undo() { if (strokes.length 0) return; const removed strokes.pop(); undoStack.push(removed); redrawAll(); }5.3 重新打開文檔時恢復批注恢復批注的流程是先渲染 PDF 當前頁拿到 viewport再遍歷該頁的 stroke 列表把 PDF 坐標轉成屏幕坐標逐段繪制。這里要特別小心跨頁數(shù)據(jù)如果用戶在第 3 頁畫到一半手指拖到了第 2 頁現(xiàn)實中很少發(fā)生但非禁用畫板時可能會導致一條筆畫的前半段在第 3 頁、后半段在第 2 頁。解決方法是每次pointerup時按當前頁號拆開保存而不是存一個全局 stroke。async function restorePageAnnotations(pageNum, strokes, viewport) { const pageStrokes strokes.filter((s) s.page pageNum); boardCtx.clearRect(0, 0, board.width, board.height); for (const stroke of pageStrokes) { boardCtx.beginPath(); boardCtx.strokeStyle stroke.color; boardCtx.lineWidth stroke.width; stroke.points.forEach((pt, i) { const sp pdfToScreen(pt.x, pt.y, boardRect, viewport); if (i 0) { boardCtx.moveTo(sp.x, sp.y); } else { boardCtx.lineTo(sp.x, sp.y); } }); boardCtx.stroke(); } }這段代碼在恢復多頁批注時有一個隱藏問題clearRect用的是board.width這是 dpr 放大后的像素值而clearRect的坐標單位受setTransform影響。如果用 CSS 坐標寫就應該清rect.width * dpr。建議統(tǒng)一封裝一個clearBoard()函數(shù)內(nèi)部用ctx.save()、ctx.setTransform(1,0,0,1,0,0)、clearRect(0,0,canvas.width,canvas.height)、ctx.restore()避免不同縮放狀態(tài)下清屏不干凈的 bug。5.4 導出圖片把 PDF 和批注合成為一張海報圖有些業(yè)務場景要求把“PDF 頁面 用戶批注”導出成一張圖片用于審批留檔或轉發(fā)。最常見做法是把 PDF 渲染到一個大 canvas再把批注層數(shù)據(jù)按同樣的 viewport 畫上去最后用canvas.toDataURL()導出。const mergeCanvas document.createElement(canvas); mergeCanvas.width pdfCanvas.width; mergeCanvas.height pdfCanvas.height; const mergeCtx mergeCanvas.getContext(2d); mergeCtx.drawImage(pdfCanvas, 0, 0); restorePageAnnotationsToContext(mergeCtx, pageStrokes, viewport); const imageUrl mergeCanvas.toDataURL(image/png);這里要注意drawImage(pdfCanvas, 0, 0)會把當前 PDF canvas 完整復制過去所以先畫 PDF 再畫批注順序不能反。導出的圖片像素大小等于 pdfCanvas 的內(nèi)部像素大小也就是 dpr 放大后的尺寸在手機上看起來清晰直接放到電腦上也不糊。如果遇到圖片導出后黑屏十有八九是restorePageAnnotationsToContext里沒有傳 viewport導致批注坐標和 PDF 圖片坐標不一致。6. 進階用離屏 canvas 與歷史棧優(yōu)化批注的撤銷和重繪畫板在筆畫少時性能沒問題但批注多到一頁 50 條以上時每次撤銷都要從頭重畫所有筆畫肉眼可見地卡頓。我在這份資源上做了兩處優(yōu)化效果都很直接。第一處是離屏 canvas 緩沖。新建一個不掛在文檔上的 canvas每次pointerup時把當前畫板內(nèi)容完整復制到離屏 canvas下一次繪制新筆畫前先drawImage恢復離屏內(nèi)容再畫新筆跡。這樣重繪畫板時不需要遍歷所有歷史 stroke只要一次位圖畫布拷貝。const offscreen document.createElement(canvas); offscreen.width board.width; offscreen.height board.height; function snapshot() { offscreenCtx.clearRect(0, 0, offscreen.width, offscreen.height); offscreenCtx.drawImage(board, 0, 0); } function restore() { boardCtx.clearRect(0, 0, board.width, board.height); boardCtx.drawImage(offscreen, 0, 0); }第二處是歷史棧的“全量重繪改增量恢復”。撤銷一條筆畫時不必重新執(zhí)行整個strokes數(shù)組的繪制而是先從離屏快照里去掉當前最后一條筆畫。但 canvas 位圖不方便“擦除某條線”所以最穩(wěn)的方案是維護兩個離屏 canvas一個存筆畫前快照一個存筆畫后快照。撤銷時直接切回前一張快照重做時切回后一張。代價是每畫一條筆跡會多占一份 canvas 內(nèi)存但移動端一次批注一般不會超過百條內(nèi)存換流暢度值得。從那以后我每次接移動端畫板需求都會先問清楚三個問題批注數(shù)據(jù)要不要保存到后端、PDF 放大后批注要不要跟著放大、撤銷最多支持多少層。這三個答案決定我要不要做增量快照、要不要存 PDF 坐標、要不要限制歷史棧長度。資源里默認做的是完整快照棧你在實際復現(xiàn)時如果發(fā)現(xiàn)內(nèi)存吃緊可以把快照壓成webp的 dataURL 再存雖然編解碼有開銷但內(nèi)存占用能降低不少。希望這份拆解和踩坑記錄幫到你。本文還有配套的精品資源點擊獲取