本文详解 fetch 下载非文本文件（如图片、压缩包）时出现“文件损坏”的根本原因及可靠解决方案，重点纠正 blob 构造错误、mime 类型误设、响应流处理不当等常见陷阱。
本文详解 fetch 下载非文本文件（如图片、压缩包）时出现“文件损坏”的根本原因及可靠解决方案，重点纠正 blob 构造错误、mime 类型误设、响应流处理不当等常见陷阱。
在前端通过 fetch 实现文件下载时，看似简单的代码却极易导致二进制文件（如 PNG、JPEG、ZIP、PDF）下载后无法打开——而纯文本文件（如 .txt）却能正常查看。你提供的代码中问题核心在于这一行：
const urlBlob = new Blob([blob], { type: "application/octet-stream" });✅ 错误根源：你将已解析好的 Blob 对象再次包裹进一个新的 Blob，并强制指定为 application/octet-stream。这看似无害，实则破坏了原始响应的二进制完整性——尤其是当服务端返回了精确的 Content-Type（如 image/png 或 application/zip）时，手动覆盖 MIME 类型可能导致浏览器或解压工具在解析时丢失关键元信息；更严重的是，new Blob([blob]) 在某些浏览器中会触发不必要的序列化/反序列化，引入字节偏移或编码污染。
✅ 正确做法：直接复用原始响应的 Blob，保留其原始类型与二进制结构：
fetch(this.baseUri + endpointURI)
.then((res) => {
if (!res.ok) throw new Error(`HTTP ${res.status}: ${res.statusText}`);
// ✅ 关键：直接使用 res.blob() 返回的原生 Blob，不二次封装
return res.blob();
})
.then((blob) => {
// ✅ 推荐：优先使用响应头中的 Content-Type， fallback 到 blob.type
const contentType = res.headers.get('content-type') || blob.type;
const urlBlob = new Blob([blob], { type: contentType }); // 仅当需显式设置时才构造，且 type 应真实反映内容
const url = URL.createObjectURL(urlBlob);
const a = document.createElement('a');
a.href = url;
a.download = attachmentName || 'download';
document.body.appendChild(a);
a.click();
document.body.removeChild(a); // 更稳妥地清理 DOM
URL.revokeObjectURL(url); // ✅ 及时释放内存引用
})
.catch(err => console.error('文件下载失败:', err));⚠️ 额外关键注意事项：
- 禁止篡改响应流：确保服务端未对响应体做 Base64 编码、JSON 封装或额外文本包装（例如返回 { "data": "base64..." }）。fetch(...).then(r => r.blob()) 必须作用于原始二进制响应体。
- 检查 CORS 与中间代理：正如你在答案中发现的——若请求经过中间网关（如你提到的“middleware 公共服务”），该网关可能未正确透传 Content-Type、Content-Length 或二进制流（例如误用 UTF-8 解码再转码），导致字节损坏。此时可对比直连后端与经网关的响应 blob.size 和 headers 是否一致。
-
调试技巧：下载后用命令行校验文件完整性：
# 查看文件头（应匹配实际类型） file -I downloaded.zip # 比较原始响应 size 与下载文件 size ls -l downloaded.png
- 替代方案（适用于受控环境）：若 CORS 和网关不可控（如你最终采用的新标签页跳转），且用户始终处于可信内网，可安全使用 <a href="https://backend/api/file" download> 直链下载——此方式绕过 JavaScript 流程，由浏览器原生处理，杜绝中间解析污染。
总结：文件下载损坏几乎总是源于对二进制流的非必要干预。坚持“最小操作原则”——信任 res.blob() 的输出，透传原始响应头，及时释放资源，即可稳定支持任意二进制文件下载。
