PDF 檔案很小，轉圖片卻卡住：先看頁數與像素

檔案容量不能直接當作處理所需記憶體

PDF 只有幾 MB，轉圖片卻一直等，先別急著把清晰度再往上調。我會拿一頁試轉，確認夠用的尺寸，再按需要的頁面分批。檔案容量只反映儲存下來的資料量，瀏覽器處理時還得解碼、建立像素、畫預覽和編碼下載檔。這些工作空間不能只照附件大小估計，也就不必一開始把全本都轉成大圖。

假設你要把二十頁掃描講義放進活動投影片，選了較高清晰度後一直停在處理中。本文沒有量測某款手機的記憶體上限，等待時間也不等於裝置故障。相同 5 MB 的兩份 PDF，頁數、頁面尺寸、字型、向量圖、透明效果與影像都可能不同，處理負擔不一定一樣。

排查時先記下哪份文件、哪一頁、用什麼設定出問題。如果只知道「附件很小」，還無法判斷是像素太多、文件內容不受支援，還是其他原因。

寬高都加倍，一份像素資料就變四倍

以 2480 × 3508 像素的一頁為例，共 8,699,840 個像素。若每個像素以四個 8 位元 RGBA 通道保存，一份像素資料是 34,799,360 bytes，約 33.19 MiB。這只算一個緩衝區，還沒加 PDF 解碼、預覽、輸出與瀏覽器其他開銷。

寬高都放大兩倍，得到 4960 × 7016，像素變成 34,799,360 個。同樣的緩衝區需要 139,197,440 bytes，約 132.75 MiB。這就是我不會一開始選最大尺寸的原因：寬、高各加倍，這份工作資料就變成四倍。解析度除了影響清楚程度，也影響處理時要容納多少像素。

假設二十頁的完整 RGBA 資料同時保留，前一種尺寸合計約 663.75 MiB。實際工具可能逐頁處理、釋放資料或保留多份副本，這個乘法不能當作本站記憶體實測。本站 PDF 轉圖片也會限制單頁輸出像素。這裡是緩衝區算例，不是本站會輸出上述尺寸的承諾。

只轉需要的頁面，尺寸用實際版面決定

投影片只需要第 3、8、12 頁的圖表，就先用 PDF 分割擷取這三頁，再轉圖片。使用其他支援選頁的工具時，也可直接縮小範圍。一批完成後先核對檔案，再做下一批，不把二十頁全部轉成大圖後才挑三張。

到底要轉多大？先挑一頁有代表性的內容，放進真正的版面看。投影片角落的小圖，不必按海報需求處理，密集小字的整頁文件又不能縮得太小。我會檢查方向、完整邊界、圖表細線與小字，再決定尺寸，下載縮圖看得見不代表放進投影片也夠清楚。

如果只降低 JPG 品質呢？它主要改變輸出編碼與容量，不能保證繪製前的記憶體也按同樣比例減少。要縮小這一份像素緩衝區，直接相關的是寬高。把容量、像素和品質分開記錄，下次才知道是在處理下載檔太大，還是轉圖時負擔太重。

如果要讓收件人搜尋或複製文字，保留原 PDF 通常更合用；只把一張圖貼進簡報，也不必改掉整本格式。確定要轉圖時，核對下載頁數與原始順序。需要再壓縮則保留清楚的第一版，從它做用途副本，別把低品質 JPG 反覆當來源。原 PDF、轉圖檔與簡報縮圖分開保存，改版時才能重做。

單頁仍失敗，記下頁碼、設定與錯誤訊息

單頁還是失敗時，我會先保存已完成的結果與原 PDF，關掉不需要的重複工作分頁，再用較小尺寸重試。如果總是同一頁失敗，就要留下錯誤資訊。原因也可能在那頁內容、文件結構或工具支援，不能只因為轉圖卡住，就認定是記憶體不足。

記下錯誤文字、原檔第幾頁、尺寸、瀏覽器與裝置，回報時附不含個資的重現說明。需要測試檔也先確認能分享的範圍，看看能否以不敏感副本重現，別直接公開整份敏感文件。

取消或重新載入後，先別急著把下載圖放進簡報。資料夾可能同時有前一輪和這一輪的同名結果，混在一起就容易漏頁。把批次名稱標出頁序，再記下哪些輸出已核對，缺哪一張才找得回來。

參考來源

• MDN：ImageData.data本文算式採 Uint8ClampedArray 的 8 位元 RGBA，每像素四 bytes；不是所有像素格式或實際總記憶體。