不經服務端轉碼就能開 275 種檔案:File Viewer 這套純前端方案,省的是誰的運維帳
開源專案 File Viewer 以 275 個副檔名、47 條預覽鏈路在瀏覽器端直接開啟附件,本文從成本結構與技術替代曲線角度,拆解純前端方案取代服務端轉碼的帳。
刊登 閱讀約 5 分鐘
275 個副檔名、47 條預覽鏈路、225 個穩定格式加上 50 個實驗格式。這組數字來自開源專案 File Viewer 作者於 2026 年 10 月 19 日發布在掘金的長文,專案最新版本 3.2.2 於前一日(10 月 18 日)釋出。本文以該文為事實基礎,從成本結構角度拆解:把檔案預覽從服務端搬進瀏覽器,動到的是哪一欄支出。
既有三種做法的成本結構
作者在文中先盤點後臺與 OA 系統處理附件預覽的常見路徑。第一種是服務端轉碼,以 kkFileView 或 LibreOffice 將文件轉為 PDF 或 HTML。效果穩定,但要多維護一套服務,檔案必須先上傳伺服器,大檔案轉碼還要排隊。這條路的成本主要落在伺服器運維與轉碼運算資源,且隨檔案量線性成長。
第二種是 Office Online 這類 iframe 嵌入方案,前提是檔案能被公網存取。內網與私有化部署的專案因此被排除在外,這是需求分層問題而非技術問題。
第三種是按格式逐一找前端庫:pdf.js 看 PDF、docx-preview 看 Word、SheetJS 看 Excel。問題在於每個庫的 API、樣式、工具列各自為政,搜尋、縮放、列印功能要每條格式鏈重寫一遍,而 PPT、CAD 這類格式經常找不到合適的前端庫。
File Viewer 選的位置是保留第三種的純前端特性,加上統一外殼:同一套檔案源、生命週期、搜尋、縮放、列印、匯出與下載介面,格式只是可插拔的實作細節。
架構怎麼壓住捆包體積
專案是 monorepo,分四層。@file-viewer/core 負責格式識別、檔案源歸一化(URL、File、Blob)、渲染器調度與統一工具列,本身不含任何重型解析器。@file-viewer/renderer-* 每類格式一個獨立包,如 renderer-word、renderer-pdf、renderer-cad、renderer-3d、renderer-archive。@file-viewer/preset-* 將渲染器組合成 lite、standard、office、engineering、all 幾檔。最後是元件包,覆蓋 Vue 3、Vue 2.7、Vue 2.6、React、Svelte、jQuery 與 Web Component,各有輕量版與 full 版。
關鍵機制在渲染器定義中的 load 欄位:一個非同步函式,只在命中該格式時才動態 import 真正的解析程式碼、Worker 與 WASM。作者指出,只裝 preset-office 的專案不會把 CAD 與 3D 的程式碼打包進去,用了 preset-all 首屏也不會因 3D 引擎變慢。換句話說,格式支援廣度與首屏載入成本被這層延遲載入切開了。
另一個工程細節是格式數字的單一事實源。倉庫裡的 ecosystem/format-catalog.json 記錄每條鏈路的副檔名、所屬包、支援級別與已知限制,執行時註冊表、文件格式矩陣與統計數字都由它生成。275 這個數字即從此處統計而來,而非手寫在文件裡。
內容嗅探是後來補上的功能。真實業務裡經常遇到副檔名是 .docx、內容其實是老版 OLE 二進位 Word 的檔案,只看副檔名會直接報錯。渲染器因此加入有上限的內容探測,再決定交給哪條鏈路。
替代曲線上,服務端轉碼退到哪裡
這與我們先前分析的WebP 壓縮管線的頻寬成本單屬於同一類替代邏輯:把運算從伺服器搬到客戶端,省下的是服務端的運維與頻寬支出,代價則轉為客戶端的解析效能與相容性風險。File Viewer 的契約裡有 sourceAccess 欄位,允許渲染器優先拿原始 URL 而非先整檔下載,進一步把下載與解析的時間成本留在瀏覽器端處理。
誰受惠:做內網與私有化系統的開發團隊,省掉一套轉碼服務的部署與排隊瓶須;檔案不需離開客戶端,也降低了敏感附件先上傳伺服器才能預覽的資料暴露面。誰承壓:kkFileView 這類服務端轉碼方案的需求基本盤,在文件類格式的預覽場景會被純前端方案逐步侵蝕,但在列印還原度要求高、或客戶端效能受限的場景仍保有位置。
邊界在哪裡
作者在文中明確交代了做不到的部分,這點值得記帳。支援級別分為高還原、結構化、基礎、實驗四檔,意味著 275 個副檔名並非同等體驗;50 個實驗格式仍在清單內但狀態未穩。Word 部分作者最終選擇自研 DOCX 引擎並單獨發布,顯示即使有現成生態,格式覆蓋的長尾仍需要投入自建解析能力的資本支出。
以版本號看,3.2.2 的迭代節奏仍在密集推進,格式目錄作為單一事實源的設計也讓支援範圍的擴張成本可控。純前端預覽這條替代曲線能走多遠,最終取決於兩個變數:實驗格式轉穩定的速率,以及高還原級格式(如 PPT、CAD)在瀏覽器端能逼近服務端轉碼的還原度到什麼程度。這兩個數字,目前來源文中都還沒給出。