大文件上傳真正讓人頭禿的通常不是文件本身太大而是“平臺太多”。我這兩年一直在做上傳相關(guān)的功能從幾個MB的辦公文檔到幾十GB的現(xiàn)場視頻都碰過最深的體會是同一套代碼在 Windows Chrome 上跑得飛快到了 macOS Safari、安卓微信內(nèi)置瀏覽器、甚至某些國產(chǎn)瀏覽器上就可能出現(xiàn)分片錯位、Worker 不工作、進度條卡死、合并失敗等等問題。所以大文件上傳里的“多平臺兼容性”本質(zhì)不是“能不能傳”而是“分片、并發(fā)、斷點續(xù)傳、秒傳、進度反饋”這條完整鏈路在每個目標平臺上都要保持穩(wěn)定可預(yù)期。今天這篇就聊聊我實際怎么討論和解決這個問題。核心思路很明確前端用 Web Worker 做分片和調(diào)度后端用 MinIO 作為對象存儲配合預(yù)簽名 URL 做多部分上傳。文章會講清楚平臺差異在哪里、為什么要這樣選型、具體怎么落地以及我在真實環(huán)境里踩過的兼容性坑。1. 多平臺兼容性到底在兼容什么1.1 平臺差異的四個維度瀏覽器、設(shè)備、網(wǎng)絡(luò)、存儲服務(wù)要討論兼容性先把“平臺”這個概念拆開。實際項目里一個用戶真正面對的平臺不是單一瀏覽器而是四層結(jié)構(gòu)的組合。第一層是瀏覽器層Chrome、Edge、Safari、Firefox以及微信、釘釘、快手這類內(nèi)置瀏覽器。它們對 HTML5 File API、Blob.slice()、Web Worker、XMLHttpRequest/fetch 的支持程度差別很大。第二層是設(shè)備層PC 上的內(nèi)存和 CPU 通常不是問題但手機端尤其低端安卓機讀取一個大文件就可能內(nèi)存告急Web Worker 也更容易崩潰。第三層是網(wǎng)絡(luò)層家庭寬帶、移動 4G/5G、企業(yè)代理、校園網(wǎng)不同網(wǎng)絡(luò)環(huán)境下的分片大小、并發(fā)數(shù)、超時時間都要跟著調(diào)整。第四層是存儲服務(wù)層MinIO、公有云對象存儲、自建 NFS 都會有自己的一套上傳接口和簽名機制兼容性不只是前端單方面的事。我通常建議團隊在討論兼容性之前先拉一張“目標平臺矩陣”。沒有這個矩陣討論就會變成各說各話。比如只做 To B 內(nèi)部系統(tǒng)那 Chrome 90 以上就夠了沒必要遷就 IE但如果是面向公眾的產(chǎn)品微信內(nèi)置瀏覽器和 iOS Safari 就是必須覆蓋的。矩陣一般寫成這樣平臺內(nèi)核需要支持的功能優(yōu)先級Windows ChromeBlinkWorker、分片、斷點續(xù)傳P0macOS SafariWebKitWorker、分片、內(nèi)存控制P0iOS 微信內(nèi)置瀏覽器WebKit分片、Safari 兼容P0Android ChromeBlinkWorker、低內(nèi)存處理P1國產(chǎn)瀏覽器360/QQChromium標準模式P1IE11Trident不做或降級整文件上傳P3這個矩陣一列后面所有技術(shù)決策都有了依據(jù)。要不要用最新的 File System Access API要不要支持 fetch 流式上傳都會因為這個矩陣里“必須兼容 Safari / 微信”而自動否決或調(diào)整。所以多平臺兼容性討論的第一步永遠不是選庫而是定范圍。1.2 兼容性問題的表象與本質(zhì)從分片、并發(fā)說起大文件上傳幾乎都會選擇分片。原因很簡單一個 1GB 文件一次性 POST 到服務(wù)器任何一個環(huán)節(jié)出問題都要重新來而且后端內(nèi)存、代理緩沖、連接超時都扛不住。分片之后每片幾 MB傳到一半斷了可以續(xù)傳進度條可以精確到百分比后端還能基于分片做秒傳校驗和并行處理。但“分片”這種看似樸素的做法在不同平臺上的表現(xiàn)其實很不一樣。最典型的是 Blob.slice() 的邊界處理。早期 Safari 對 slice() 的支持有兼容問題有些舊版本不支持或者從一個 File 對象連續(xù)切分時內(nèi)容會錯位。還有 FileReader.readAsArrayBuffer() 讀取大文件時在 iOS Safari 上很容易把內(nèi)存打滿最后 WebView 直接崩潰。所以本質(zhì)上多平臺兼容性討論的不是“功能有沒有”而是“同一套分片流程在不同平臺上的資源表現(xiàn)是否一致”。現(xiàn)代瀏覽器對 File 對象的支持已經(jīng)比較統(tǒng)一但 Web Worker 在移動端的不穩(wěn)定性、XHR 上傳大文件時的進度事件頻率、瀏覽器對同域名并發(fā)連接數(shù)的限制這些才是真正的差異點。討論的時候要把這些“隱藏差異”擺到臺面上來否則上線后一定會被用戶逐個踩中。1.3 明確討論邊界哪些平臺組合需要優(yōu)先支持討論大文件上傳兼容性最容易犯的錯就是試圖覆蓋所有平臺。我的經(jīng)驗是世界上不存在“所有平臺都完美”的上傳方案只存在“在目標平臺上表現(xiàn)穩(wěn)定”的方案。所以開討論會的第一步不是寫代碼而是拉上產(chǎn)品、測試一起把平臺清單定下來。優(yōu)先考慮用戶量最大的平臺一般就是 Windows Chrome 和 Android 微信內(nèi)置瀏覽器先保證這兩種。接著確認文件類型和大小范圍視頻平臺單文件可能 1GB 到 20GB文檔平臺可能幾百 MB這直接決定分片大小和并發(fā)策略。再考慮弱網(wǎng)和斷點續(xù)傳的優(yōu)先級移動端用戶經(jīng)常鎖屏、切后臺必須支持斷點續(xù)傳內(nèi)網(wǎng)辦公環(huán)境則沒那么緊迫。邊界一定下來很多“要不要兼容”的爭論自然結(jié)束。比如有人提出要用 IndexedDB 緩存分片如果目標平臺都是現(xiàn)代瀏覽器可以做但如果還要兼容舊版微信的 X5 內(nèi)核就果斷放棄。這里沒有絕對的對錯只有目標平臺矩陣支不支持的問題。2. 核心技術(shù)方案選型worker、分片與對象存儲2.1 前端為什么需要 Web Worker 加載大文件上傳大文件上傳如果全部放在主線程頁面的滾動、點擊會卡頓嚴重時瀏覽器直接提示“腳本無響應(yīng)”。尤其是每個分片的切分、MD5 計算、讀取文件內(nèi)容全部是 CPU 密集和內(nèi)存密集操作。用 Web Worker 把這些操作移到后臺線程主線程只負責更新進度條和響應(yīng)用戶交互體驗完全不一樣。這也是“前端使用 worker 上傳大文件”這個熱詞背后的核心原因。拿我做過的一個視頻上傳項目舉例單文件平均 5GB。最開始版本直接在主線程里用 FileReader 讀取并切分Chrome 上還能忍受但 Safari 上頁面基本變成幻燈片。換成 Worker 之后切分、Hash 計算、隊列調(diào)度都在 Worker 里跑主線程幾乎沒有壓力。Worker 的使用有幾個要點主線程通過 postMessage 把 File 對象傳給 Worker注意是傳引用不是復(fù)制數(shù)據(jù)Worker 里用 File 對象的 slice() 方法切分再用 arrayBuffer() 讀取Worker 里不要操作 DOM進度結(jié)果通過 postMessage 回傳移動端部分瀏覽器對 Worker 的內(nèi)存有嚴格限制不能無節(jié)制地創(chuàng)建多個 Worker一般一個上傳任務(wù)對應(yīng)一個 Worker 就夠了。// main.js 簡化示意 const worker new Worker(./upload-worker.js); worker.postMessage({ file, chunkSize: 8 * 1024 * 1024 }); worker.onmessage (e) { const { type, data } e.data; if (type progress) { updateProgressUI(data.percent); } if (type done) { notifyUploadComplete(data.fileId); } };別小看這一步。很多團隊上來直接寫上傳組件遇到性能問題才想起 Worker。我建議大文件上傳從第一版就把 Worker 放進去后面能少折騰很多。等線上出了問題再改涉及的結(jié)構(gòu)調(diào)整更大而且很難證明回退有沒有引入新問題。2.2 分片策略與并發(fā)控制怎么定分片大小和并發(fā)數(shù)是兼容性討論里的核心參數(shù)但很多人都是拍腦袋定的。一個穩(wěn)妥的做法是“動態(tài)估算 平臺系數(shù)”先測一次當前網(wǎng)絡(luò)速度再根據(jù)文件大小和網(wǎng)絡(luò)狀態(tài)動態(tài)調(diào)整分片大小和并發(fā)數(shù)。分片大小常規(guī)是 2MB 到 16MB。選得太小分片數(shù)量巨大后端和隊列開銷高選得太大斷點續(xù)傳粒度粗出錯重傳代價大。我一般取 4MB 或 8MB 作為基線。并發(fā)數(shù)方面瀏覽器對同域名并發(fā)連接數(shù)有限制HTTP/1.1 下 Chrome 是 6 個HTTP/2 雖然可以多路復(fù)用但上傳場景不一定都走 H2移動端網(wǎng)絡(luò)波動也大。所以并發(fā)建議控制在 3 到 6 之間。并發(fā)控制直接用簡單的信號量實現(xiàn)即可不需要引入復(fù)雜框架。Worker 線程里維護一個任務(wù)隊列最多同時執(zhí)行 N 個上傳請求每完成一個就從隊列取下一個。為什么不讓所有分片同時發(fā)因為無腦并發(fā)會讓弱網(wǎng)環(huán)境下的失敗率直線上升服務(wù)端容易被沖垮進度條也容易亂跳。重試策略同樣要在設(shè)計階段想清楚。分片上傳失敗后要區(qū)分原因網(wǎng)絡(luò)中斷可以指數(shù)退避重試服務(wù)器返回 4xx 要檢查參數(shù)不再重試5xx 可以適當重試。我在項目里寫了一個重試計數(shù)器最多重試 3 次超過就把分片標記為失敗整體上傳中止并給出可續(xù)傳的提示。這個策略在各平臺上都要一致否則會出現(xiàn) Android 上重試成功、iOS 上直接退出這種詭異差異。2.3 MinIO 作為后端存儲時大文件方案怎么搭MinIO 是一個開源的高性能對象存儲兼容 S3 API。很多團隊把它當私有化的對象存儲來用。處理大文件上傳時MinIO 本身有兩條典型路徑一是客戶端直接分片上傳到 MinIO走 S3 的多部分上傳接口二是先傳到自己的應(yīng)用服務(wù)器再由服務(wù)器轉(zhuǎn)存到 MinIO。前者鏈路短、性能好后者方便做強校驗和額外業(yè)務(wù)邏輯但會增加服務(wù)器的帶寬壓力。我們在實操中選了前者 預(yù)簽名 URL 的方式。前端拿到一個帶權(quán)限的預(yù)簽名 URL直接把分片 PUT 到 MinIO應(yīng)用服務(wù)器不中轉(zhuǎn)文件數(shù)據(jù)只負責生成簽名、記錄分片狀態(tài)。這樣做的好處很直接幾十 GB 的視頻上傳不會壓垮業(yè)務(wù)服務(wù)器MinIO 本身的吞吐能力就是上限。MinIO 多部分上傳的核心流程是這樣的先調(diào)用初始化接口拿到 uploadId然后按分片編號逐個 PUT每個分片返回 ETag最后所有分片完成后攜帶 uploadId 和 Part 列表調(diào)用合并接口MinIO 自動把分片合并成最終對象。這個流程天然支持斷點續(xù)傳和并發(fā)只是業(yè)務(wù)層必須自己維護每個分片的上傳狀態(tài)。因為 MinIO 兼容 S3 API代碼不綁定廠商之后切公有云對象存儲也基本能復(fù)用。2.4 為什么選擇 MinIOS3 兼容接口的價值選擇 MinIO 不是因為它多炫而是它在“多平臺兼容”這個命題上能幫你省掉大量適配工作。S3 API 已經(jīng)是對象存儲事實標準MinIO、AWS S3、阿里云 OSS、騰訊云 COS 都有類似的多部分上傳接口。如果后端用的是 MinIO前端按 S3 的協(xié)議寫以后要遷到公有云只需要換 Endpoint 和簽名邏輯分片、合并、斷點續(xù)傳的代碼幾乎不用動。另外MinIO 對分片上傳的原生支持很好能自動處理超過 5GB 的對象還有生命周期管理、版本控制等能力對視頻素材、日志歸檔這些場景很實用。我們選擇 MinIO 還有一個現(xiàn)實原因團隊希望數(shù)據(jù)留在內(nèi)網(wǎng)不把所有文件都交給公有云。MinIO 部署簡單Docker 一條命令就能起一個單機實例后續(xù)要擴展到分布式也方便。不過要注意MinIO 單機模式下磁盤故障沒有冗余生產(chǎn)環(huán)境至少要用分布式模式或者掛可靠的存儲。這個小細節(jié)跟兼容性關(guān)系不大但屬于大文件方案里必須考慮的高可用問題。討論多平臺兼容時很容易只盯著前端忘了后端存儲如果沒有冗余所有兼容性努力都是白費。3. 實操一套可落地的多平臺兼容大文件上傳方案3.1 前端模塊分片、Hash、Worker 調(diào)度現(xiàn)在把前面的選擇串起來給一個可以直接落地的前端模塊設(shè)計。整體分四層文件選擇層負責接收 File 對象并做類型、大小校驗切片層在 Worker 里按固定大小切片并為每個分片計算 MD5調(diào)度層維護待傳隊列控制并發(fā)處理重試和錯誤傳輸層用 XMLHttpRequest 把分片 PUT 到預(yù)簽名 URL并監(jiān)聽上傳進度。核心的切片代碼大致長這樣// upload-worker.js self.onmessage async (e) { const { file, chunkSize, uploadId, presignUrls } e.data; const totalChunks Math.ceil(file.size / chunkSize); for (let i 0; i totalChunks; i) { const start i * chunkSize; const end Math.min(start chunkSize, file.size); const chunk file.slice(start, end); // 實際項目里這里應(yīng)該用 fetch/XHR PUT 到 presignUrls[i] await uploadChunk(chunk, i 1); self.postMessage({ type: progress, loaded: end, total: file.size }); } self.postMessage({ type: done }); };上傳動作放在 Worker 里還是主線程我習(xí)慣把分片和 Hash 放 Worker網(wǎng)絡(luò)請求放主線程。因為 XMLHttpRequest 的進度事件在主線程處理更直觀而且網(wǎng)絡(luò)請求本身不阻塞 UI。如果硬要在 Worker 里用 fetchSafari 對 Worker 中 fetch 的支持已經(jīng)沒問題但調(diào)試起來會多一層麻煩。Hash 計算是另一個兼容性隱形坑。用 SparkMD5 計算大文件 MD5在低端安卓機上可能耗時幾十秒。為了不卡主線程我也會把 Hash 放到 Worker 里。再進階一點可以抽樣算 Hash也就是只讀取文件首尾和中間若干塊計算一個近似指紋用于秒傳判斷。抽樣 Hash 在絕大多數(shù)場景足夠用但“極小概率碰撞”是否需要接受要由產(chǎn)品和后端一起拍板。3.2 后端 MinIO 接入預(yù)簽名 URL 與分片合并后端如果用 Node.js接入 MinIO 的核心是兩件事生成預(yù)簽名 URL、記錄分片狀態(tài)。以 minio 包的接口為例代碼大概是這樣的import { Client } from minio; const minioClient new Client({ endPoint: minio.example.com, port: 9000, useSSL: false, accessKey: process.env.MINIO_ACCESS_KEY, secretKey: process.env.MINIO_SECRET_KEY, }); // 創(chuàng)建多部分上傳任務(wù) async function createMultipartUpload(bucket, objectName) { return await minioClient.initiateNewMultipartUpload(bucket, objectName); } // 生成某個分片的預(yù)簽名 PUT URL async function getPresignedPartUrl(bucket, objectName, uploadId, partNumber) { return await minioClient.presignedPutObjectPart( bucket, objectName, uploadId, partNumber, 60 * 60 ); }每次上傳分片都從后端拿一個預(yù)簽名 URL還是批量拿一批我建議批量獲取減少 HTTP 請求。前端一次拿 50 個或 100 個分片的預(yù)簽名 URL放在內(nèi)存里用用完再繼續(xù)拿。這樣既安全又高效。預(yù)簽名 URL 的有效期要設(shè)置合理我一般設(shè) 1 小時長時間大文件上傳建議支持刷新 URL或者用短期憑證重新簽名。分片全部上傳完成后前端需要把每個分片的 PartNumber 和 ETag 列表交給后端后端調(diào)用合并接口。合并本身是 MinIO 內(nèi)部操作幾十 GB 的文件通常幾秒到十幾秒完成但大文件合并可能耗時較長所以要給合并請求設(shè)置更長的超時時間。我們這里用同步方式等 complete 接口返回即可前端請求超時不要用默認的 10 秒至少要放到 30 秒以上。3.3 斷點續(xù)傳與秒傳的實現(xiàn)思路斷點續(xù)傳的關(guān)鍵是“已上傳的分片狀態(tài)能恢復(fù)”。最容易實現(xiàn)的方式是后端在數(shù)據(jù)庫里記錄每個 uploadId 對應(yīng)的已上傳分片集合。前端重新打開頁面時請求后端拿到已上傳分片列表上傳前做一次過濾只傳缺失的分片。秒傳依賴文件指紋。前端在 Worker 里計算文件 Hash可以是全文 MD5也可以是抽樣 Hash上傳前先調(diào)用后端接口問一下這個 Hash 對應(yīng)的文件是否已存在。如果存在且校驗后內(nèi)容一致直接返回已有文件 ID前端提示“秒傳成功”。如果不存在再走分片流程。這一步的兼容性細節(jié)在于“Hash 算法”和“編碼格式”。不同設(shè)備算出的 Hash 必須一致所以哈希算法一定要固定比如統(tǒng)一用 MD5 hex 字符串。iOS 和 Android 上 FileReader 讀取分片的二進制結(jié)果理論上應(yīng)該一致但我遇到過部分舊版本手機上 arrayBuffer 的 byteOffset 不一致導(dǎo)致讀取內(nèi)容錯亂的案例。所以分片的 Hash 算出來之后還要讓后端校驗分片長度和內(nèi)容不能只信任前端上報的 Hash。斷點續(xù)傳還涉及一個容易被忽略的點分片狀態(tài)記錄必須和后端實際存儲保持一致。如果前端說某個分片傳完了但后端沒記上合并時就會缺片。我建議在每次分片上傳成功后后端先記錄再返回成功響應(yīng)前端拿到成功響應(yīng)后才更新本地狀態(tài)。這樣即使中間某個請求丟失下次續(xù)傳時也能靠后端狀態(tài)兜底。3.4 兼容性配置清單從 browser 到 SDK 版本這里給出我每次做兼容性適配都會過一遍的配置項配置項推薦值/處理原因Blob.slice使用特性檢測不支持則降級整文件上傳舊 Safari / IEWeb Worker檢測構(gòu)造器是否存在舊瀏覽器會直接調(diào)用失敗FileReader優(yōu)先用 arrayBuffer()兼容用 readAsArrayBuffer部分 WebViewfetch / XHR統(tǒng)一用 XHR進度事件更穩(wěn)Safari 的 fetch 超時控制有坑并發(fā)數(shù)動態(tài) 3~6瀏覽器連接數(shù)限制分片大小4MB~8MB平衡性能和斷點粒度HTML5 File API強制要求否則提示升級瀏覽器沒有 File API 就沒有分片分片 PUT 超時5~10 分鐘弱網(wǎng)大分片需要更長等待合并接口超時30 分鐘以上大對象合并耗時長列這個清單的目的不是讓你照抄而是作為討論兼容性時的共同語言。每個團隊的產(chǎn)品形態(tài)不同配置項可以調(diào)整但“必須有一條明確的檢查鏈”這件事是通用的。沒有這條檢查鏈你在群里說的“兼容性問題”和客戶端反饋的“傳不了”很可能根本不是同一個問題。4. 常見兼容性雷區(qū)與排查實錄4.1 我在實際項目中踩過的五個平臺坑第一個坑是 iOS Safari 的 slice 邊界錯位。當時用 File.slice(start, end) 切分在 iOS 13 的某個版本上切出來的分片內(nèi)容偶爾會整體偏移幾個字節(jié)導(dǎo)致后端 MD5 校驗總失敗。后來排查發(fā)現(xiàn)是瀏覽器版本的一個已知問題更新系統(tǒng)后消失。應(yīng)對辦法是上傳后后端必須做分片大小和 MD5 校驗校驗失敗就標記該分片重傳。第二個坑是微信內(nèi)置瀏覽器的 Worker 不穩(wěn)定。在部分 Android 微信 X5 內(nèi)核里Worker 偶發(fā)創(chuàng)建失敗而且沒有任何報錯。我后來在前面加了一層降級邏輯如果 Worker 不可用就回到主線程執(zhí)行切片。性能會差一些但功能可用用戶不會因為“傳不了”而卡在那里。第三個坑是低端安卓機的內(nèi)存溢出。大文件在部分華為或小米瀏覽器上讀取整個 ArrayBuffer會把頁面直接搞崩。解決方法是按分片讀用完立即釋放同時避免在同一時間把多個分片的 ArrayBuffer 都駐留在內(nèi)存中。這個在 PC 上幾乎不用考慮但移動端必須當回事。第四個坑是 Chrome 的并發(fā)連接數(shù)限制。用 HTTP/1.1 時單域名 6 個并發(fā)連接如果同時開多個上傳任務(wù)后面的任務(wù)會一直排隊用戶以為頁面卡死。解決方法是上傳任務(wù)串行或者給不同任務(wù)分配不同子域名。但子域名又會引入新的 CORS 和 DNS 復(fù)雜度所以我的默認方案是任務(wù)排隊最多同時發(fā)兩個任務(wù)。第五個坑是企業(yè)網(wǎng)絡(luò)代理對 PUT 方法的限制。有些內(nèi)網(wǎng)代理會攔截 PUT 請求導(dǎo)致分片總是失敗。我們沒法完全繞過但加了一個備用通道當 PUT 連續(xù)失敗時降級為 POST 到應(yīng)用服務(wù)器再由服務(wù)器轉(zhuǎn)發(fā)到 MinIO。這個通道慢一些但能保證用戶在大文件上傳時不中斷。類似的失敗處理邏輯最好做成可配置的不要寫死在代碼里。4.2 問題排查工具與方法排查大文件上傳兼容性問題最有效的手段是抓請求級證據(jù)。先打開 DevTools 的 Network 面板按“大圖”模式看每個分片請求的狀態(tài)碼、耗時和響應(yīng)。多數(shù)兼容性問題在 Network 面板上會直接暴露某個分片一直 pending、某個請求返回 CORS 錯誤、某個請求超時。CORS 是大文件上傳跨域場景的?？?。前端 PUT 到 MinIO 預(yù)簽名 URL如果 MinIO 的 CORS 配置沒寫好瀏覽器會攔截響應(yīng)。我一般這樣配置允許來源是業(yè)務(wù)域名允許方法包含 PUT、POST、GET允許請求頭包含 Content-Type、ETag、Authorization同時暴露響應(yīng)頭 ETag。為什么必須暴露 ETag因為合并時需要拿到每個分片的 ETag 再交給后端如果前端 JS 讀取不到這個流程就走不下去。另一個有效工具是本地代理抓包。線上環(huán)境遇到問題我常用 Whistle 或 Charles 把上傳請求轉(zhuǎn)發(fā)到測試環(huán)境同時記錄每個分片的請求頭和響應(yīng)體。有了原始請求定位是瀏覽器問題、網(wǎng)絡(luò)問題還是后端接口問題就快很多。如果條件允許再給線上的上傳模塊加一個“調(diào)試日志開關(guān)”把設(shè)備 UA、瀏覽器版本、分片大小、請求狀態(tài)都打出來。這是排查線上兼容性問題最省力的辦法不要等到用戶反饋了才臨時加日志。4.3 兼容性驗證清單上線前必須過一遍真機測試比任何模擬器都靠譜。我每次上線前都會拿著同一份大文件在下面的組合里跑一遍Windows Chrome 加 HTTP/1.1、Windows Edge 加 HTTP/2、macOS Safari、iPhone Safari、iPhone 微信、安卓低端機 Chrome以及一個企業(yè)內(nèi)網(wǎng)環(huán)境。每個組合都要驗證分片上傳正常、進度條平滑、刷新后續(xù)傳成功、合并后文件 MD5 與源文件一致。一個容易被忽略的點是“上傳過程中頁面切換后臺”。移動端切后臺后網(wǎng)絡(luò)請求會被掛起回到前臺后很多瀏覽器不會自動恢復(fù)。我們通常監(jiān)聽 visibilitychange 事件回到前臺后重新檢查未完成的分片并重發(fā)。這個問題在 iOS Safari 上尤其明顯鎖屏幾分鐘再回來幾乎所有請求都會斷開。這套清單不復(fù)雜但能擋住 90% 的兼容性回歸。我剛做上傳功能時總想在代碼層一次搞定所有平臺后來發(fā)現(xiàn)更實際的做法是先把矩陣和驗證清單定死代碼按清單適配剩下的交給自動化測試和真機回歸。兼容性不是靠某一次優(yōu)化達到的而是靠每一次版本迭代前老老實實地過一遍清單把新平臺暴露出來的問題及時補進去。