去年團隊里有人隨口問了一句："要是視頻處理能全在瀏覽器里搞定，不用服務器呢？"

我當時正在一家在線視頻平臺做技術評估，這句話把我拽進了一個長達8個月的WASM深坑?，F(xiàn)在回頭看，有些發(fā)現(xiàn)挺反直覺的——比如Safari這個"老拖后腿"的，居然開始翻身了。

從服務器賬單開始的實驗

我們給客戶的核心服務是視頻上傳和處理。傳統(tǒng)流程很標準：用戶傳文件→服務器做編碼/切片/分析→返回結果。

但賬單和延遲都在漲。文件越大，服務器成本越高，用戶等得越久。哪怕只是做個簡單的預處理或元數(shù)據(jù)提取，也要走完整的服務器鏈路，這件事本身就透著浪費。

"客戶端能不能扛？"這個想法成了評估WASM的起點。

答案是可以，而且比預期能干得多。

我們用的是ffmpeg.wasm——FFmpeg編譯成WebAssembly的版本。以下功能全部能在瀏覽器里直接跑：

不需要服務器。文件不出用戶設備。從隱私角度說，這是實打實的優(yōu)勢。

性能數(shù)據(jù)比我想象的好看。短視頻編碼速度大概是原生FFmpeg的1/5到1/2——聽著很慢，但別忘了這是在瀏覽器標簽頁里跑。能跑起來本身就夠離譜了。

視頻元數(shù)據(jù)提取幾乎是實時的。不用上傳就能拿到分辨率、碼率、時長這些信息，UX可以直接上一個臺階。

1GB文件引發(fā)的內(nèi)存慘案

最大的坑是內(nèi)存。

瀏覽器里的WebAssembly有硬性上限。處理大文件時稍有不慎就會內(nèi)存溢出崩潰——我親手踩過這個雷。直接把1GB視頻文件丟進去，標簽頁當場死亡。

解決方法是分塊處理。把大文件切成64MB的塊，順序寫入緩沖區(qū)：

分塊處理繞過了內(nèi)存限制，代價是代碼復雜度上升——但這個代價付得起。

實現(xiàn)起來不算優(yōu)雅，但穩(wěn)定。我們線上跑了幾個月，沒再出現(xiàn)過內(nèi)存崩潰。

Safari的翻身仗

評估過程中我順便掃了一眼整個WASM生態(tài)。和兩年前比，變化很大。

以前Safari是WASM世界的"新IE"——開發(fā)者要么寫降級代碼，要么干脆避開某些功能，因為蘋果在WASM支持上一直比Chrome和Firefox慢半拍。

現(xiàn)在情況變了。Safari 18.4支持了新的Wasm異常處理規(guī)范，Safari 26.0又加了原地解釋器來加速啟動。蘋果終于開始認真跟進了。

這個轉變的實際意義是什么？以前要維護三套代碼路徑的模塊，現(xiàn)在可以逐步收攏。對中小型團隊來說，維護成本是實打實的下降。

當然，Chrome和Firefox還是跑在前頭。但"Safari能用"和"Safari好用"之間的差距，正在以肉眼可見的速度縮小。

沒說完的部分

回到那個最初的問題：我們把多少服務器負載成功遷到了客戶端？

目前大約是30%的預處理任務——主要是元數(shù)據(jù)提取、縮略圖生成、格式預檢。編碼和重度處理還是留在服務端，畢竟2-5倍的性能差距在批量場景下扛不住。

但這個比例在動。WASM的編譯工具鏈在成熟，瀏覽器內(nèi)存限制也在緩慢放寬。我們內(nèi)部在測一個新的流式處理方案，目標是把單文件處理上限從現(xiàn)在的2GB推到10GB。

有個細節(jié)挺有意思：用戶其實感知不到背后換了技術。他們只發(fā)現(xiàn)"上傳前就能看到視頻信息了""小文件處理變快了"。技術債務的減少，最終變成了產(chǎn)品體驗的平滑。

所以如果你也在評估WASM，我的建議是——先找一個具體的成本痛點下手，而不是為了技術而技術。我們的起點只是一張服務器賬單，和一句"要是能……"的假設。

現(xiàn)在的問題是：當瀏覽器能做的事越來越多，你準備把哪些服務器任務"還"給用戶設備？