Blob文件流下载这六个字，最早出现在我手里的时候，是一句很敷衍的工单描述：“导出按钮点了没反应，用户说换浏览器就好了”。翻代码才发现，导出接口走的是 POST，带一堆筛选条件，后端直接Content-Type: application/octet-stream吐二进制回来，前端拿到手却用JSON.parse去解析响应体，控制台一水儿的乱码加一个红色报错。这类问题在后台系统、报表中心、文件管理模块里出现的频率高得离谱，几乎每个做中后台的前端都会撞上一次。所谓 Blob 文件流下载，说白了就是把后端返回的二进制数据在浏览器内存里接住，包成一个 Blob 对象，再借一个临时的对象地址把它“骗”成本地文件存下来。它解决的核心矛盾很具体：当下载地址不能提前拼好、必须带鉴权头、必须走 POST 传参、或者文件是后端实时生成的时候，传统的<a href="xxx">直链就彻底失效了，只剩这条路能走。这篇东西写给已经写过几版导出代码但总在小地方翻车的同学，也写给刚接手一个导出需求、还没搞清楚arraybuffer和blob该选哪个的新人，下面全是我在几个实际项目里反复验证过的做法和踩过的坑。

1. 先把问题定义清楚：Blob 文件流下载到底绕开了什么

1.1 直链下载失效的四种典型现场

很多人对下载的直觉还停留在“给个地址就行”，这个直觉在静态资源站成立，在业务系统里几乎必然翻车。第一种现场是鉴权。后端接口要求请求头里带 token，而浏览器原生下载走的是独立的导航请求，不会带上你 axios 拦截器里塞的那些 header，结果就是 401。第二种现场是参数体积。导出条件里勾了三十个组织节点、七八个筛选项，拼成 query string 短的两千字符往上，长的直接顶到浏览器和网关的 URL 长度上限，日志里的报错是 414。第三种现场是文件是临时生成的。报表要跑几十秒聚合，结果写进临时目录，给一个带签名的地址，这种方案本身没问题，但如果签名地址有时效、有时被 CDN 缓存策略搞乱，用户在下载框弹出前喝杯咖啡回来，地址已经过期了。第四种最隐蔽，是响应格式由后端动态决定。查不到数据的时候后端返回一段 JSON 提示“无符合条件的数据”，正常时返回 xlsx 流，前端如果只会无脑触发下载，用户拿到的是一个名叫导出.xlsx的损坏文件，双击打开提示格式错误。这四种现场叠在一起，就是 Blob 方案存在的全部理由：把下载这件事从前端导航行为，改造成一次受控的、可拦截的、可判断的普通网络请求。

搞清楚这一点之后，后面的所有设计就有了判断标准。请求可控意味着你可以加 header、加超时、加取消、加进度监听；响应可控意味着你可以先判断 content-type 再决定是弹提示还是落文件；对象地址可控意味着你可以手动回收内存。我见过不少代码把 Blob 下载写成一段孤立的工具函数，随便往哪个组件里一塞，结果错误提示走不到、进度条接不上、iOS 上直接点了没反应。所以第一步不是写代码，是想清楚这条链路上有哪几个环节可能出问题。

注意：判断是否必须用 Blob 方案，看两个条件就够了——下载请求是否需要自定义请求头，或者是否需要用 POST 提交复杂参数。两个都不满足的话，直链方案更省事，别为了统一而统一。

1.2 Blob、ArrayBuffer、File、ObjectURL 各自的角色

这四个概念经常被混着叫，但它们分工很清晰。ArrayBuffer是一段纯粹的、定长的原始字节缓冲区，它不知道这些字节代表什么，你可以把它理解成一个没有标签的 U 盘。Blob是在字节之上加了一层元信息，也就是type（MIME 类型），它代表“一段不可变的类文件数据”，可以切片、可以取大小。File是 Blob 的子类，多出name和lastModified，通常出现在用户通过<input type="file">选择文件、或者拖拽上传的场景里。ObjectURL不是数据，它是一个由浏览器分配的、形如blob:https://host/uuid的字符串地址，指向内存里那个 Blob，只有当你需要把 Blob 交给浏览器原生能力（比如<a download>、<img src>、<video src>）消费的时候才需要它。

把它们串起来看，一次完整的下载过程其实就四步：网络层拿到 ArrayBuffer 或 Blob、必要时补上正确的 MIME 类型、URL.createObjectURL生成临时地址、交给<a>元素点击。理解这个分层的好处是，出问题时你能快速定位在哪一层。文件下载下来打不开，多半是 MIME 类型错了或者字节被截断；文件名乱码，问题在响应头解析；页面开久了内存飙升，问题在 ObjectURL 没回收；点了没反应，问题在触发层或者浏览器策略。我习惯在工具函数里把这几层拆成独立的小函数，getFileNameFromHeaders、buildBlob、saveAs，各自可以单测，出问题的时候日志也好看。

还有一点容易被忽略：responseType的设置必须和后续处理方式匹配。axios 里设成'blob'，拿到的是 Blob；设成'arraybuffer'，拿到的是 ArrayBuffer。两者都能构造出最终的 Blob，但如果你设成'blob'却按 ArrayBuffer 去读byteLength，就会拿到 undefined。浏览器端的 axios 只支持'blob'和'arraybuffer'两种二进制类型，'stream'、'document'那些是 Node 环境或者特定场景才有的，别照着文档瞎写。

1.3 什么时候不该用 Blob 方案

技术选型里最有价值的部分往往是什么时候不用。超大文件是第一个劝退项。Blob 的数据会完整驻留在内存或浏览器托管的临时存储里，一个 2GB 的镜像包走 Blob 方案，桌面端可能勉强扛住，移动端大概率直接把标签页搞崩。这种情况要么让后端给带签名的直链，要么上分片下载加流式写盘。iOS Safari 的下载行为是第二个劝退项，早期版本对a[download]的支持非常别扭，经常是新开一个空白页或者干脆没反应，用户以为自己点错了。如果目标用户里有大量 iOS 端，必须提前做降级预案，不能等上线了才被投诉。需要断点续传的场景也是，Blob 方案天然是一次性拿全量，中途断了只能从头再来。

我的判断经验是：文件体积在 200MB 以内、目标环境以桌面浏览器为主、需要鉴权和复杂参数，那就老老实实上 Blob 方案，成熟稳定，坑都可控；超出这个范围，就该去和后端谈直链或者分片协议，别硬扛。这个结论不是拍脑袋来的，是把线上内存告警、崩溃率和用户投诉量对着看了几个版本之后得出的。

2. 方案设计与技术选型：为什么最终都收敛到这几行代码

2.1 四条下载路径的横向对比

前端能触达的下载方式其实有四条，各自的适用边界很清楚，我把它们放在一张表里对比，基本上一眼就能选出来。

选择逻辑非常直接：需要鉴权或者 POST，只有最后一条路。不需要的话，直链或 iframe 更省心。iframe 方案在老系统里用得特别多，因为它不会让页面跳走，下载体验相对顺滑，但它的致命缺陷是完全静默——后端返回 500，用户看到的是一个空白 iframe，前端一点感知都没有。我后来在所有项目里都把 iframe 方案换掉了，就是因为排查线上问题时完全没线索，用户说“点了没反应”，你连请求有没有发出去都不知道。

Blob 方案的价值不只是“能用 POST”，更重要的是它把下载变成了一次普通的异步请求，这意味着你能接错误处理、能接 loading、能接取消按钮、能在文件流和 JSON 错误之间做判断。这些能力在 iframe 时代是没有的，而对中后台系统来说，用户体验的差距主要就体现在这些地方。

2.2 fetch 与 axios 在流式下载里的真实差异

选 fetch 还是 axios，这是第二个要拍板的事。两者都能干这活，差别集中在三处。第一处是进度。axios 在浏览器端提供了onDownloadProgress，底层靠 XHR 的progress事件，能拿到loaded和total，做进度条非常顺手；fetch 原生没有下载进度，想拿只能自己读response.body的 ReadableStream 手动累加，代码量翻倍。第二处是超时和取消。axios 有timeout配置和AbortController，fetch 只有AbortController，超时得自己用setTimeout包一层。第三处是拦截器。如果项目里已经有统一的 token 注入、统一错误提示、统一 loading 管理，用 axios 能直接复用；换成 fetch 就得重新写一遍。

所以我的实际选择是：中后台项目一律用 axios，因为拦截器和进度条的收益太明显；轻量页面、或者只需要几十 KB 的小文件、又不想为了一个下载引入整个 axios 的场景，用 fetch 更干净。有一个细节要注意，axios 的onDownloadProgress在某些情况下total会是 0，因为后端没返回Content-Length，比如 chunked 编码或者动态压缩过的响应。这时候进度条只能做成不确定态，别硬算百分比，否则会出现加载到 120% 的尴尬。

// axios 侧的关键配置 const res = await axios.post('/api/export', params, { responseType: 'blob', timeout: 120000, onDownloadProgress: (e) => { if (e.total) { setPercent(Math.round((e.loaded / e.total) * 100)); } }, });

上面这段里responseType: 'blob'是最关键的一行，写错或者漏写，拿到的就是被当成字符串解析过的乱码。我见过有人写成'Blob'（首字母大写），axios 不认，静默降级成默认的 json 解析，然后整条链路全崩。

2.3 一条可复用的分层结构

写了几版之后，我把这块代码固定成了四层，每一层的职责单一，替换起来也方便。请求层负责发请求、拿二进制、处理超时和取消；校验层负责判断这次响应到底是文件还是错误提示；解析层负责从响应头里抠出文件名和类型；触发层负责生成 ObjectURL、造 a 标签、点击、回收。这四层拆开之后，最直接的好处是错误处理终于有着落了——校验层一旦发现 content-type 是application/json，立刻走错误分支，把 blob 转成文本读出来弹提示，用户不会再收到一个坏掉的文件。

// 分层的骨架，实际项目里可以拆成独立文件 async function downloadFile({ url, params, method = 'post' }) { // 1. 请求层 const res = await request({ url, params, method, responseType: 'blob' }); // 2. 校验层 await assertIsFile(res); // 3. 解析层 const fileName = parseFileName(res.headers['content-disposition']); const blob = new Blob([res.data], { type: guessMime(fileName) }); // 4. 触发层 saveAs(blob, fileName); }

这套结构我用了好几个项目，后来连分片下载也能挂进来——只要请求层换个实现，其余三层完全不用动。这也是我建议的演进方向：别一上来就想着写一个万能下载函数，先按职责切分，等需求真变复杂了再往里填。

3. 核心实现拆解：从二进制响应到本地文件

3.1 响应类型设置：一个字符写错全盘皆输

响应类型的设置是所有问题的源头，也是最容易出错的地方。浏览器端的 axios，responseType只认'blob'和'arraybuffer'两个值，其中'blob'更常用，因为它自带 type 信息，后续处理省事。但这里有个连锁反应：一旦设成'blob'，所有响应的 data 都变成 Blob，包括错误响应。后端返回 500 时，res.data依然是一个 Blob，你的res.data.message永远是 undefined。这就是为什么很多人调试时发现“错误信息拿不到”，其实是拿得到，只是它在 Blob 里，得先await blob.text()再JSON.parse才能看见。

// 错误响应的正确读法 if (blob.type.includes('application/json')) { const text = await blob.text(); const err = JSON.parse(text); throw new Error(err.message || '导出失败'); }

另一个常被忽略的点是responseType在 axios 的拦截器里可能会被覆盖。如果项目里有个全局响应拦截器，判断res.data.code !== 0就弹提示，那它拿到 Blob 时会因为.code是 undefined 而误判成失败，直接跳错误分支。这个坑我在两个项目里都撞过，解决办法是在拦截器开头加一层判断：if (res.config.responseType === 'blob') return res;，把二进制响应放行，交给业务代码自己处理。

提示：全局拦截器一定要给 blob 类型开白名单，否则统一错误处理逻辑会误伤所有文件下载请求，这类问题往往只在导出功能上线后才暴露。

相关的还有Content-Type的协商。有些后端为了省事，所有文件都返回application/octet-stream，这个类型本身是合法的“二进制流”声明，浏览器不会尝试打开它，会直接下载。但如果返回的是text/plain或者干脆没设，Chrome 有可能把内容当文本渲染出来，页面上直接刷出一屏乱码。这种情况要在前端用文件名的扩展名兜底，手动构造 Blob 时指定正确的 MIME，能很大程度上规避。

3.2 文件名解析：Content-Disposition 的编码陷阱

文件名这块的坑多到可以单独成章。标准做法是后端在响应头里给Content-Disposition: attachment; filename="report.xlsx"，前端正则抠出 filename 就行。但只要文件名里有中文，问题立刻出现——HTTP 头历史上只允许 ASCII，中文必须编码。RFC 5987 给出的方案是加一个filename*参数，格式为filename*=UTF-8''%E6%8A%A5%E8%A1%A8.xlsx，前端需要先做decodeURIComponent才能还原。

function parseFileName(disposition) { if (!disposition) return 'download'; // 优先取 filename*，它的编码是可靠的 const star = /filename\*=UTF-8''([^;]+)/i.exec(disposition); if (star) return decodeURIComponent(star[1].trim()); // 兜底取 filename，兼容老后端 const normal = /filename="?([^";]+)"?/i.exec(disposition); if (normal) { const name = normal[1].trim(); try { return decodeURIComponent(name); } catch { return name; } } return 'download'; }

这里有两个实操细节。一是 decodeURIComponent 要包 try/catch。有些后端在 filename 里塞了未编码的中文，直接 decode 会抛URIError，整个下载流程就断了。二是跨域场景下这个头可能根本读不到。浏览器出于安全考虑，跨域请求默认只暴露少数几个安全响应头，Content-Disposition不在其中。后端必须显式加一行Access-Control-Expose-Headers: Content-Disposition，前端才能从res.headers里取到。这个问题极其隐蔽，因为请求本身成功了，文件也下载下来了，就是名字永远叫download，用户一脸问号。我在排查这个的时候，光看前端代码看了两个小时，最后用浏览器开发者工具的 Network 面板对比响应头才定位到。

还有一类特殊情况是文件名里含/、\、:这些字符。Windows 上这些是非法路径字符，浏览器会自动替换成下划线或者直接截断，导致最终文件名和预期不一致。稳妥的做法是前端解析完再清洗一遍：name.replace(/[\\/:*?"<>|]/g, '_')。

3.3 MIME 类型与 Blob 构造

构造 Blob 的时候，type参数决定浏览器怎么理解这份数据。不传 type 的话，Blob 的 type 是空字符串，某些浏览器在下载时会把它当成未知二进制，虽然大多数情况下还是能正常保存，但文件名可能被加上奇怪的扩展名。我的做法是：优先用响应头里的 Content-Type，拿不到就按扩展名映射。映射表不用太全，覆盖业务里常见的十几种就够了。

这张表我一般直接写成一个对象常量，用时MIME_MAP[ext] || 'application/octet-stream'一行搞定。有个细节是 csv 的 MIME 要写text/csv而不是application/csv，前者才是标准。另外如果导出的 csv 里有中文字段，后端没有加 BOM 的话，Excel 打开会乱码，这个锅在前端甩不掉——解决办法是在构造 Blob 时手动拼上\uFEFF前缀：

const blob = new Blob(['\uFEFF' + csvText], { type: 'text/csv;charset=utf-8' });

这个 BOM 头只有三个字节，但对 Windows 上的 Excel 判断编码有决定性作用。我在一个数据导出模块里加过这行，用户反馈的“打开是乱码”投诉直接归零。

3.4 触发下载与 URL 回收时机

最后一步看起来最简单，其实藏着一个经典的内存泄漏。标准写法是const url = URL.createObjectURL(blob)，造一个<a>元素，设置href和download，appendChild到文档里，click()，然后移除。关键在于URL.revokeObjectURL什么时候调。如果 click 之后立刻同步 revoke，部分浏览器（尤其是 Firefox 和某些版本的 Safari）会因为地址失效而中断下载，用户拿到零字节文件。如果永远不 revoke，那个 Blob 就一直挂在内存里，用户连续导出几十次，标签页内存能涨到一个惊人的数字。

function saveAs(blob, fileName) { const url = URL.createObjectURL(blob); const a = document.createElement('a'); a.href = url; a.download = fileName; a.style.display = 'none'; document.body.appendChild(a); a.click(); document.body.removeChild(a); // 延迟回收，给浏览器足够的读取时间 setTimeout(() => URL.revokeObjectURL(url), 4000); }

四秒这个数字不是魔法值，是我在几个浏览器上测出来的经验区间——太短会偶发中断，太长会短时间占内存，四秒左右基本兼顾了两头。更严谨的做法是监听下载完成事件，但浏览器并不提供这个能力，所以只能靠延时。另外appendChild这一步不能省，虽然没有明确文档说要挂到文档树里，但早期 Firefox 上有过不挂载就不触发下载的情况，加上这一行成本极低。

还有一个容易被忽略的点：a.download属性在跨域场景下会被忽略。如果你把href设成一个跨域的直链，download指定的文件名不会生效，浏览器会按 URL 最后一段来命名。这个问题只影响直链方案，我们这套 Blob 方案里href是blob:协议，同源，不受限制。

4. 大文件、进度与异常：把体验和稳定性补上

4.1 进度条的两种实现路线

进度条这东西，做得好是加分项，做不好是事故源。核心矛盾在于：有些响应根本没有 Content-Length。后端如果是边查边吐的流式响应、或者开了 gzip 分块压缩，total会是 0，这时候按loaded / total算出来的百分比毫无意义。我的策略是分两种情况：total有效就走确定性进度条，total为 0 就走不确定态（转圈或者跑马灯），绝不硬算。

onDownloadProgress: (e) => { if (!e.total) { setStage('generating'); // 不确定态 return; } const p = Math.min(99, Math.floor((e.loaded / e.total) * 100)); setPercent(p); // 留 1% 给落盘阶段 }

注意我把它封顶在 99%。因为网络传输到 100% 并不意味着文件已经落盘，浏览器还需要一点时间把 Blob 写出去，如果进度条停在 100% 但下载框还没弹出来，用户会觉得卡死了。留 1% 作为缓冲，等saveAs真正触发后再置为完成态，观感会好很多。

另一个实际问题是长任务的等待焦虑。报表导出经常要跑二三十秒，而这期间请求已经发出去了，但服务器还没开始返回数据，onDownloadProgress一次都不会触发。用户看到的是一个 0% 的进度条，等半分钟没动静就会去点第二次。我的做法是加一个“已提交，正在生成文件”的文案状态，用setTimeout在请求发出后 1 秒切换到它，让用户知道系统没死。这种细节看起来很小，但对减少重复提交非常有效——重复提交会触发后端并发限制，反而让第一次的任务更慢。

4.2 大文件内存峰值与流式落盘

Blob 方案的内存模型是这样的：网络收到的数据先攒在内存里，最终形成一个完整的 Blob 对象，浏览器可能会把超过一定大小的 Blob 移到磁盘存储区，但这个过程对 JS 不可见，你也控制不了。一个 500MB 的文件，在 Chrome 里峰值占用可能到 1GB 上下，因为中间会有多份拷贝。实测下来，桌面端 200MB 以内的文件基本无感，超过 500MB 就开始出现明显的卡顿，1GB 往上基本等于赌运气。

真要处理大文件，现在有两条路。一条是File System Access API，showSaveFilePicker()拿到文件句柄，配合response.body.getReader()边读边写，内存占用是常数级的。

const handle = await window.showSaveFilePicker({ suggestedName: fileName }); const writable = await handle.createWritable(); const reader = response.body.getReader(); while (true) { const { done, value } = await reader.read(); if (done) break; await writable.write(value); } await writable.close();

这段代码很漂亮，但现实约束是：只有 Chromium 系内核支持，而且必须在用户手势之后调用，Safari 和 Firefox 目前都不行。所以它适合内部系统这类浏览器环境可控的场景，对外产品还得做降级。

另一条路是分片下载。前后端约定好每片的大小（常用 5MB 到 20MB），前端循环发Range: bytes=0-5242879这样的请求，每片拿到后先存着，最后合并成一个 Blob。好处是单次请求的内存压力小、可以显示精细进度、断了一片只重试那一块；坏处是总耗时可能变长（多次请求的开销）、代码复杂度上一个台阶、而且最终合并那一步仍然需要完整内存，本质上只是把峰值推迟了，没有消除。真正想彻底解决，还是得回到流式写盘，或者让后端支持直链。

我在一个文件管理模块里做过折中方案：小于 100MB 走普通 Blob，100MB 到 500MB 走分片加逐片落盘（用 IndexedDB 暂存），超过 500MB 直接提示“文件较大，建议使用客户端工具下载”。这个分级策略是拿用户实际的文件大小分布算出来的——统计下来 95% 的下载都在 50MB 以内，为那 5% 去做一套复杂的流式方案，投入产出比不划算。

4.3 当后端返回的是 JSON 错误

这是 Blob 下载里最高频的线上问题，没有之一。表现是：用户点导出，浏览器下载了一个文件，打开提示“文件已损坏”，或者用文本编辑器打开发现里面是一段 JSON。根因是后端在业务异常时返回了 JSON，但 HTTP 状态码是 200，前端无脑落盘。防御的做法是在触发下载前做一次类型嗅探。

async function assertIsFile(res) { const blob = res.data; const type = blob.type || ''; const isJson = type.includes('json') || type.includes('text/plain'); if (!isJson) return; // 把 blob 读成文本，尝试解析出错误信息 const text = await blob.text(); try { const data = JSON.parse(text); throw new Error(data.message || data.msg || '导出失败，请稍后重试'); } catch (e) { if (e instanceof SyntaxError) return; // 不是 JSON，可能是真的纯文本文件 throw e; } }

这里有个判断要小心：不能一看到text/plain就认定是错误。有些系统导出的 txt 或 csv 就是text/plain，误判会把正常下载拦下来。所以解析失败（SyntaxError）的时候要放行，让文件正常落地。这个细节我在第一版里漏了，结果一个导出日志文件的接口全线报错，排查了半天。

还有一种情况是后端把错误信息塞进了响应头，比如X-Error-Message，但同样受跨域暴露头的限制。如果前后端能协商，我更推荐用一个自定义的响应头标记业务状态，比如成功时X-Result: ok，失败时X-Result: error加X-Message，前端只看这个标记决定走向，比嗅探 MIME 类型可靠得多。这个约定需要后端配合，但只要谈一次就能一劳永逸。

提示：最稳的方案永远是前后端约定一个明确的业务状态头，而不是让前端靠 MIME 类型猜。嗅探只是兜底手段，不能当主逻辑。

5. 兼容性差异与排查实录

5.1 浏览器行为差异对照表

各个浏览器在下载这件事上的行为差异比想象中大，我做了一张对照表，基本上覆盖了日常会遇到的分歧点。

从表里能看出，桌面端三家基本一致，真正的雷区在移动端和内置浏览器。iOS Safari 的处理策略我一般是这样的：先尝试标准a[download]，检测到是 iOS 且下载未触发（可以用一个短暂的setTimeout之后检查页面是否仍在焦点）就降级成在新标签页打开 Blob 地址，让系统自己决定怎么处理。体验不算完美，但比点了没反应强。微信内置浏览器更麻烦，它对 Blob 下载基本持拒绝态度，稳妥做法是检测 UA 里是否包含MicroMessenger，命中就弹一个引导层，提示用户点右上角在浏览器中打开。这个引导层虽然粗暴，但转化率比默默失败高得多。

还有一个通用的兼容写法是给 IE 兜底，虽然现在基本不用了，但如果维护的是老系统，navigator.msSaveOrOpenBlob(blob, fileName)是唯一可行路径，得在saveAs里加一个分支判断。这段代码我建议保留，成本就三行。

5.2 常见问题速查表

下面这张表是我这些年攒下来的，基本覆盖了 Blob 下载 90% 的故障场景，遇到问题先对一遍，能省掉大量抓瞎时间。

这张表里最值得多说一句的是第一行。responseType漏设导致的乱码问题，特征非常明显——下载下来的文件用文本编辑器打开，是一堆�PNG或者PK开头的乱码，那是因为二进制被当成 UTF-8 字符串解码过，字节已经不可逆地损坏了。看到这个特征，直接去查请求配置，不用怀疑别的。

5.3 我在真实项目里踩过的几个坑

说几个具体案例，都是文档里不会写、但实际会碰上的。

第一个是超时设置。默认的 axios 超时经常是 10 秒或者根本没设，导出接口跑三十秒是常态，结果请求被前端自己掐断了。更恶心的是掐断之后catch里拿到的error.response.data依然是 Blob，你还得再解一次才能看到真正的错误。我的做法是给所有导出请求单独设timeout: 120000，并且用AbortController支持用户手动取消——用户等得不耐烦点取消，总比干等着强。

第二个是并发导出把后端打挂。用户手快连点五次导出，五个请求同时跑，数据库直接被打满。前端能做的限制是：点击后立刻置 disabled，请求结束再恢复，同时用一个全局的下载任务队列，同一时间只允许一个导出请求在飞。这个改动只有十几行，但效果立竿见影。

第三个是文件名里的空格和特殊字符。有次用户反馈下载下来文件名变成了一串%20，原因是我在decodeURIComponent之后又做了一次 URL 编码，多此一举。文件名解析这块，原则是只解码一次，不做额外编码，因为download属性接受的是原始字符串，浏览器自己会处理特殊字符。

第四个是在 iframe 里触发下载。后台系统常见的布局是主页面套一堆 iframe，如果下载代码跑在 iframe 里，某些浏览器会把下载行为归属到 iframe，导致下载框被拦截或者出现位置怪异。稳妥做法是把a元素挂到document.body，而不是某个局部容器，必要时用window.top.document。这个坑我调了大半天，最后发现只是appendChild的目标不对。

第五个是下载完成后的状态同步。用户下载完文件，列表里的“已导出”状态没更新，得手动刷新。原因是下载是纯前端行为，后端根本不知道。解决办法要么在下载成功后额外发一个确认请求，要么在导出接口里就直接把状态改掉。我倾向后者，虽然语义上有点别扭（请求返回时文件还没真正落盘），但业务上够用，也省一次请求。

写完这些，我在实际项目里的体会是：Blob 文件流下载本身的技术含量并不高，核心代码加起来不到五十行，真正耗时间的是那些边角情况——跨域头的暴露、错误响应的识别、移动端的降级、内存的回收。这些问题有个共同特征：在开发机上永远复现不了，只有到了真实用户手里才会暴露。所以我的建议是，这套代码写完别急着交付，拿一个大文件、一个空数据场景、一个后端故意报错的场景、再加上手机浏览器，四个用例跑一遍，能挡掉后面八成的线上问题。至于再往后怎么优化，比如接流式写盘、接分片续传，那都是文件体积真的涨上去了才需要考虑的事，提前做反而是过度设计。