40GB片源不上傳、不裝App：一個index.html把播放器成本壓到零

2026年10月9日，掘金作者「霍營_託尼」發布一篇工程復盤，記錄自己如何用純前端方案播放40GB級本地影片。沒有後端、沒有框架、沒有Electron，整個專案只有一個index.html加一個app.js，核心依賴是Chrome的File System Access API與開源庫mpegts.js。

這篇技術文章值得從成本帳的角度重讀一遍，因為它示範了一件事：在特定場景下，瀏覽器已經能把「本地大檔案播放」這門生意的邊際成本壓到接近零。

使用者的痛點，就是繞不開的成本

作者的起點是三個具體痛點：本地播放器軟體體驗差、進度記不住；上傳網盤再線上看，幾小時的上傳時間加上會員費用；直接把檔案拖進瀏覽器的video標籤，4K MKV會讓記憶體飆到數GB，TS與FLV格式Chrome根本不支援，拖動進度條則畫面卡死。

這三個痛點對應三筆帳。播放器軟體帳是安裝與維護成本，網盤帳是頻寬與訂閱成本，瀏覽器原生播放帳則是記憶體成本。幾百GB的片源若走網盤路徑，上傳頻寬與會員費是持續支出；若走本地方案，過去的替代品是VLC或PotPlayer這類桌面軟體。

三條播放鏈路的架構拆解

方案最終收斂為三條鏈路。原生格式（MP4、MKV、MOV）走URL.createObjectURL(File)，TS與FLV走mpegts.js搭配自訂FileLoader，m3u8走內建下載器，全部基於File System Access API的檔案句柄按需讀盤。

關鍵認知在於URL.createObjectURL(file)並不會把整個檔案讀進記憶體。File物件本質上是磁碟的懶載入引用，瀏覽器按需讀盤，因此原生格式路徑天然就是流式，記憶體佔用與檔案總大小脫鉤。這一點直接決定了40GB檔案能否在瀏覽器跑起來。

真正的工程成本落在TS與FLV。mpegts.js為HTTP場景設計，預設用RangeLoader走fetch，而本地檔案沒有HTTP端點，必須自訂FileLoader把磁碟檔案偽裝成網路流。作者記錄的兩個實戰大坑都出在這裡。

第一坑是分片對齊。TS流的基本單位是188位元組的TS包，每個包以0x47開頭。最初版本用512KB（524288位元組）切分片，524288除以188等於2788.76，第2788個包被攔腰截斷，導致必現的花屏、卡死與時長亂跳。解法是把分片大小向下對齊到188的整數倍，即524100位元組、2788個完整包。

第二坑更隱蔽。mpegts.js內部用三參數的Uint8Array建構式切包，其offset參數只對ArrayBuffer來源生效；若傳入Uint8Array，它會無視offset整份複製，切出全數錯位的資料。這個缺陷不報錯、不崩潰，只表現為偶發花屏，排查成本遠高於第一坑。

影響推演：誰被替代，誰受惠

從技術替代曲線看，受壓的是兩類產品。一是本地影片播放軟體，當瀏覽器能以一個HTML檔案完成格式轉封裝、按需讀盤與進度跳轉，桌面播放器的安裝理由又少一分。二是雲盤的影片轉存與線上播放業務，這類服務按頻寬與會員收費，而本地方案把這兩項支出同時歸零。此一邏輯與先前前端分發成本那本帳的觀察一致：使用者端的資源限制一旦被理解清楚，成本往往能被重新分配。

受惠的一端是瀏覽器平臺本身。File System Access API目前仍是Chromium系才完整支援，這類應用案例增加，實質上拉高了Chrome的平臺黏著度，也讓PWA路線多了一個重度場景的論據。

開發者端的受惠更直接。零後端、零框架、兩個檔案的交付形態，意味著無伺服器成本、無維運成本，分發就是複製檔案。這與easygif.app純瀏覽器GIF工具的生存邏輯同構：把運算留在使用者端，邊際成本趨近於零的小工具才有免費空間。

收束判斷

這篇復盤的價值不在於播放器本身，而在於它把幾項早已存在的瀏覽器能力（File System Access、createObjectURL的懶載入語意、mpegts.js的載入器抽象）組合成一條完整替代路徑。188位元組對齊與ArrayBuffer型別這類細節，則說明替代的成本主要支付在工程除錯端，而非基礎設施端。

限制也必須交代：方案依賴Chromium對File System Access API的支援，Safari與Firefox使用者不在覆蓋範圍內；版權物件的合法性由使用者自行承擔，文章未觸及這一層。就工程帳而言，這是一次乾淨的示範：當分發與運算都能留在使用者端，一門小工具生意的固定成本與邊際成本可以同時壓到接近零，剩下的 only 是開發者自己的時間成本。