戰(zhàn)詳解)
1. 從一次文件上傳說起為什么前端必須掌握FileReader和Blob前兩周有個(gè)朋友跟我抱怨說他們公司做內(nèi)部管理系統(tǒng)遇到一個(gè)特別頭疼的需求用戶要上傳幾百M(fèi)B的壓縮包還要能預(yù)覽圖片、查看文本文件內(nèi)容甚至要把Excel里的數(shù)據(jù)抽出來做校驗(yàn)。他第一反應(yīng)是這得走后端吧結(jié)果后端同事冷笑一聲說文件解析本來就能在前端做你查查FileReader。其實(shí)這句話對(duì)了一半。FileReader確實(shí)能在瀏覽器本地讀取文件內(nèi)容但真正讓前端文件操作從花了呼哨變成生產(chǎn)力工具的是FileReader和Blob這對(duì)組合。一個(gè)負(fù)責(zé)把File/Blob數(shù)據(jù)讀進(jìn)內(nèi)存并轉(zhuǎn)成可用的文本、DataURL或二進(jìn)制buffer另一個(gè)負(fù)責(zé)用結(jié)構(gòu)化方式描述、切分、組合二進(jìn)制數(shù)據(jù)。兩者互相配合才能完成前端文件上傳預(yù)覽、分片傳輸、本地導(dǎo)出、圖片壓縮這些日常剛需。這篇文章不打算講那些官方文檔里一抄一大段的API羅列。我從一個(gè)實(shí)際項(xiàng)目里踩過的坑出發(fā)把FileReader的四個(gè)讀取方法、Blob的切片和應(yīng)用場(chǎng)景、以及兩者配合時(shí)最容易出問題的地方全部掰開揉碎講清楚。適合剛接觸前端文件處理的技術(shù)新人也適合想系統(tǒng)梳理一遍、避免在項(xiàng)目里踩坑的進(jìn)階開發(fā)者。先花一分鐘理解一個(gè)基礎(chǔ)概念瀏覽器里一切文件操作的本質(zhì)都是二進(jìn)制數(shù)據(jù)操作。FileReader是將二進(jìn)制轉(zhuǎn)為可讀內(nèi)容的翻譯官Blob是二進(jìn)制數(shù)據(jù)的容器和切分器。繞明白這兩句話后面全是細(xì)節(jié)。2. FileReader把文件讀進(jìn)內(nèi)存的四把鑰匙FileReader說白了就是瀏覽器提供的一個(gè)文件內(nèi)容讀取器。你給它一個(gè)File對(duì)象或者Blob對(duì)象它通過內(nèi)部異步機(jī)制把內(nèi)容讀出來然后通過事件回調(diào)把結(jié)果交給你。之所以叫Reader是因?yàn)樗还茏x,不管寫——寫文件、生成文件是另一碼事稍后講Blob時(shí)再聊。這里有個(gè)關(guān)鍵認(rèn)知FileReader的所有讀取方法都是異步的。也就是說你調(diào)用readAsText(file)之后文件內(nèi)容不會(huì)立刻出現(xiàn)在返回值里而是要等onload事件觸發(fā)才能拿到結(jié)果。新手最容易犯的錯(cuò)誤就是剛調(diào)用完就立刻取result結(jié)果自然是undefined。2.1 readAsText讀文本文件的最短路徑readAsText(blob, encoding?)會(huì)把Blob內(nèi)容按指定編碼解析成字符串第二個(gè)參數(shù)不傳時(shí)默認(rèn)UTF-8。這個(gè)方法最適合讀純文本、JSON、XML、CSV這類數(shù)據(jù)。const input document.querySelector(input[typefile]); input.addEventListener(change, async (e) { const file e.target.files[0]; const reader new FileReader(); reader.onload () { console.log(reader.result); }; reader.readAsText(file, UTF-8); });看起來很簡(jiǎn)單但有幾個(gè)細(xì)節(jié)值得注意。第一onload里拿到的reader.result是字符串。如果你讀的是JSON文件記得JSON.parse(reader.result)因?yàn)镕ileReader不管內(nèi)容結(jié)構(gòu)它只負(fù)責(zé)把字節(jié)變成字符串。第二編碼參數(shù)很重要。很多系統(tǒng)里用戶會(huì)上傳GBK編碼的CSV或TXT這時(shí)不指定GBK或者GB18030中文一定會(huì)亂碼。實(shí)測(cè)下來某些瀏覽器并不認(rèn)GBK這個(gè)標(biāo)簽要寫成GB18030才能兼容這是我踩過的第一個(gè)坑。第三超大文本文件慎用readAsText。一個(gè)100MB的TXT文件會(huì)被整體讀成一個(gè)超長(zhǎng)字符串內(nèi)存占用翻倍還會(huì)卡死渲染線程。遇到大文件正確做法是先切片再用readAsArrayBuffer逐段處理。后面講分片上傳時(shí)我會(huì)給完整示例。2.2 readAsDataURL圖片預(yù)覽的規(guī)范姿勢(shì)readAsDataURL把文件內(nèi)容編碼成Base64字符串并且自動(dòng)加上MIME類型前綴。比如讀一張PNG圖片得到的結(jié)果長(zhǎng)這樣data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA...這種DataURL可以直接塞給img.src、a.href實(shí)現(xiàn)預(yù)覽和下載。好處是簡(jiǎn)單直觀不需要額外生成臨時(shí)URL符合瀏覽器安全策略不需要考慮內(nèi)存釋放。壞處是Base64編碼會(huì)讓體積膨脹約33%而且一旦編碼成字符串你拿到的就不再是原始二進(jìn)制數(shù)據(jù)后續(xù)沒法直接傳給二進(jìn)制上傳接口。我個(gè)人的經(jīng)驗(yàn)是圖片預(yù)覽優(yōu)先用URL.createObjectURL而不是readAsDataURL兩者我都后文對(duì)比。但如果圖片本身要參與表單提交、跨端傳輸或需要暫存在本地比如存進(jìn)localStorage做草稿箱DataURL反而是更好的選擇。// 圖片預(yù)覽 - DataURL方案 const reader new FileReader(); reader.onload (e) { previewImg.src reader.result; // data:image/xxx;base64,.... }; reader.readAsDataURL(file);這里有一個(gè)非常隱蔽的坑用readAsDataURL讀大圖片時(shí)Base64字符串會(huì)非常長(zhǎng)放在img.src里雖然能顯示但內(nèi)存壓力很大而且瀏覽器地址欄或某些組件的日志里如果打了這個(gè)字符串頁面直接卡死。我在一個(gè)后臺(tái)管理系統(tǒng)里就遇到過用戶上傳一張8MB的照片console.log了預(yù)覽字符串整個(gè)DevTools直接崩潰。2.3 readAsArrayBuffer接觸二進(jìn)制原貌的入口readAsArrayBuffer返回ArrayBuffer對(duì)象它是一段固定長(zhǎng)度的原始二進(jìn)制數(shù)據(jù)緩沖不包含任何字符串語義。你可以在后續(xù)用DataView或Uint8Array等TypedArray視圖去解析、修改、讀取其中的字節(jié)。reader.onload () { const buffer reader.result; // 這是ArrayBuffer const bytes new Uint8Array(buffer); // 按字節(jié)視圖解讀 console.log(bytes.length, bytes[0]); // 例如文件長(zhǎng)度、第一字節(jié) }; reader.readAsArrayBuffer(file);這個(gè)方法幾乎是所有前端二進(jìn)制處理的基礎(chǔ)。判斷文件真實(shí)類型魔數(shù)校驗(yàn)、讀取圖片寬高、解析文件頭、計(jì)算MD5/SHA1哈希、分片上傳統(tǒng)統(tǒng)需要先拿到ArrayBuffer再操作。舉個(gè)實(shí)際例子圖片的PNG格式前8個(gè)字節(jié)固定是89 50 4E 47 0D 0A 1A 0AJPEG前3字節(jié)是FF D8 FF。想在前端做文件類型校驗(yàn)不能只看input的accept屬性因?yàn)橛脩舾臄U(kuò)展名就能繞過。正確做法是讀ArrayBuffer后檢查魔數(shù)function checkIsPng(buffer) { const bytes new Uint8Array(buffer.slice(0, 8)); const pngSignature [0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A]; return pngSignature.every((v, i) bytes[i] v); }這段代碼依賴ArrayBuffer.prototype.slice注意它與Blob.slice的返回類型不同前者返回新的ArrayBuffer后者返回新的Blob新手很容易搞混。2.4 生命周期事件與結(jié)果緩存FileReader除了onload還有onerror、onabort、onloadstart、onloadend、onprogress幾個(gè)常用事件。實(shí)際項(xiàng)目中至少需要處理onerror和onloadend。onloadend無論成功失敗都會(huì)觸發(fā)適合統(tǒng)一關(guān)閉loading狀態(tài)。const reader new FileReader(); reader.onloadstart () { showLoading(); }; reader.onprogress (e) { if (e.lengthComputable) { const percent Math.round((e.loaded / e.total) * 100); updateProgress(percent); } }; reader.onload () { handleResult(reader.result); }; reader.onerror (e) { showError(讀取失敗); }; reader.onloadend () { hideLoading(); }; reader.readAsText(file);還有兩個(gè)不可不知的細(xì)節(jié)。其一FileReader.result在讀取成功后會(huì)一直保留在對(duì)象上不會(huì)自動(dòng)清空。如果一個(gè)FileReader對(duì)象被復(fù)用去讀多個(gè)文件新結(jié)果會(huì)覆蓋舊結(jié)果但底層的舊內(nèi)存并不會(huì)立刻釋放。處理大量文件時(shí)建議每讀一個(gè)文件就新建一個(gè)FileReader或者讀完就reader null避免內(nèi)存回收不及時(shí)。其二reader.abort()可以中斷讀取觸發(fā)onabort事件。但在文件很大的情況下中斷之后的內(nèi)部狀態(tài)有些瀏覽器處理得并不干凈最穩(wěn)妥的做法是直接用新實(shí)例替換舊實(shí)例而不是嘗試復(fù)用。3. Blob二進(jìn)制數(shù)據(jù)的樂高積木如果說FileReader是讀文件內(nèi)容那Blob就是描述和操作二進(jìn)制數(shù)據(jù)本身。Blob的全稱是Binary Large Object瀏覽器里它代表一個(gè)不可變的原始數(shù)據(jù)塊。所有File對(duì)象實(shí)際上都繼承自Blob——這點(diǎn)非常重要意味著幾乎所有能操作Blob的API同樣能操作File。3.1 Blob的構(gòu)造與type屬性的門道創(chuàng)建Blob有兩種方式。一種是直接newconst blob new Blob([hello world], { type: text/plain }); const jsonBlob new Blob([JSON.stringify({a: 1})], { type: application/json });另一種是從已有Blob里切出一段const sliced largeBlob.slice(start, end, type);構(gòu)造時(shí)傳入的數(shù)組里可以是字符串、ArrayBuffer、TypedArray、DataView甚至另一個(gè)Blob。瀏覽器會(huì)把它們按順序拼接成一個(gè)整體。type屬性表示MIME類型這個(gè)字段的違規(guī)率非常高。很多人隨手填一個(gè)application/octet-stream完事結(jié)果后續(xù)下載文件時(shí)擴(kuò)展名不對(duì)、預(yù)覽時(shí)找不到合適的渲染器。從實(shí)踐角度講圖片image/png、image/jpeg、image/webp文本text/plain或text/markdownJSONapplication/json壓縮包application/zip通用二進(jìn)制application/octet-stream這個(gè)字段既是預(yù)覽和下載的依據(jù)也參與了文件類型識(shí)別。雖然真實(shí)文件頭的魔數(shù)才是權(quán)威但type字段如果填錯(cuò)了很多場(chǎng)景下會(huì)直接導(dǎo)致功能異常。我在項(xiàng)目中遇到過用Blob生成后端需要的JSON文件時(shí)type填了text/plain下載下來系統(tǒng)識(shí)別不了。改回application/json即刻解決。3.2 從Blob創(chuàng)建預(yù)覽URL前面提到圖片預(yù)覽有兩種思路這里全部展開。URL.createObjectURL(blob)**會(huì)根據(jù)Blob生成一段臨時(shí)URL格式是blob:http://域名/uuid。它引用著內(nèi)存里的Blob對(duì)象瀏覽器渲染圖片、視頻、PDF時(shí)可以直接加載這段URL。const objectUrl URL.createObjectURL(file); previewImg.src objectUrl;和DataURL相比objectURL有三個(gè)明顯優(yōu)勢(shì)體積零膨脹不經(jīng)過Base64編碼性能開銷極小生成速度快支持大文件預(yù)覽保真性好視頻、PDF等二進(jìn)制格式也能直接預(yù)覽但代價(jià)是這段URL的生命周期必須由你手動(dòng)管理。一旦不再使用必須調(diào)用URL.revokeObjectURL(objectUrl)釋放內(nèi)存。很多項(xiàng)目里只create不revoke后果就是頁面越用越卡尤其是上傳預(yù)覽圖片頻繁操作的頁面內(nèi)存直線往上漲。正確的姿勢(shì)是在圖片加載完成后盡快釋放const img new Image(); img.onload () URL.revokeObjectURL(objectUrl); img.src objectUrl;需要注意的是revoke要放在onload回調(diào)里而不是調(diào)用create后立刻執(zhí)行。revoke太早img還沒來得及加載預(yù)覽框變成一片空白。3.3 Blob切片與分片上傳的實(shí)現(xiàn)思路Blob有一個(gè)極其實(shí)用的能力slice(start, end, contentType)可以切出原始數(shù)據(jù)的任意子段返回新的Blob。這個(gè)能力直接支撐起前端分片上傳、斷點(diǎn)續(xù)傳、視頻流加載等場(chǎng)景。先看基礎(chǔ)分片代碼const CHUNK_SIZE 2 * 1024 * 1024; // 每片2MB function sliceFile(file) { const chunks []; let start 0; while (start file.size) { const end Math.min(start CHUNK_SIZE, file.size); chunks.push(file.slice(start, end)); start end; } return chunks; }這個(gè)循環(huán)很基礎(chǔ)真正有講究的是切完之后的上傳邏輯。我在項(xiàng)目里用過一個(gè)組合思路async function uploadChunks(file) { const chunks sliceFile(file); const total chunks.length; for (let i 0; i total; i) { const formData new FormData(); formData.append(chunk, chunks[i], file.name); formData.append(index, i.toString()); formData.append(total, total.toString()); formData.append(filename, file.name); // 用fetch逐個(gè)上傳 await fetch(/api/upload, { method: POST, body: formData }); progress.innerHTML 已上傳 ${i 1}/${total}; } }這段代碼的實(shí)際效果是前端把大文件切成多個(gè)小Blob每個(gè)獨(dú)立上傳服務(wù)端接收后按index順序合并。相比一次傳整個(gè)文件好處有三點(diǎn)第一避免大文件單請(qǐng)求超時(shí)。很多代理服務(wù)和網(wǎng)關(guān)對(duì)請(qǐng)求體大小和時(shí)間限制得非常死2MB一個(gè)的請(qǐng)求幾乎不會(huì)觸發(fā)超時(shí)。第二支持并發(fā)控制。可以把循環(huán)改成Promise.all限制同時(shí)3~5個(gè)請(qǐng)求實(shí)測(cè)上傳速度比串行快很多。第三具備斷點(diǎn)續(xù)傳的雛形。如果某個(gè)分片上傳失敗重新上傳失敗分片即可不需要整個(gè)文件重來。但這里有一個(gè)最容易遺漏的細(xì)節(jié)分片上傳時(shí)Blob切片返回的是一個(gè)視圖式的Blob它內(nèi)部引用的是原文件部分字節(jié)不是復(fù)制出來的獨(dú)立數(shù)據(jù)。也就是說原文件對(duì)象如果被垃圾回收切片切片可能出問題。因此分片期間必須保持原File對(duì)象引用不丟失。一些打包工具或?yàn)g覽器優(yōu)化可能會(huì)提前調(diào)整原Blob的生命周期所以最好把原文件也掛在作用域里或顯式保留引用。3.4 用Blob實(shí)現(xiàn)前端文件導(dǎo)出與下載Blob第三大高頻應(yīng)用場(chǎng)景是前端生成文件并下載。比如數(shù)據(jù)導(dǎo)出到CSV后端不參與純前端搞定。function exportCSV(data) { const rows data.map(row row.join(,)).join(\n); const blob new Blob([\uFEFF rows], { type: text/csv;charsetutf-8; }); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download 導(dǎo)出數(shù)據(jù).csv; a.click(); URL.revokeObjectURL(url); }這段代碼里的\uFEFF是BOM頭專門用來解決Excel打開CSV時(shí)中文亂碼的問題。不加BOMWindows上的Excel大概率以ANSI編碼解讀UTF-8的CSV中文直接變亂碼。加完BOMExcel才會(huì)正確識(shí)別為UTF-8。另一個(gè)細(xì)節(jié)是a.click()之后要立刻revoke嗎實(shí)踐中最好用setTimeout延遲到點(diǎn)擊事件完成后釋放或者干脆在下載事件響應(yīng)后釋放。有些瀏覽器在點(diǎn)擊事件同步執(zhí)行完之前釋放URL會(huì)導(dǎo)致下載失敗。穩(wěn)妥寫法a.onclick () setTimeout(() URL.revokeObjectURL(url), 1000);4. 工具選型與平臺(tái)差異這些坑不踩等于白學(xué)FileReader和Blob雖說是瀏覽器原生能力但在真正的項(xiàng)目中必須考慮兼容性、性能邊界、以及和現(xiàn)有框架的配合。4.1 兼容性現(xiàn)狀一個(gè)殘酷的事實(shí)FileReader在IE10才完整支持Blob和URL.createObjectURL更是要IE10。如果項(xiàng)目還要兼容IE9及以下這兩個(gè)API基本沒法用只能借助后端或者Flash方案——不過現(xiàn)在這么老的瀏覽器幾乎已經(jīng)絕跡這里只提一句考古?，F(xiàn)代瀏覽器中兩者的實(shí)現(xiàn)趨于一致但仍有微妙的差異new Blob()的構(gòu)造函數(shù)在Safari低版本上不支持需要PolyfillFileReader的readAsBinaryString被標(biāo)記廢棄不要使用URL.createObjectURL在部分Android WebView上生成的URL過期時(shí)間不穩(wěn)定必要時(shí)改用DataURL兜底我在一個(gè)混合開發(fā)項(xiàng)目里遇到過iOS的WKWebView對(duì)大Blob的objectURL支持很好但Android的X5內(nèi)核下URL.revokeObjectURL執(zhí)行時(shí)機(jī)稍晚就會(huì)導(dǎo)致內(nèi)存泄漏。最終的處理方案是統(tǒng)一用FileReader.readAsDataURL做圖片預(yù)覽雖然性能略差但平臺(tái)一致性更好。這個(gè)決策的依據(jù)是項(xiàng)目里圖片體積不大幾乎都在2MB以內(nèi)性能損耗在可接受范圍內(nèi)而平臺(tái)一致性直接決定了用戶體感。4.2 性能邊界與內(nèi)存管理FileReader和Blob的配合最容易出性能問題的是大文件全量讀進(jìn)內(nèi)存。比如一個(gè)200MB的壓縮包你調(diào)用readAsArrayBuffer想算MD5瞬間瀏覽器內(nèi)存上漲幾百M(fèi)B。不是不能做而是要控制并發(fā)、控制單次讀取量。我在實(shí)際項(xiàng)目中總結(jié)了一套經(jīng)驗(yàn)文件小于5MB直接readAsArrayBuffer讀全量無腦簡(jiǎn)單文件5MB~50MB先切片每片2MB逐片讀取并計(jì)算hash或上傳文件大于50MB必須結(jié)合file.slice分片且每讀完一片手動(dòng)把對(duì)應(yīng)的Blob引用置空另外一個(gè)被忽視的細(xì)節(jié)是FileReader讀大文件時(shí)result里的ArrayBuffer在讀取結(jié)束后不會(huì)被自動(dòng)釋放即使reader null也只是斷掉了引用。如果想強(qiáng)制回收內(nèi)存可以把reader.result也置空或主動(dòng)調(diào)用reader.abort()后再置空。實(shí)測(cè)在Chrome里reader null; reader.result null;之后堆內(nèi)存會(huì)明顯下降。4.3 FileReader與Blob對(duì)象的關(guān)系速查很多文檔把FileReader和Blob混在一起講導(dǎo)致新手搞不清誰是誰。我用一個(gè)小表格整理能力FileReaderBlob讀取文件內(nèi)容為文本支持readAsText不支持讀取文件為DataURL支持readAsDataURL不支持讀取為ArrayBuffer支持readAsArrayBuffer不支持生成臨時(shí)預(yù)覽URL不支持支持URL.createObjectURL切片不支持支持blob.slice構(gòu)造新文件不支持支持new Blob與FormData配合不能直接appendFile本身就是Blob子類可直接append這表格我背了很久。只要記住這兩句話FileReader負(fù)責(zé)從Blob/File里把字節(jié)讀出來Blob負(fù)責(zé)組織和切割數(shù)據(jù)本身。當(dāng)然File也繼承了Blob的一切能力所以file.slice能切file.type能查URL.createObjectURL(file)也能用。5. 實(shí)操環(huán)節(jié)一個(gè)文件預(yù)覽與分片上傳的綜合Demo講了這么多理論必須上點(diǎn)能直接抄的代碼。我拿一個(gè)典型的管理后臺(tái)文件管理系統(tǒng)場(chǎng)景舉例完成三件事圖片本地預(yù)覽、文本文件內(nèi)容讀取、大文件分片上傳。這三件事分別對(duì)應(yīng)FileReader的兩個(gè)方法和Blob切片。5.1 界面與交互設(shè)計(jì)頁面上有一個(gè)文件選擇框支持多選可以識(shí)別的文件類型包括圖片、文本、CSV。選擇后頁面分為三個(gè)區(qū)域圖片預(yù)覽區(qū)用URL.createObjectURL展示縮略圖文本內(nèi)容區(qū)用readAsText讀取并顯示文本內(nèi)容前1000個(gè)字符上傳進(jìn)度區(qū)無論什么文件都走分片上傳顯示進(jìn)度條這個(gè)設(shè)計(jì)瞄準(zhǔn)的是實(shí)際需求預(yù)覽是給用戶即時(shí)反饋的內(nèi)容讀取是為了前端本地校驗(yàn)比如檢查CSV表頭格式是否正確分片上傳是為了服務(wù)端接收大文件時(shí)更穩(wěn)定。5.2 核心代碼實(shí)現(xiàn)完整代碼貼出來可以直接放在一個(gè)HTML文件里跑!DOCTYPE html html langzh-CN head meta charsetUTF-8 / titleFileReader與Blob綜合實(shí)操/title /head body input typefile idfileInput multiple / h3圖片預(yù)覽/h3 div idpreview/div h3文本內(nèi)容/h3 pre idtextContent/pre h3上傳進(jìn)度/h3 div idprogress/div script const input document.getElementById(fileInput); const preview document.getElementById(preview); const textContent document.getElementById(textContent); const progress document.getElementById(progress); input.addEventListener(change, (e) { const files Array.from(e.target.files); files.forEach(handleFile); }); function handleFile(file) { // 根據(jù)type分流處理 if (file.type.startsWith(image/)) { previewImage(file); } else if (file.type.startsWith(text/) || file.type.includes(json) || file.type.includes(csv)) { readTextPreview(file); } uploadChunks(file); } function previewImage(file) { const url URL.createObjectURL(file); const img document.createElement(img); img.src url; img.style.maxWidth 200px; img.style.margin 8px; img.onload () URL.revokeObjectURL(url); preview.appendChild(img); } function readTextPreview(file) { const reader new FileReader(); reader.onload () { const str reader.result; // 只預(yù)覽前1000字符避免大文本卡頁面 textContent.textContent str.slice(0, 1000); // 檢測(cè)是否JSON并嘗試格式化 if (file.type.includes(json)) { try { const obj JSON.parse(str); textContent.textContent JSON.stringify(obj, null, 2); } catch (err) { textContent.textContent 解析JSON失敗 err.message; } } }; reader.onerror () { textContent.textContent 文件讀取失敗; }; reader.readAsText(file, UTF-8); } const CHUNK_SIZE 1 * 1024 * 1024; // 1MB一片 function sliceFile(file) { const chunks []; for (let start 0; start file.size; start CHUNK_SIZE) { const end Math.min(start CHUNK_SIZE, file.size); const chunk file.slice(start, end); chunks.push(chunk); } return chunks; } async function uploadChunks(file) { const chunks sliceFile(file); const total chunks.length; for (let i 0; i total; i) { // 模擬上傳實(shí)際上傳到后端接口 await simulateUpload(chunks[i], i, total, file.name); progress.textContent 文件 ${file.name}${i 1}/${total} 片; } } function simulateUpload(chunk, index, total, filename) { return new Promise((resolve) { setTimeout(() { console.log(第${index 1}/${total}片上傳完成大小${chunk.size}字節(jié)); resolve(); }, 200); }); } /script /body /html三個(gè)模塊的代碼都不復(fù)雜但組合起來就能覆蓋日常大部分文件處理需求。這個(gè)Demo我用在一個(gè)內(nèi)部的需求文檔上傳中心項(xiàng)目里當(dāng)時(shí)配合后端把接口對(duì)接好全流程跑得還算順利。5.3 實(shí)操中發(fā)現(xiàn)的關(guān)鍵問題第一個(gè)問題是input的multiple屬性配合文件校驗(yàn)時(shí)用戶可能一次選多種類型文件導(dǎo)致預(yù)覽區(qū)卡片混排。我后來加了分組渲染每種類型一個(gè)卡片組UI更清晰。第二個(gè)問題是文本預(yù)覽的編碼問題。瀏覽器通過file.type判斷文本類型是靠擴(kuò)展名和后端返回的MIME但CSV文件的編碼經(jīng)常是GBKreadAsText(file, UTF-8)讀到一半亂碼。我后來加了一個(gè)降級(jí)策略如果檢測(cè)到亂碼字符\uFFFD就用TextDecoder(gb18030)重新解碼ArrayBuffer。這個(gè)坑在實(shí)際業(yè)務(wù)里太常見了。function decodeText(buffer, fallbackEncoding) { try { return new TextDecoder(fallbackEncoding).decode(buffer); } catch (e) { return new TextDecoder(utf-8).decode(buffer); } }第三個(gè)問題是分片上傳時(shí)Excel等二進(jìn)制文件其實(shí)沒必要去預(yù)覽但業(yè)務(wù)要求選中文件后立即反饋。所以我在上傳前會(huì)先顯示文件大小和類型元信息再異步做預(yù)覽和讀取避免阻塞流程。6. 進(jìn)階FileReader和Blob與現(xiàn)代框架如何共存現(xiàn)在的項(xiàng)目基本都用了React、Vue或小程序框架。FileReader和Blob本質(zhì)上屬于瀏覽器原生能力框架層面沒有特殊適配但組合使用時(shí)依然有幾個(gè)值得留意的配合點(diǎn)。6.1 在React/Vue中的狀態(tài)管理Blob對(duì)象和FileReader實(shí)例都不是React狀態(tài)也不應(yīng)該放進(jìn)state里。因?yàn)锽lob可能很大放進(jìn)去會(huì)造成不必要的渲染和內(nèi)存拷貝。正確做法是File對(duì)象放在ref里引用讀取結(jié)果只把字符串或ArrayBuffer放入state。我在React項(xiàng)目里寫過類似這種代碼const [text, setText] useState(); const fileRef useRef(null); const handleChange (e) { fileRef.current e.target.files[0]; const reader new FileReader(); reader.onload () setText(reader.result); reader.readAsText(fileRef.current, UTF-8); };這個(gè)細(xì)節(jié)看似簡(jiǎn)單實(shí)際很多人把File對(duì)象直接setState然后發(fā)現(xiàn)輸入框的值還是空的因?yàn)镕ile對(duì)象的引用變了導(dǎo)致內(nèi)部狀態(tài)混亂。保持File對(duì)象引用不變結(jié)果字符串走state是最穩(wěn)的配合姿勢(shì)。在Vue3的setup里同理用shallowRef或者普通ref都可以但注意不要在computed里直接引用Blob對(duì)象做派生計(jì)算——每次依賴變化都會(huì)重新讀文件性能極差。6.2 小程序端的局限性再提一句小程序。小程序里沒有標(biāo)準(zhǔn)FileReader和Blob但微信小程序提供了wx.getFileSystemManager().readFile支付寶小程序有自己的my.readFile。整體能力對(duì)標(biāo)FileReader但細(xì)節(jié)差異很大尤其是編碼和路徑處理。如果你的團(tuán)隊(duì)同時(shí)做Web端和小程序端建議封裝一層統(tǒng)一的文件讀取接口Web端用FileReader小程序端用各自API上層業(yè)務(wù)邏輯保持一致。我參與過一個(gè)跨端項(xiàng)目最初直接在小程序里用Web的思維寫文件處理結(jié)果到處踩坑小程序讀取的是本地臨時(shí)文件路徑不是File對(duì)象讀取JSON必須指定encoding為utf8讀取ArrayBuffer后要轉(zhuǎn)字符串需要ArrayBuffer → Uint8Array → String.fromCharCode的方法鏈。后來統(tǒng)一封裝成async readText(path)和async readArrayBuffer(path)兩個(gè)方法才把兩端的復(fù)雜度隔離掉。6.3 與裝載器的配合再說一個(gè)容易被忽略的場(chǎng)景FileReader讀取的文件如果最終要傳給后端用FormData時(shí)不需要自己讀內(nèi)容直接formData.append(file, file)就行。只有要讀取內(nèi)容做預(yù)覽或校驗(yàn)時(shí)才需要FileReader。很多新手把上傳文件和讀取文件混為一談以為不上傳就不需要FileReader或者以為上傳前必須先讀取。其實(shí)上傳是底層協(xié)議的事瀏覽器會(huì)自己讀文件流前端只需要把File對(duì)象交給FormData或fetch的Body即可。理解這個(gè)邊界之后代碼寫起來會(huì)清晰非常多。FileReader用于我要看、我要算、我要改、我要校驗(yàn)的場(chǎng)景Blob用于我要切、我要拼、我要臨時(shí)URL、我要生成文件的場(chǎng)景。兩者合起來前端文件操作的全拼圖才完整。我在實(shí)際項(xiàng)目中還發(fā)現(xiàn)一個(gè)隱藏技巧用FileReader.readAsArrayBuffer讀取文件后配合CryptoJS或?yàn)g覽器內(nèi)置的crypto.subtle.digest計(jì)算文件SHA256在前端做文件去重、秒傳判定完全可行。這塊如果大家感興趣我后續(xù)可以單獨(dú)寫一篇前端計(jì)算大文件哈希的工程化方案。7. 常見問題排查與避坑速查表最后把這段時(shí)間實(shí)戰(zhàn)中高頻遇到的坑集中列出來給讀者當(dāng)速查手冊(cè)。這些問題每一個(gè)我都實(shí)際碰過有些甚至排查了整整一天。7.1 高頻報(bào)錯(cuò)與解決方案報(bào)錯(cuò)/現(xiàn)象根因解決方案reader.result為null讀取還沒完成就取值等onload觸發(fā)后再取讀取JSON中文亂碼編碼指定錯(cuò)誤或源文件非UTF-8readAsText時(shí)指定GB18030或用TextDecoder降級(jí)URL.createObjectURL后圖片不顯示revoke時(shí)機(jī)太早在img.onload后再revoke大文件上傳瀏覽器崩潰全量讀取ArrayBuffer分片、限制每次讀取量Blob轉(zhuǎn)File時(shí)lastModified丟失未顯式賦值new File([blob], name, {lastModified})分片上傳后文件合并損壞切片時(shí)end計(jì)算錯(cuò)誤使用Math.min(startsize, file.size)readAsDataURL內(nèi)存暴漲Base64膨脹33%改用objectURLSafari下new Blob報(bào)錯(cuò)低版本不支持構(gòu)造參數(shù)引入Blob Polyfill或改用File對(duì)象7.2 實(shí)戰(zhàn)排錯(cuò)實(shí)錄有一次線上反饋用戶上傳的CSV文件在預(yù)覽時(shí)前幾行正常后面全亂碼。排查過程是這樣的第一步懷疑編碼但全文件前幾行正常后面亂不太像整體編碼問題。第二步懷疑文件太大但文件只有3MB不至于卡。第三步直接用ArrayBuffer讀出來發(fā)現(xiàn)亂碼集中在某一行之后。仔細(xì)對(duì)比發(fā)現(xiàn)這一行恰好是某個(gè)字段里出現(xiàn)了一個(gè)特殊字符。最終定位文件里包含的某個(gè)特殊字符被瀏覽器判定為二進(jìn)制數(shù)據(jù)導(dǎo)致FileReader的文本解碼在那一行中斷。解決方法是改用readAsArrayBuffer讀取全量再用TextDecoder異步分塊解碼。這種問題單純看文檔根本發(fā)現(xiàn)不了必須動(dòng)手讀字節(jié)才能定位。還有一次遇到預(yù)覽PDF時(shí)白屏。排查發(fā)現(xiàn)URL.createObjectURL(blob)在Safari下能生成URL但WebView的PDF預(yù)覽組件不支持blob協(xié)議。最終方案是改用readAsDataURL生成DataURL遞給PDF預(yù)覽組件同時(shí)通過window.open打開新窗口預(yù)覽。這類兼容性適配經(jīng)驗(yàn)只能靠踩坑積累。7.3 一些寫在代碼注釋里的經(jīng)驗(yàn)最后分享幾條我每次寫文件處理代碼時(shí)都會(huì)遵守的約定所有FileReader實(shí)例用完后置空引用尤其循環(huán)讀取時(shí)創(chuàng)建ObjectURL后必須配套revoke可以用try/finally保證文本讀取優(yōu)先使用TextDecoder而非readAsText因?yàn)榍罢咧С址謮K解碼和按需結(jié)束字符串文件大小校驗(yàn)放在所有讀取動(dòng)作之前避免內(nèi)存浪費(fèi)處理超大文件時(shí)用requestIdleCallback分批處理Blob切片避免長(zhǎng)時(shí)間占用主線程這些約定看著瑣碎但長(zhǎng)期堅(jiān)持下來項(xiàng)目的穩(wěn)定性提升非常明顯。我見過太多功能能跑但一到大文件就崩的代碼基本都是在這幾個(gè)細(xì)節(jié)上偷懶導(dǎo)致的。文件操作雖然只是前端的一小部分但FileReader和Blob這對(duì)組合掌握好之后前面那些只能靠后端的需求會(huì)少一大半。下次再遇到文件預(yù)覽、分片上傳、本地導(dǎo)出別急著向后端求助先在瀏覽器里把數(shù)據(jù)的來龍去脈摸清楚。 前端文件處理利器：FileReader與Blob實(shí)戰(zhàn)詳解
1. 從一次文件上傳說起為什么前端必須掌握FileReader和Blob前兩周有個(gè)朋友跟我抱怨說他們公司做內(nèi)部管理系統(tǒng)遇到一個(gè)特別頭疼的需求用戶要上傳幾百M(fèi)B的壓縮包還要能預(yù)覽圖片、查看文本文件內(nèi)容甚至要把Excel里的數(shù)據(jù)抽出來做校驗(yàn)。他第一反應(yīng)是這得走后端吧結(jié)果后端同事冷笑一聲說文件解析本來就能在前端做你查查FileReader。其實(shí)這句話對(duì)了一半。FileReader確實(shí)能在瀏覽器本地讀取文件內(nèi)容但真正讓前端文件操作從花了呼哨變成生產(chǎn)力工具的是FileReader和Blob這對(duì)組合。一個(gè)負(fù)責(zé)把File/Blob數(shù)據(jù)讀進(jìn)內(nèi)存并轉(zhuǎn)成可用的文本、DataURL或二進(jìn)制buffer另一個(gè)負(fù)責(zé)用結(jié)構(gòu)化方式描述、切分、組合二進(jìn)制數(shù)據(jù)。兩者互相配合才能完成前端文件上傳預(yù)覽、分片傳輸、本地導(dǎo)出、圖片壓縮這些日常剛需。這篇文章不打算講那些官方文檔里一抄一大段的API羅列。我從一個(gè)實(shí)際項(xiàng)目里踩過的坑出發(fā)把FileReader的四個(gè)讀取方法、Blob的切片和應(yīng)用場(chǎng)景、以及兩者配合時(shí)最容易出問題的地方全部掰開揉碎講清楚。適合剛接觸前端文件處理的技術(shù)新人也適合想系統(tǒng)梳理一遍、避免在項(xiàng)目里踩坑的進(jìn)階開發(fā)者。先花一分鐘理解一個(gè)基礎(chǔ)概念瀏覽器里一切文件操作的本質(zhì)都是二進(jìn)制數(shù)據(jù)操作。FileReader是將二進(jìn)制轉(zhuǎn)為可讀內(nèi)容的翻譯官Blob是二進(jìn)制數(shù)據(jù)的容器和切分器。繞明白這兩句話后面全是細(xì)節(jié)。2. FileReader把文件讀進(jìn)內(nèi)存的四把鑰匙FileReader說白了就是瀏覽器提供的一個(gè)文件內(nèi)容讀取器。你給它一個(gè)File對(duì)象或者Blob對(duì)象它通過內(nèi)部異步機(jī)制把內(nèi)容讀出來然后通過事件回調(diào)把結(jié)果交給你。之所以叫Reader是因?yàn)樗还茏x,不管寫——寫文件、生成文件是另一碼事稍后講Blob時(shí)再聊。這里有個(gè)關(guān)鍵認(rèn)知FileReader的所有讀取方法都是異步的。也就是說你調(diào)用readAsText(file)之后文件內(nèi)容不會(huì)立刻出現(xiàn)在返回值里而是要等onload事件觸發(fā)才能拿到結(jié)果。新手最容易犯的錯(cuò)誤就是剛調(diào)用完就立刻取result結(jié)果自然是undefined。2.1 readAsText讀文本文件的最短路徑readAsText(blob, encoding?)會(huì)把Blob內(nèi)容按指定編碼解析成字符串第二個(gè)參數(shù)不傳時(shí)默認(rèn)UTF-8。這個(gè)方法最適合讀純文本、JSON、XML、CSV這類數(shù)據(jù)。const input document.querySelector(input[typefile]); input.addEventListener(change, async (e) { const file e.target.files[0]; const reader new FileReader(); reader.onload () { console.log(reader.result); }; reader.readAsText(file, UTF-8); });看起來很簡(jiǎn)單但有幾個(gè)細(xì)節(jié)值得注意。第一onload里拿到的reader.result是字符串。如果你讀的是JSON文件記得JSON.parse(reader.result)因?yàn)镕ileReader不管內(nèi)容結(jié)構(gòu)它只負(fù)責(zé)把字節(jié)變成字符串。第二編碼參數(shù)很重要。很多系統(tǒng)里用戶會(huì)上傳GBK編碼的CSV或TXT這時(shí)不指定GBK或者GB18030中文一定會(huì)亂碼。實(shí)測(cè)下來某些瀏覽器并不認(rèn)GBK這個(gè)標(biāo)簽要寫成GB18030才能兼容這是我踩過的第一個(gè)坑。第三超大文本文件慎用readAsText。一個(gè)100MB的TXT文件會(huì)被整體讀成一個(gè)超長(zhǎng)字符串內(nèi)存占用翻倍還會(huì)卡死渲染線程。遇到大文件正確做法是先切片再用readAsArrayBuffer逐段處理。后面講分片上傳時(shí)我會(huì)給完整示例。2.2 readAsDataURL圖片預(yù)覽的規(guī)范姿勢(shì)readAsDataURL把文件內(nèi)容編碼成Base64字符串并且自動(dòng)加上MIME類型前綴。比如讀一張PNG圖片得到的結(jié)果長(zhǎng)這樣data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA...這種DataURL可以直接塞給img.src、a.href實(shí)現(xiàn)預(yù)覽和下載。好處是簡(jiǎn)單直觀不需要額外生成臨時(shí)URL符合瀏覽器安全策略不需要考慮內(nèi)存釋放。壞處是Base64編碼會(huì)讓體積膨脹約33%而且一旦編碼成字符串你拿到的就不再是原始二進(jìn)制數(shù)據(jù)后續(xù)沒法直接傳給二進(jìn)制上傳接口。我個(gè)人的經(jīng)驗(yàn)是圖片預(yù)覽優(yōu)先用URL.createObjectURL而不是readAsDataURL兩者我都后文對(duì)比。但如果圖片本身要參與表單提交、跨端傳輸或需要暫存在本地比如存進(jìn)localStorage做草稿箱DataURL反而是更好的選擇。// 圖片預(yù)覽 - DataURL方案 const reader new FileReader(); reader.onload (e) { previewImg.src reader.result; // data:image/xxx;base64,.... }; reader.readAsDataURL(file);這里有一個(gè)非常隱蔽的坑用readAsDataURL讀大圖片時(shí)Base64字符串會(huì)非常長(zhǎng)放在img.src里雖然能顯示但內(nèi)存壓力很大而且瀏覽器地址欄或某些組件的日志里如果打了這個(gè)字符串頁面直接卡死。我在一個(gè)后臺(tái)管理系統(tǒng)里就遇到過用戶上傳一張8MB的照片console.log了預(yù)覽字符串整個(gè)DevTools直接崩潰。2.3 readAsArrayBuffer接觸二進(jìn)制原貌的入口readAsArrayBuffer返回ArrayBuffer對(duì)象它是一段固定長(zhǎng)度的原始二進(jìn)制數(shù)據(jù)緩沖不包含任何字符串語義。你可以在后續(xù)用DataView或Uint8Array等TypedArray視圖去解析、修改、讀取其中的字節(jié)。reader.onload () { const buffer reader.result; // 這是ArrayBuffer const bytes new Uint8Array(buffer); // 按字節(jié)視圖解讀 console.log(bytes.length, bytes[0]); // 例如文件長(zhǎng)度、第一字節(jié) }; reader.readAsArrayBuffer(file);這個(gè)方法幾乎是所有前端二進(jìn)制處理的基礎(chǔ)。判斷文件真實(shí)類型魔數(shù)校驗(yàn)、讀取圖片寬高、解析文件頭、計(jì)算MD5/SHA1哈希、分片上傳統(tǒng)統(tǒng)需要先拿到ArrayBuffer再操作。舉個(gè)實(shí)際例子圖片的PNG格式前8個(gè)字節(jié)固定是89 50 4E 47 0D 0A 1A 0AJPEG前3字節(jié)是FF D8 FF。想在前端做文件類型校驗(yàn)不能只看input的accept屬性因?yàn)橛脩舾臄U(kuò)展名就能繞過。正確做法是讀ArrayBuffer后檢查魔數(shù)function checkIsPng(buffer) { const bytes new Uint8Array(buffer.slice(0, 8)); const pngSignature [0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A]; return pngSignature.every((v, i) bytes[i] v); }這段代碼依賴ArrayBuffer.prototype.slice注意它與Blob.slice的返回類型不同前者返回新的ArrayBuffer后者返回新的Blob新手很容易搞混。2.4 生命周期事件與結(jié)果緩存FileReader除了onload還有onerror、onabort、onloadstart、onloadend、onprogress幾個(gè)常用事件。實(shí)際項(xiàng)目中至少需要處理onerror和onloadend。onloadend無論成功失敗都會(huì)觸發(fā)適合統(tǒng)一關(guān)閉loading狀態(tài)。const reader new FileReader(); reader.onloadstart () { showLoading(); }; reader.onprogress (e) { if (e.lengthComputable) { const percent Math.round((e.loaded / e.total) * 100); updateProgress(percent); } }; reader.onload () { handleResult(reader.result); }; reader.onerror (e) { showError(讀取失敗); }; reader.onloadend () { hideLoading(); }; reader.readAsText(file);還有兩個(gè)不可不知的細(xì)節(jié)。其一FileReader.result在讀取成功后會(huì)一直保留在對(duì)象上不會(huì)自動(dòng)清空。如果一個(gè)FileReader對(duì)象被復(fù)用去讀多個(gè)文件新結(jié)果會(huì)覆蓋舊結(jié)果但底層的舊內(nèi)存并不會(huì)立刻釋放。處理大量文件時(shí)建議每讀一個(gè)文件就新建一個(gè)FileReader或者讀完就reader null避免內(nèi)存回收不及時(shí)。其二reader.abort()可以中斷讀取觸發(fā)onabort事件。但在文件很大的情況下中斷之后的內(nèi)部狀態(tài)有些瀏覽器處理得并不干凈最穩(wěn)妥的做法是直接用新實(shí)例替換舊實(shí)例而不是嘗試復(fù)用。3. Blob二進(jìn)制數(shù)據(jù)的樂高積木如果說FileReader是讀文件內(nèi)容那Blob就是描述和操作二進(jìn)制數(shù)據(jù)本身。Blob的全稱是Binary Large Object瀏覽器里它代表一個(gè)不可變的原始數(shù)據(jù)塊。所有File對(duì)象實(shí)際上都繼承自Blob——這點(diǎn)非常重要意味著幾乎所有能操作Blob的API同樣能操作File。3.1 Blob的構(gòu)造與type屬性的門道創(chuàng)建Blob有兩種方式。一種是直接newconst blob new Blob([hello world], { type: text/plain }); const jsonBlob new Blob([JSON.stringify({a: 1})], { type: application/json });另一種是從已有Blob里切出一段const sliced largeBlob.slice(start, end, type);構(gòu)造時(shí)傳入的數(shù)組里可以是字符串、ArrayBuffer、TypedArray、DataView甚至另一個(gè)Blob。瀏覽器會(huì)把它們按順序拼接成一個(gè)整體。type屬性表示MIME類型這個(gè)字段的違規(guī)率非常高。很多人隨手填一個(gè)application/octet-stream完事結(jié)果后續(xù)下載文件時(shí)擴(kuò)展名不對(duì)、預(yù)覽時(shí)找不到合適的渲染器。從實(shí)踐角度講圖片image/png、image/jpeg、image/webp文本text/plain或text/markdownJSONapplication/json壓縮包application/zip通用二進(jìn)制application/octet-stream這個(gè)字段既是預(yù)覽和下載的依據(jù)也參與了文件類型識(shí)別。雖然真實(shí)文件頭的魔數(shù)才是權(quán)威但type字段如果填錯(cuò)了很多場(chǎng)景下會(huì)直接導(dǎo)致功能異常。我在項(xiàng)目中遇到過用Blob生成后端需要的JSON文件時(shí)type填了text/plain下載下來系統(tǒng)識(shí)別不了。改回application/json即刻解決。3.2 從Blob創(chuàng)建預(yù)覽URL前面提到圖片預(yù)覽有兩種思路這里全部展開。URL.createObjectURL(blob)**會(huì)根據(jù)Blob生成一段臨時(shí)URL格式是blob:http://域名/uuid。它引用著內(nèi)存里的Blob對(duì)象瀏覽器渲染圖片、視頻、PDF時(shí)可以直接加載這段URL。const objectUrl URL.createObjectURL(file); previewImg.src objectUrl;和DataURL相比objectURL有三個(gè)明顯優(yōu)勢(shì)體積零膨脹不經(jīng)過Base64編碼性能開銷極小生成速度快支持大文件預(yù)覽保真性好視頻、PDF等二進(jìn)制格式也能直接預(yù)覽但代價(jià)是這段URL的生命周期必須由你手動(dòng)管理。一旦不再使用必須調(diào)用URL.revokeObjectURL(objectUrl)釋放內(nèi)存。很多項(xiàng)目里只create不revoke后果就是頁面越用越卡尤其是上傳預(yù)覽圖片頻繁操作的頁面內(nèi)存直線往上漲。正確的姿勢(shì)是在圖片加載完成后盡快釋放const img new Image(); img.onload () URL.revokeObjectURL(objectUrl); img.src objectUrl;需要注意的是revoke要放在onload回調(diào)里而不是調(diào)用create后立刻執(zhí)行。revoke太早img還沒來得及加載預(yù)覽框變成一片空白。3.3 Blob切片與分片上傳的實(shí)現(xiàn)思路Blob有一個(gè)極其實(shí)用的能力slice(start, end, contentType)可以切出原始數(shù)據(jù)的任意子段返回新的Blob。這個(gè)能力直接支撐起前端分片上傳、斷點(diǎn)續(xù)傳、視頻流加載等場(chǎng)景。先看基礎(chǔ)分片代碼const CHUNK_SIZE 2 * 1024 * 1024; // 每片2MB function sliceFile(file) { const chunks []; let start 0; while (start file.size) { const end Math.min(start CHUNK_SIZE, file.size); chunks.push(file.slice(start, end)); start end; } return chunks; }這個(gè)循環(huán)很基礎(chǔ)真正有講究的是切完之后的上傳邏輯。我在項(xiàng)目里用過一個(gè)組合思路async function uploadChunks(file) { const chunks sliceFile(file); const total chunks.length; for (let i 0; i total; i) { const formData new FormData(); formData.append(chunk, chunks[i], file.name); formData.append(index, i.toString()); formData.append(total, total.toString()); formData.append(filename, file.name); // 用fetch逐個(gè)上傳 await fetch(/api/upload, { method: POST, body: formData }); progress.innerHTML 已上傳 ${i 1}/${total}; } }這段代碼的實(shí)際效果是前端把大文件切成多個(gè)小Blob每個(gè)獨(dú)立上傳服務(wù)端接收后按index順序合并。相比一次傳整個(gè)文件好處有三點(diǎn)第一避免大文件單請(qǐng)求超時(shí)。很多代理服務(wù)和網(wǎng)關(guān)對(duì)請(qǐng)求體大小和時(shí)間限制得非常死2MB一個(gè)的請(qǐng)求幾乎不會(huì)觸發(fā)超時(shí)。第二支持并發(fā)控制。可以把循環(huán)改成Promise.all限制同時(shí)3~5個(gè)請(qǐng)求實(shí)測(cè)上傳速度比串行快很多。第三具備斷點(diǎn)續(xù)傳的雛形。如果某個(gè)分片上傳失敗重新上傳失敗分片即可不需要整個(gè)文件重來。但這里有一個(gè)最容易遺漏的細(xì)節(jié)分片上傳時(shí)Blob切片返回的是一個(gè)視圖式的Blob它內(nèi)部引用的是原文件部分字節(jié)不是復(fù)制出來的獨(dú)立數(shù)據(jù)。也就是說原文件對(duì)象如果被垃圾回收切片切片可能出問題。因此分片期間必須保持原File對(duì)象引用不丟失。一些打包工具或?yàn)g覽器優(yōu)化可能會(huì)提前調(diào)整原Blob的生命周期所以最好把原文件也掛在作用域里或顯式保留引用。3.4 用Blob實(shí)現(xiàn)前端文件導(dǎo)出與下載Blob第三大高頻應(yīng)用場(chǎng)景是前端生成文件并下載。比如數(shù)據(jù)導(dǎo)出到CSV后端不參與純前端搞定。function exportCSV(data) { const rows data.map(row row.join(,)).join(\n); const blob new Blob([\uFEFF rows], { type: text/csv;charsetutf-8; }); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download 導(dǎo)出數(shù)據(jù).csv; a.click(); URL.revokeObjectURL(url); }這段代碼里的\uFEFF是BOM頭專門用來解決Excel打開CSV時(shí)中文亂碼的問題。不加BOMWindows上的Excel大概率以ANSI編碼解讀UTF-8的CSV中文直接變亂碼。加完BOMExcel才會(huì)正確識(shí)別為UTF-8。另一個(gè)細(xì)節(jié)是a.click()之后要立刻revoke嗎實(shí)踐中最好用setTimeout延遲到點(diǎn)擊事件完成后釋放或者干脆在下載事件響應(yīng)后釋放。有些瀏覽器在點(diǎn)擊事件同步執(zhí)行完之前釋放URL會(huì)導(dǎo)致下載失敗。穩(wěn)妥寫法a.onclick () setTimeout(() URL.revokeObjectURL(url), 1000);4. 工具選型與平臺(tái)差異這些坑不踩等于白學(xué)FileReader和Blob雖說是瀏覽器原生能力但在真正的項(xiàng)目中必須考慮兼容性、性能邊界、以及和現(xiàn)有框架的配合。4.1 兼容性現(xiàn)狀一個(gè)殘酷的事實(shí)FileReader在IE10才完整支持Blob和URL.createObjectURL更是要IE10。如果項(xiàng)目還要兼容IE9及以下這兩個(gè)API基本沒法用只能借助后端或者Flash方案——不過現(xiàn)在這么老的瀏覽器幾乎已經(jīng)絕跡這里只提一句考古?，F(xiàn)代瀏覽器中兩者的實(shí)現(xiàn)趨于一致但仍有微妙的差異new Blob()的構(gòu)造函數(shù)在Safari低版本上不支持需要PolyfillFileReader的readAsBinaryString被標(biāo)記廢棄不要使用URL.createObjectURL在部分Android WebView上生成的URL過期時(shí)間不穩(wěn)定必要時(shí)改用DataURL兜底我在一個(gè)混合開發(fā)項(xiàng)目里遇到過iOS的WKWebView對(duì)大Blob的objectURL支持很好但Android的X5內(nèi)核下URL.revokeObjectURL執(zhí)行時(shí)機(jī)稍晚就會(huì)導(dǎo)致內(nèi)存泄漏。最終的處理方案是統(tǒng)一用FileReader.readAsDataURL做圖片預(yù)覽雖然性能略差但平臺(tái)一致性更好。這個(gè)決策的依據(jù)是項(xiàng)目里圖片體積不大幾乎都在2MB以內(nèi)性能損耗在可接受范圍內(nèi)而平臺(tái)一致性直接決定了用戶體感。4.2 性能邊界與內(nèi)存管理FileReader和Blob的配合最容易出性能問題的是大文件全量讀進(jìn)內(nèi)存。比如一個(gè)200MB的壓縮包你調(diào)用readAsArrayBuffer想算MD5瞬間瀏覽器內(nèi)存上漲幾百M(fèi)B。不是不能做而是要控制并發(fā)、控制單次讀取量。我在實(shí)際項(xiàng)目中總結(jié)了一套經(jīng)驗(yàn)文件小于5MB直接readAsArrayBuffer讀全量無腦簡(jiǎn)單文件5MB~50MB先切片每片2MB逐片讀取并計(jì)算hash或上傳文件大于50MB必須結(jié)合file.slice分片且每讀完一片手動(dòng)把對(duì)應(yīng)的Blob引用置空另外一個(gè)被忽視的細(xì)節(jié)是FileReader讀大文件時(shí)result里的ArrayBuffer在讀取結(jié)束后不會(huì)被自動(dòng)釋放即使reader null也只是斷掉了引用。如果想強(qiáng)制回收內(nèi)存可以把reader.result也置空或主動(dòng)調(diào)用reader.abort()后再置空。實(shí)測(cè)在Chrome里reader null; reader.result null;之后堆內(nèi)存會(huì)明顯下降。4.3 FileReader與Blob對(duì)象的關(guān)系速查很多文檔把FileReader和Blob混在一起講導(dǎo)致新手搞不清誰是誰。我用一個(gè)小表格整理能力FileReaderBlob讀取文件內(nèi)容為文本支持readAsText不支持讀取文件為DataURL支持readAsDataURL不支持讀取為ArrayBuffer支持readAsArrayBuffer不支持生成臨時(shí)預(yù)覽URL不支持支持URL.createObjectURL切片不支持支持blob.slice構(gòu)造新文件不支持支持new Blob與FormData配合不能直接appendFile本身就是Blob子類可直接append這表格我背了很久。只要記住這兩句話FileReader負(fù)責(zé)從Blob/File里把字節(jié)讀出來Blob負(fù)責(zé)組織和切割數(shù)據(jù)本身。當(dāng)然File也繼承了Blob的一切能力所以file.slice能切file.type能查URL.createObjectURL(file)也能用。5. 實(shí)操環(huán)節(jié)一個(gè)文件預(yù)覽與分片上傳的綜合Demo講了這么多理論必須上點(diǎn)能直接抄的代碼。我拿一個(gè)典型的管理后臺(tái)文件管理系統(tǒng)場(chǎng)景舉例完成三件事圖片本地預(yù)覽、文本文件內(nèi)容讀取、大文件分片上傳。這三件事分別對(duì)應(yīng)FileReader的兩個(gè)方法和Blob切片。5.1 界面與交互設(shè)計(jì)頁面上有一個(gè)文件選擇框支持多選可以識(shí)別的文件類型包括圖片、文本、CSV。選擇后頁面分為三個(gè)區(qū)域圖片預(yù)覽區(qū)用URL.createObjectURL展示縮略圖文本內(nèi)容區(qū)用readAsText讀取并顯示文本內(nèi)容前1000個(gè)字符上傳進(jìn)度區(qū)無論什么文件都走分片上傳顯示進(jìn)度條這個(gè)設(shè)計(jì)瞄準(zhǔn)的是實(shí)際需求預(yù)覽是給用戶即時(shí)反饋的內(nèi)容讀取是為了前端本地校驗(yàn)比如檢查CSV表頭格式是否正確分片上傳是為了服務(wù)端接收大文件時(shí)更穩(wěn)定。5.2 核心代碼實(shí)現(xiàn)完整代碼貼出來可以直接放在一個(gè)HTML文件里跑!DOCTYPE html html langzh-CN head meta charsetUTF-8 / titleFileReader與Blob綜合實(shí)操/title /head body input typefile idfileInput multiple / h3圖片預(yù)覽/h3 div idpreview/div h3文本內(nèi)容/h3 pre idtextContent/pre h3上傳進(jìn)度/h3 div idprogress/div script const input document.getElementById(fileInput); const preview document.getElementById(preview); const textContent document.getElementById(textContent); const progress document.getElementById(progress); input.addEventListener(change, (e) { const files Array.from(e.target.files); files.forEach(handleFile); }); function handleFile(file) { // 根據(jù)type分流處理 if (file.type.startsWith(image/)) { previewImage(file); } else if (file.type.startsWith(text/) || file.type.includes(json) || file.type.includes(csv)) { readTextPreview(file); } uploadChunks(file); } function previewImage(file) { const url URL.createObjectURL(file); const img document.createElement(img); img.src url; img.style.maxWidth 200px; img.style.margin 8px; img.onload () URL.revokeObjectURL(url); preview.appendChild(img); } function readTextPreview(file) { const reader new FileReader(); reader.onload () { const str reader.result; // 只預(yù)覽前1000字符避免大文本卡頁面 textContent.textContent str.slice(0, 1000); // 檢測(cè)是否JSON并嘗試格式化 if (file.type.includes(json)) { try { const obj JSON.parse(str); textContent.textContent JSON.stringify(obj, null, 2); } catch (err) { textContent.textContent 解析JSON失敗 err.message; } } }; reader.onerror () { textContent.textContent 文件讀取失敗; }; reader.readAsText(file, UTF-8); } const CHUNK_SIZE 1 * 1024 * 1024; // 1MB一片 function sliceFile(file) { const chunks []; for (let start 0; start file.size; start CHUNK_SIZE) { const end Math.min(start CHUNK_SIZE, file.size); const chunk file.slice(start, end); chunks.push(chunk); } return chunks; } async function uploadChunks(file) { const chunks sliceFile(file); const total chunks.length; for (let i 0; i total; i) { // 模擬上傳實(shí)際上傳到后端接口 await simulateUpload(chunks[i], i, total, file.name); progress.textContent 文件 ${file.name}${i 1}/${total} 片; } } function simulateUpload(chunk, index, total, filename) { return new Promise((resolve) { setTimeout(() { console.log(第${index 1}/${total}片上傳完成大小${chunk.size}字節(jié)); resolve(); }, 200); }); } /script /body /html三個(gè)模塊的代碼都不復(fù)雜但組合起來就能覆蓋日常大部分文件處理需求。這個(gè)Demo我用在一個(gè)內(nèi)部的需求文檔上傳中心項(xiàng)目里當(dāng)時(shí)配合后端把接口對(duì)接好全流程跑得還算順利。5.3 實(shí)操中發(fā)現(xiàn)的關(guān)鍵問題第一個(gè)問題是input的multiple屬性配合文件校驗(yàn)時(shí)用戶可能一次選多種類型文件導(dǎo)致預(yù)覽區(qū)卡片混排。我后來加了分組渲染每種類型一個(gè)卡片組UI更清晰。第二個(gè)問題是文本預(yù)覽的編碼問題。瀏覽器通過file.type判斷文本類型是靠擴(kuò)展名和后端返回的MIME但CSV文件的編碼經(jīng)常是GBKreadAsText(file, UTF-8)讀到一半亂碼。我后來加了一個(gè)降級(jí)策略如果檢測(cè)到亂碼字符\uFFFD就用TextDecoder(gb18030)重新解碼ArrayBuffer。這個(gè)坑在實(shí)際業(yè)務(wù)里太常見了。function decodeText(buffer, fallbackEncoding) { try { return new TextDecoder(fallbackEncoding).decode(buffer); } catch (e) { return new TextDecoder(utf-8).decode(buffer); } }第三個(gè)問題是分片上傳時(shí)Excel等二進(jìn)制文件其實(shí)沒必要去預(yù)覽但業(yè)務(wù)要求選中文件后立即反饋。所以我在上傳前會(huì)先顯示文件大小和類型元信息再異步做預(yù)覽和讀取避免阻塞流程。6. 進(jìn)階FileReader和Blob與現(xiàn)代框架如何共存現(xiàn)在的項(xiàng)目基本都用了React、Vue或小程序框架。FileReader和Blob本質(zhì)上屬于瀏覽器原生能力框架層面沒有特殊適配但組合使用時(shí)依然有幾個(gè)值得留意的配合點(diǎn)。6.1 在React/Vue中的狀態(tài)管理Blob對(duì)象和FileReader實(shí)例都不是React狀態(tài)也不應(yīng)該放進(jìn)state里。因?yàn)锽lob可能很大放進(jìn)去會(huì)造成不必要的渲染和內(nèi)存拷貝。正確做法是File對(duì)象放在ref里引用讀取結(jié)果只把字符串或ArrayBuffer放入state。我在React項(xiàng)目里寫過類似這種代碼const [text, setText] useState(); const fileRef useRef(null); const handleChange (e) { fileRef.current e.target.files[0]; const reader new FileReader(); reader.onload () setText(reader.result); reader.readAsText(fileRef.current, UTF-8); };這個(gè)細(xì)節(jié)看似簡(jiǎn)單實(shí)際很多人把File對(duì)象直接setState然后發(fā)現(xiàn)輸入框的值還是空的因?yàn)镕ile對(duì)象的引用變了導(dǎo)致內(nèi)部狀態(tài)混亂。保持File對(duì)象引用不變結(jié)果字符串走state是最穩(wěn)的配合姿勢(shì)。在Vue3的setup里同理用shallowRef或者普通ref都可以但注意不要在computed里直接引用Blob對(duì)象做派生計(jì)算——每次依賴變化都會(huì)重新讀文件性能極差。6.2 小程序端的局限性再提一句小程序。小程序里沒有標(biāo)準(zhǔn)FileReader和Blob但微信小程序提供了wx.getFileSystemManager().readFile支付寶小程序有自己的my.readFile。整體能力對(duì)標(biāo)FileReader但細(xì)節(jié)差異很大尤其是編碼和路徑處理。如果你的團(tuán)隊(duì)同時(shí)做Web端和小程序端建議封裝一層統(tǒng)一的文件讀取接口Web端用FileReader小程序端用各自API上層業(yè)務(wù)邏輯保持一致。我參與過一個(gè)跨端項(xiàng)目最初直接在小程序里用Web的思維寫文件處理結(jié)果到處踩坑小程序讀取的是本地臨時(shí)文件路徑不是File對(duì)象讀取JSON必須指定encoding為utf8讀取ArrayBuffer后要轉(zhuǎn)字符串需要ArrayBuffer → Uint8Array → String.fromCharCode的方法鏈。后來統(tǒng)一封裝成async readText(path)和async readArrayBuffer(path)兩個(gè)方法才把兩端的復(fù)雜度隔離掉。6.3 與裝載器的配合再說一個(gè)容易被忽略的場(chǎng)景FileReader讀取的文件如果最終要傳給后端用FormData時(shí)不需要自己讀內(nèi)容直接formData.append(file, file)就行。只有要讀取內(nèi)容做預(yù)覽或校驗(yàn)時(shí)才需要FileReader。很多新手把上傳文件和讀取文件混為一談以為不上傳就不需要FileReader或者以為上傳前必須先讀取。其實(shí)上傳是底層協(xié)議的事瀏覽器會(huì)自己讀文件流前端只需要把File對(duì)象交給FormData或fetch的Body即可。理解這個(gè)邊界之后代碼寫起來會(huì)清晰非常多。FileReader用于我要看、我要算、我要改、我要校驗(yàn)的場(chǎng)景Blob用于我要切、我要拼、我要臨時(shí)URL、我要生成文件的場(chǎng)景。兩者合起來前端文件操作的全拼圖才完整。我在實(shí)際項(xiàng)目中還發(fā)現(xiàn)一個(gè)隱藏技巧用FileReader.readAsArrayBuffer讀取文件后配合CryptoJS或?yàn)g覽器內(nèi)置的crypto.subtle.digest計(jì)算文件SHA256在前端做文件去重、秒傳判定完全可行。這塊如果大家感興趣我后續(xù)可以單獨(dú)寫一篇前端計(jì)算大文件哈希的工程化方案。7. 常見問題排查與避坑速查表最后把這段時(shí)間實(shí)戰(zhàn)中高頻遇到的坑集中列出來給讀者當(dāng)速查手冊(cè)。這些問題每一個(gè)我都實(shí)際碰過有些甚至排查了整整一天。7.1 高頻報(bào)錯(cuò)與解決方案報(bào)錯(cuò)/現(xiàn)象根因解決方案reader.result為null讀取還沒完成就取值等onload觸發(fā)后再取讀取JSON中文亂碼編碼指定錯(cuò)誤或源文件非UTF-8readAsText時(shí)指定GB18030或用TextDecoder降級(jí)URL.createObjectURL后圖片不顯示revoke時(shí)機(jī)太早在img.onload后再revoke大文件上傳瀏覽器崩潰全量讀取ArrayBuffer分片、限制每次讀取量Blob轉(zhuǎn)File時(shí)lastModified丟失未顯式賦值new File([blob], name, {lastModified})分片上傳后文件合并損壞切片時(shí)end計(jì)算錯(cuò)誤使用Math.min(startsize, file.size)readAsDataURL內(nèi)存暴漲Base64膨脹33%改用objectURLSafari下new Blob報(bào)錯(cuò)低版本不支持構(gòu)造參數(shù)引入Blob Polyfill或改用File對(duì)象7.2 實(shí)戰(zhàn)排錯(cuò)實(shí)錄有一次線上反饋用戶上傳的CSV文件在預(yù)覽時(shí)前幾行正常后面全亂碼。排查過程是這樣的第一步懷疑編碼但全文件前幾行正常后面亂不太像整體編碼問題。第二步懷疑文件太大但文件只有3MB不至于卡。第三步直接用ArrayBuffer讀出來發(fā)現(xiàn)亂碼集中在某一行之后。仔細(xì)對(duì)比發(fā)現(xiàn)這一行恰好是某個(gè)字段里出現(xiàn)了一個(gè)特殊字符。最終定位文件里包含的某個(gè)特殊字符被瀏覽器判定為二進(jìn)制數(shù)據(jù)導(dǎo)致FileReader的文本解碼在那一行中斷。解決方法是改用readAsArrayBuffer讀取全量再用TextDecoder異步分塊解碼。這種問題單純看文檔根本發(fā)現(xiàn)不了必須動(dòng)手讀字節(jié)才能定位。還有一次遇到預(yù)覽PDF時(shí)白屏。排查發(fā)現(xiàn)URL.createObjectURL(blob)在Safari下能生成URL但WebView的PDF預(yù)覽組件不支持blob協(xié)議。最終方案是改用readAsDataURL生成DataURL遞給PDF預(yù)覽組件同時(shí)通過window.open打開新窗口預(yù)覽。這類兼容性適配經(jīng)驗(yàn)只能靠踩坑積累。7.3 一些寫在代碼注釋里的經(jīng)驗(yàn)最后分享幾條我每次寫文件處理代碼時(shí)都會(huì)遵守的約定所有FileReader實(shí)例用完后置空引用尤其循環(huán)讀取時(shí)創(chuàng)建ObjectURL后必須配套revoke可以用try/finally保證文本讀取優(yōu)先使用TextDecoder而非readAsText因?yàn)榍罢咧С址謮K解碼和按需結(jié)束字符串文件大小校驗(yàn)放在所有讀取動(dòng)作之前避免內(nèi)存浪費(fèi)處理超大文件時(shí)用requestIdleCallback分批處理Blob切片避免長(zhǎng)時(shí)間占用主線程這些約定看著瑣碎但長(zhǎng)期堅(jiān)持下來項(xiàng)目的穩(wěn)定性提升非常明顯。我見過太多功能能跑但一到大文件就崩的代碼基本都是在這幾個(gè)細(xì)節(jié)上偷懶導(dǎo)致的。文件操作雖然只是前端的一小部分但FileReader和Blob這對(duì)組合掌握好之后前面那些只能靠后端的需求會(huì)少一大半。下次再遇到文件預(yù)覽、分片上傳、本地導(dǎo)出別急著向后端求助先在瀏覽器里把數(shù)據(jù)的來龍去脈摸清楚。