前端下载文件、把后端返回的 Excel 文件流导出成用户硬盘上那个能双击打开的文件，这件事在外行看来就是一行a.click()，在真正做过的人眼里却是一串连环坑。我这些年经手过至少七八个后台管理系统，几乎每个项目都要重新处理一遍“导出”这个需求，每次都能踩出点新花样：有的是文件名变成乱码，有的是下载下来一个 3KB 的.xlsx打开提示格式错误，还有的是明明后端返回了错误提示，前端却老老实实把它存成了文件。这篇文章就把前端下载文件、下载 Excel 文件、后端返回文件流导出这一整套东西拆开讲清楚，包括浏览器到底是怎么把一堆二进制字节变成磁盘上一个文件的、responseType: 'blob'背后的实际含义、Content-Disposition该怎么解析、常见的错误现场怎么快速定位。适合刚接手数据导出需求的前端同学，也适合已经写过几遍但每次都要翻旧代码、说不清所以然的老手对照查漏。
1. 前端下载文件的几条路，先选对再动手
做导出需求，第一件事不是写代码，是搞清楚“这个文件从哪来”。来源不同，实现方式完全是两套逻辑。很多人上来就window.open(url)，结果发现接口要求带 token、要求 POST 一堆筛选条件，open出去的是一个 401 页面；也有人不管三七二十一全部用 Blob 处理，结果对一个静态资源链接也去发 XHR，白白多绕一圈。
1.1 三种常见形态的边界
我把实际项目里遇到的下载需求归成三类。
第一类是静态资源直链，比如把用户手册 PDF、模板文件放在对象存储上，后端给你一个带签名的 URL。这种最省事，直接创建a标签设置href和download属性点一下就行，甚至不需要download属性，浏览器识别到 PDF、图片这类类型会直接内联预览，用户自己另存。注意<a download>对跨域 URL 是无效的——浏览器会忽略 download 属性，改走预览或直接跳转，这是 HTML 规范里的限制，跟浏览器版本无关。所以跨域签名链接想强制下载，要么后端在响应头里加Content-Disposition: attachment，要么走流式代理。
第二类是GET 请求带鉴权，比如/api/export?month=202409，但需要Authorization头。这种不能直接<a href>，因为浏览器发起的导航请求带不上你存在 localStorage 里的 token。常见做法是用fetch或axios把文件拉成 Blob，再走 Blob URL 下载。
第三类是POST 请求返回流，筛选条件复杂到 URL 放不下，或者要传一个大的 ID 数组，后端只能接受 POST，响应体是二进制流。这就是标题里说的“后端返回文件流”，也是坑最密集的一类：请求配置、错误判别、文件名提取、大文件超时，每个环节都能出问题。
1.2 为什么“后端返回文件流”最容易翻车
它翻车的根本原因在于同一个响应通道里塞了两种语义完全不同的内容。成功的时候，响应体是几百 KB 的 xlsx 二进制；失败的时候，很多后端习惯性地返回{"code": 500, "message": "导出数据量超过上限"}这样的 JSON。而前端的请求库是按responseType预先决定怎么处理响应体的，你设了blob，它就把 JSON 也当二进制收下来，于是那句错误提示变成了一堆字节，用户点开文件发现是乱码，客服电话就来了。
另一个原因是文件流没有“格式自描述”能力。HTML 页面你打开就知道对不对，但一个损坏的 xlsx 和正常的 xlsx 在字节层面可能只差几个字节，浏览器不会帮你校验，它只负责把字节倒到磁盘上。所以出问题时，前端几乎没有报错，一切“看起来都成功了”，只有用户知道文件打不开。
我的建议很直接：只要接口涉及文件流，前端就要把“判错”当成一等公民来做，不能依赖 HTTP 状态码。下面第 3 节会给具体的判断逻辑。
2. 二进制落盘的底层机制，搞懂了就不慌
很多人写下载是抄来的模板，能跑就行，一出问题就抓瞎。其实这套机制就三个概念：请求层拿到二进制、内存里包成 Blob、用临时 URL 交给浏览器。搞清楚这三步各自在干什么，排错就有方向了。
2.1 Blob、ArrayBuffer 与 responseType 的对应关系
responseType决定了浏览器把响应体解析成什么 JavaScript 类型。这个参数设错了，后面全白搭。
| responseType | 得到的类型 | 典型用途 | 常见误用 |
|---|---|---|---|
空 /'text' | string | 普通 JSON 接口 | 拿去下载，中文全乱码 |
'json' | object | 结构化数据 | 文件流被强行 JSON.parse 报错 |
'blob' | Blob | 文件下载、图片预览 | 拿不到原始字节做校验 |
'arraybuffer' | ArrayBuffer | 需要读写字节、加解密、拼接 | 下载时忘记再包成 Blob |
'document' | Document | 极少用 | — |
Blob（Binary Large Object）你可以理解成“浏览器内存里的一块只读字节区，外加一个 MIME 类型标签”。它本身不能直接读内容，要用FileReader或者blob.text()、blob.arrayBuffer()转。它的好处是浏览器知道怎么把它变成一个可下载的资源，所以你不需要自己管理字节。
ArrayBuffer是更底层的东西，就是一段连续内存。如果你需要在下载前做点什么——比如给 CSV 拼个 BOM 头、校验文件头是不是PK（xlsx 本质是 zip，头两个字节是 0x50 0x4B）、或者把多个分片拼起来——那就用arraybuffer，处理完再new Blob([buffer], { type: '...' })。
有一个细节值得说：Blob构造时如果不给type，浏览器会用空字符串，某些老版本环境下载时文件名后缀会丢。我习惯性总是显式指定type，虽然对下载行为本身影响不大，但对调试有帮助——你在 Network 面板之外，可以在控制台打印blob.type和blob.size快速确认拿到的是不是文件。
2.2 objectURL 的生命周期与释放时机
URL.createObjectURL(blob)会生成一个形如blob:https://example.com/8f3a-...的临时地址，这个地址指向内存里的 Blob。关键在于它是强引用：只要这个 URL 没被revokeObjectURL释放，对应的 Blob 就一直占着内存，哪怕你已经把a标签删了。
一次两次无所谓，但如果你的页面是个报表中心，用户连续导出几十次 Excel，每个文件几 MB，内存就会明显涨上去。我在一个项目里见过这个问题的实际表现：用户反复导出后页面卡顿，DevTools 的 Memory 面板里能看到一堆 Detached 的 Blob。
正确写法是在点击后延迟释放：
function downloadBlob(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); // 不要立刻 revoke，部分浏览器会在下一帧才真正开始读取 setTimeout(() => URL.revokeObjectURL(url), 1000); }那个setTimeout不是玄学。早期 Safari 和部分 WebView 在click()之后是异步去读 URL 的，如果你同步revoke，下载会直接失败或者得到 0 字节文件。延迟 1 秒是社区里比较通用的折中值，我实测在主流环境里稳定。
注意：如果你在 iframe 或者沙箱环境里跑，
createObjectURL可能被策略拦截，报Not allowed to load local resource。这种情况基本无解，得让宿主页配合。
2.3 Content-Disposition 里藏着文件名
后端返回文件流时，文件名是通过响应头Content-Disposition传的。前端如果不解析这个头，就只能自己瞎编一个导出.xlsx，用户桌面上一堆同名文件，体验很差。
这个头的格式有历史包袱，实际见到的至少三种：
Content-Disposition: attachment; filename="report.xlsx" Content-Disposition: attachment; filename=report.xlsx Content-Disposition: attachment; filename="report.xlsx"; filename*=UTF-8''%E6%8A%A5%E8%A1%A8.xlsx第三种是 RFC 5987 的写法，专门解决非 ASCII 字符（中文文件名）的问题。filename*里的格式是字符集'语言'URL编码后的名字，语言部分通常为空。现代后端的正确做法是两个都返回：filename放一个 ASCII 兜底（比如export_202409.xlsx），filename*放真正的中文名。
还有一个隐藏坑：有些后端用URLEncoder.encode编码文件名，把空格编成了+。而decodeURIComponent不会把+还原成空格，于是文件名变成report+2024.xlsx。所以解析的时候要额外处理一次：
name = name.replace(/\+/g, ' ');3. 从请求到落盘：一条完整的 Excel 导出链路
这一节我把整条链路拆成四段，每段给出可直接抄的写法。假设场景是：用户在前端勾选了一堆订单，点“导出 Excel”，后端根据 ID 列表生成文件并以流的形式返回。
3.1 请求层怎么配
用 axios 的话，核心就两个配置：
const res = await axios.post('/api/order/export', { ids: selectedIds, dateRange: [start, end], columns: ['orderNo', 'amount', 'status'], }, { responseType: 'blob', // 关键：告诉浏览器按二进制收 timeout: 0, // 大文件不要设默认超时 headers: { 'Content-Type': 'application/json' }, });responseType: 'blob'是整件事的地基。写错成'json'或者不写，axios 会用默认的 JSON 转换器去处理，二进制会被当成 UTF-8 文本解码，出来的是一串�PK开头的东西，再包成 Blob 下载，文件大小可能对得上但内容已经废了。
timeout: 0也是必要的。axios 默认没有超时（取决于版本，有些封装的默认值是 10s 或 30s），但如果你的项目里统一配了 10 秒超时，导出十万行数据后端跑 40 秒，前端会先断开，用户看到“网络错误”，实际上后端还在默默生成。
如果你用了统一封装的请求拦截器，这里要特别小心。很多团队的项目里，响应拦截器会无脑做if (res.data.code !== 0) throw ...，碰到 blob 响应直接崩。正确的做法是在拦截器里判断：
if (response.config.responseType === 'blob') { return response; // 跳过业务码校验，交给调用方处理 }这一步不做，你会发现导出的接口在拦截器里就挂了，错误信息还特别莫名其妙。
3.2 响应处理：先判错，再下载
拿到 blob 之后，第一件事不是下载，是判断这个 blob 到底是文件还是错误信息。我的判断顺序是这样的。
第一步看blob.type。后端如果规范，成功时是application/vnd.openxmlformats-officedocument.spreadsheetml.sheet或者application/octet-stream，失败时是application/json。
第二步看blob.size。如果文件只有几十个字节，那基本不可能是正常的 Excel（xlsx 最少也有几 KB，因为内部是 zip 结构）。这时候就读内容。
第三步读内容判断。稳妥的写法：
async function handleExportResponse(res) { const blob = res.data; const contentType = blob.type || ''; // 明显的 JSON 错误响应 if (contentType.includes('application/json') || contentType.includes('text/plain')) { const text = await blob.text(); let message = '导出失败'; try { const data = JSON.parse(text); message = data.message || data.msg || message; } catch (e) { message = text.slice(0, 200) || message; } throw new Error(message); } // 兜底：体积可疑且首字符是 { if (blob.size < 512) { const text = await blob.text(); if (text.trim().startsWith('{')) { try { const data = JSON.parse(text); throw new Error(data.message || '导出失败'); } catch (e) { if (e instanceof SyntaxError) { // 解析不了就当正常文件放过 } else { throw e; } } } } return blob; }这段代码看着啰嗦，但每一段都来自实际踩坑。text/plain那一条是因为有些网关会把错误转成纯文本；体积判断那一条是因为有些后端压根不设Content-Type，或者设成了application/octet-stream却在里面塞 JSON。
提示：更省事的办法是跟后端约定，错误时返回 4xx/5xx 状态码，前端在 axios 的 error 分支里处理。但这需要后端配合改造，老项目里往往做不到，前端只能自己兜。
3.3 文件名解析的健壮写法
前面说过Content-Disposition的三种形态，这里给一个能覆盖大部分情况的解析函数。注意 axios 里获取这个头的方式是res.headers['content-disposition']，而且如果跨域，需要后端在Access-Control-Expose-Headers里显式暴露Content-Disposition，否则前端读不到这个头。这一点非常容易被忽略，表现是本地开发正常（代理同源），部署到线上（跨域）文件名就丢了。
function parseFilename(disposition, fallback = '导出文件.xlsx') { if (!disposition) return fallback; // 优先取 RFC 5987 的 filename* const starMatch = /filename\*\s*=\s*([^;]+)/i.exec(disposition); if (starMatch) { let value = starMatch[1].trim().replace(/^["']|["']$/g, ''); const parts = /^([\w-]+)'[^']*'(.*)$/.exec(value); if (parts) { try { return decodeURIComponent(parts[2]).replace(/\+/g, ' '); } catch (e) { // 编码不规范，落到下面兜底 } } } const plainMatch = /filename\s*=\s*([^;]+)/i.exec(disposition); if (plainMatch) { let value = plainMatch[1].trim().replace(/^["']|["']$/g, ''); try { value = decodeURIComponent(value); } catch (e) { // 不是 URL 编码，原样用 } return value.replace(/\+/g, ' ') || fallback; } return fallback; }几个要点再强调一遍：正则里filename*必须放在filename之前判断，不然会被普通的那种先命中；decodeURIComponent要包try/catch，因为有些后端会把未编码的%直接塞进来；+替换要放在解码之后，顺序反了会破坏原本就含有+的合法编码。
3.4 一个能反复用的下载工具函数
把上面几块拼起来，就是一个通用的导出工具。我一般放在src/utils/download.js里，全项目复用。
// utils/download.js export async function exportFile(requestFn, options = {}) { const { fallbackName = '导出文件.xlsx', onProgress, } = options; const res = await requestFn({ responseType: 'blob', timeout: 0, onDownloadProgress: (e) => { if (onProgress && e.total) { onProgress(Math.round((e.loaded / e.total) * 100)); } }, }); const blob = await validateBlob(res.data); const filename = parseFilename( res.headers['content-disposition'], fallbackName ); downloadBlob(blob, filename); return { blob, filename }; }调用方写起来就很清爽：
await exportFile( (config) => api.post('/api/order/export', params, config), { fallbackName: `订单明细_${dayjs().format('YYYYMMDD')}.xlsx` } );fallbackName带上日期是个小习惯，能避免用户在拿不到后端文件名时下载出一堆同名文件被系统自动加(1)(2)。
4. 踩坑记录：那些“下载下来打不开”的现场
这一节是我这些年攒下来的故障台账，按发生频率排序。每个问题我都写清楚现象、原因和定位方法，遇到类似情况可以直接对照。
4.1 文件损坏与乱码的五大成因
| 现象 | 最可能原因 | 快速验证方法 |
|---|---|---|
| 下载的文件只有几 KB，打开提示格式错误 | 响应体是 JSON 错误，被当成文件存了 | 用文本编辑器打开，看是不是{"code":...} |
| 文件大小正常但打开全是乱码 | responseType没设 blob，二进制被当文本解码 | 控制台打印blob.type，看是不是text/plain |
| 文件能打开但中文全是问号/方块 | CSV 缺 BOM 头，Excel 按本地编码解析 | 用记事本打开看编码是不是 ANSI |
| 下载 0 字节 | objectURL 被提前 revoke，或浏览器拦截 | 把 revoke 的 setTimeout 拉长到 5 秒再试 |
文件名变成%E6%8A%A5%E8%A1%A8.xlsx | 后端编码了但前端没解码 | 直接看响应头的原始内容 |
第一条和第二条占了所有问题的七成以上。我的经验是，遇到文件打不开，第一反应永远是把 blob 的内容当文本读出来看一眼，两秒钟就能确定是不是错误信息。控制台执行：
await blob.text() // 或者 new Response(blob).text()如果是PK开头的乱码，说明是正常的 xlsx；如果是可读的 JSON 或 HTML，那就是错误响应，问题在后端或者网关。
HTML 这个情况也值得单独说：有时候接口被登录拦截，返回的是一个 302 跳转后的登录页 HTML。前端拿到这段 HTML 存成.xlsx，用户打开就是一堆标签。所以判断的时候不能只判 JSON，<开头也要拦。
4.2 错误 JSON 被存成 .xlsx 的完整现场
讲一个印象最深的案例。某后台管理系统的订单导出功能，上线后用户反馈“下载的文件打不开”。我拿到用户下载的文件，3.2KB，用 VSCode 打开一看，内容是一段完整的 JSON，里面写着{"code":1001,"msg":"导出数据量超过单次上限，请缩小时间范围"}。
问题链路是这样的：后端业务校验失败，但它包在一个 HTTP 200 的响应里返回 JSON，Content-Type设成了application/json；前端 axios 设了responseType: 'blob'，把 JSON 当二进制收下；代码里没有做任何判断，直接downloadBlob；用户拿到一个 3KB 的“Excel”。
修复方案分两层。前端加上 3.2 节那套判断逻辑，立刻止血；后端把业务失败改成 4xx 状态码，并在文档里写明。我坚持让后端改的原因是：前端永远猜不全后端会怎么错误返回，靠前端兜底是治标，统一协议才是治本。
顺带说一个变种：有些网关（比如某些 Nginx 配置）在超时的时候会返回自己的 HTML 错误页，状态码可能是 502/504，axios 会走 catch，但如果你们的错误处理里写了finally就去下载，照样能存出个 HTML 文件来。所以 catch 分支里千万别碰res.data去下载。
4.3 大文件、超时与进度条
数据量一上去，问题就变成另一批了。
超时：前面说了timeout: 0，但还要注意运维层。Nginx 默认proxy_read_timeout是 60 秒，网关可能有自己的限制，后端生成大文件超过这个时间，连接会被掐断，前端拿到的是截断的流，下载下来是个“半个文件”。这种文件通常大小不对，xlsx 会报“文件已损坏”。定位方法是看响应头里的Content-Length和实际blob.size是否一致：
const expected = Number(res.headers['content-length']); if (expected && blob.size !== expected) { throw new Error('文件传输不完整，请重试'); }这个校验成本极低，建议加上。
进度条：onDownloadProgress能用，但它依赖Content-Length响应头。如果后端做了 gzip 压缩，e.total拿到的是压缩后的长度，跟实际下载量对不上，进度条会跑到 100% 还在转，或者超过 100%。另外，这个回调反映的是下载进度，不是后端生成进度——用户点了导出之后那段最长的等待（后端在查库生成文件）是没有进度的。所以我的做法是：点按钮先给一个“正在生成，请稍候”的 loading，等到开始接收数据了再切换成百分比条。
流式下载：如果文件大到几百 MB，全部放内存里再落盘，低端机会崩。Chromium 系可以用 File System Access API 边下边写：
async function streamSave(response, suggestedName) { if (!window.showSaveFilePicker) { // 不支持就回退到普通 Blob 下载 const blob = await response.blob(); downloadBlob(blob, suggestedName); return; } const handle = await window.showSaveFilePicker({ suggestedName }); 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(); }注意showSaveFilePicker必须由用户手势触发，不能放在异步回调的深处，否则会抛安全错误。而且它只在 Chromium 系可用，Safari 和 Firefox 得走回退。实际项目里我的态度是：除非真有超大文件需求，否则老老实实让后端压缩包、前端普通 Blob 下载，别为了炫技引入兼容性负担。
4.4 跨端差异与浏览器限制
移动端和内置浏览器是另一个世界。
iOS Safari 对a.download的支持在 13 之后基本可用，但有个限制：它不认download里的路径分隔符，文件名里的/会被替换掉；另外部分版本对 Blob URL 的下载会打开新标签页而不是保存。App 内置 WebView 的问题更大，很多 WebView 直接禁用了 Blob 下载，点下去毫无反应。这种情况前端无解，要么引导用户“在浏览器中打开”，要么走原生桥接让 App 自己下载。
还有一个容易被忽略的限制：浏览器的多文件下载拦截。如果业务需要一次导出多个文件（比如按月份拆分成 12 个 Excel），你在循环里连续触发 12 次a.click()，从第二次开始大部分浏览器会静默拦截，因为不是用户手势。正确做法是让后端打成 zip 返回一个文件，或者前端用JSZip在浏览器里打包。前者更靠谱，后者在文件多、体积大时内存压力明显。
5. 不依赖后端的导出方案与进阶玩法
有些导出场景根本不需要后端参与，比如把当前页面的表格数据导成 CSV，或者把用户在一个表单里填的东西导成模板文件。这类需求让后端加接口反而是浪费，前端自己就能搞定。
5.1 纯前端导出 CSV 与 Excel
CSV 是最容易的，本质就是拼字符串。但有两个细节必须处理，否则 Excel 打开就是灾难。
第一是BOM 头。Excel 在打开 CSV 时，如果文件没有 BOM，它会按系统本地编码（简体中文环境下是 GBK）去解析，UTF-8 的中文就变成乱码。加一个\uFEFF就解决了：
function exportCsv(rows, filename = '导出.csv') { const escape = (v) => { const s = v == null ? '' : String(v); if (/[",\n\r]/.test(s)) { return '"' + s.replace(/"/g, '""') + '"'; } return s; }; const content = rows.map(r => r.map(escape).join(',')).join('\r\n'); const blob = new Blob(['\uFEFF' + content], { type: 'text/csv;charset=utf-8', }); downloadBlob(blob, filename); }第二是转义。字段里含逗号、换行、双引号，必须整体加引号并把内部引号翻倍，否则列会错位。这段逻辑很短但极容易漏，我见过好几个项目导出的 CSV 里地址字段一带逗号，整张表就歪了。
如果需要真正的 xlsx（带格式、多 sheet、列宽），用 SheetJS 这类库生成二进制：
import * as XLSX from 'xlsx'; function exportXlsx(data, filename = '导出.xlsx') { const ws = XLSX.utils.aoa_to_sheet(data); ws['!cols'] = [{ wch: 20 }, { wch: 12 }, { wch: 30 }]; // 列宽 const wb = XLSX.utils.book_new(); XLSX.utils.book_append_sheet(wb, ws, '数据'); const buf = XLSX.write(wb, { bookType: 'xlsx', type: 'array' }); const blob = new Blob([buf], { type: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet', }); downloadBlob(blob, filename); }ws['!cols']这个设置我强烈建议加上。默认列宽下，导出的表格里长文本全被截成####，用户第一反应就是“你这导出有问题”，其实是没设列宽。
前端导出的适用边界要说清楚：几千行以内随便玩，几万行开始明显卡顿，十万行以上浏览器直接卡死。因为整个流程都在主线程，XLSX.write是同步的，几万行能占住主线程好几秒。真要导大数据量，还是得走 3.1 节的后端流方案，或者上 Web Worker 把生成过程挪出去。
5.2 批量导出与打包下载
业务上常见的“按门店导出，一家一个文件”，如果门店有几十个，前端循环下载肯定被拦截。两个思路。
一是后端打 zip，接口返回application/zip，前端处理方式跟 Excel 完全一样，只是 fallback 文件名改成.zip。这是我最推荐的做法，服务端压缩比高、稳定、不占前端内存。
二是前端打包，用 JSZip 把多个 Blob 塞进去：
import JSZip from 'jszip'; async function exportZip(files) { const zip = new JSZip(); for (const f of files) { zip.file(f.name, f.blob); } const content = await zip.generateAsync({ type: 'blob', compression: 'DEFLATE', compressionOptions: { level: 6 }, }); downloadBlob(content, `批量导出_${Date.now()}.zip`); }注意generateAsync也要时间，几十个文件同样会卡。而且这个方案的前提是你得先把每个文件都从后端拉下来，网络开销翻倍。所以除非数量很少（比如 5 个以内），我还是推给后端。
5.3 下载体验的几个细节打磨
技术链路通了之后，体验上的小改进往往更影响用户评价。
按钮防抖与状态。导出按钮是最容易被连点的。用户点了没反应就再点，结果后端收到五次请求，生成了五个文件。我的做法是点击后立刻disabled并显示“生成中…”，请求结束（无论成功失败）再恢复。同时用 loading 遮罩防止用户切页面。
空数据提示。如果筛选条件查出来 0 条，后端可能返回一个只有表头的 Excel，也可能返回错误。前者用户打开一脸懵，后者用户以为坏了。最好在前端就拦一下：勾选数量为 0 时直接message.warning('请先选择要导出的数据')，不浪费一次请求。
成功反馈。浏览器下载是静默的，用户不知道好了没有。可以在请求完成后弹一个轻提示“文件已开始下载，请查看浏览器下载列表”。这类小反馈能显著减少“我点了没反应”的投诉。
失败可重试。导出失败的时候，把错误信息展示出来，同时保留用户的筛选条件，一点就能重试，不要清空表单让用户重新选一遍。
6. 一些真金白银换来的经验
做这类需求的年头久了，我现在拿到“导出”两个字的需求，第一句话一定问后端：失败的时候你返回什么。如果对方说“返回错误码啊”，我会追问“HTTP 状态码还是 body 里的 code”；如果答案是后者，我会直接要求改成前者，改不了就在前端写判断。这一步沟通成本很低，但能省掉后面一半的线上问题。
还有一条是永远不要相信响应头里没有的东西。Content-Disposition拿不到的时候要能优雅降级，Content-Length拿不到的时候不要算进度，Content-Type是application/octet-stream的时候不要以为就是文件。前端在这个链路里是弱势方，唯一的武器是多写几行防御性代码。
最后分享一个排查小技巧。当用户说“导出的文件打不开”而你在本地复现不了的时候，让他把下载的文件发过来，不用打开，直接看文件大小和用文本编辑器看前 200 个字符。PK开头说明文件本身没问题，可能是 Excel 版本或者文件关联的问题；{或<开头说明是错误响应；全是问号说明编码错了。这一个动作就能把问题范围砍掉一大半，比让用户描述半天强得多。
