使用 fetch + blob() 下载非文本文件（如图片、ZIP）时出现损坏，根本原因常是 Blob 构造方式错误或响应类型处理不当；本文提供标准修复方案及替代策略。
使用 `fetch` + `blob()` 下载非文本文件（如图片、zip）时出现损坏，根本原因常是 blob 构造方式错误或响应类型处理不当；本文提供标准修复方案及替代策略。
在前端通过 fetch 下载二进制文件（如 PNG、PDF、ZIP）时，若仅对响应调用 res.blob() 后再用 new Blob([blob], {...}) 二次封装，极易导致数据损坏——尤其对非文本格式敏感的文件（如图像头信息错位、ZIP 结构破坏），而纯文本 .txt 文件因容错性强仍可打开，从而掩盖问题。
根本问题在于冗余包装：
res.blob() 已返回一个完整、正确的 Blob 对象，而以下代码却将其作为“数据源”再次包裹：
.then((blob) => {
const urlBlob = new Blob([blob], { type: "application/octet-stream" }); // ❌ 错误！
// ...
});
这相当于把一个 Blob 当作原始字节流传入 Blob 构造器，浏览器会将其序列化为字符串（如 [object Blob]）再编码，彻底破坏二进制结构。
✅ 正确做法：直接使用 res.blob() 返回的 Blob，仅需显式设置 MIME 类型（推荐从响应头读取）：
fetch(this.baseUri + endpointURI)
.then((res) => {
if (!res.ok) throw new Error(`HTTP ${res.status}: ${res.statusText}`);
// 优先从响应头获取真实 content-type，避免硬编码
const contentType = res.headers.get("content-type") || "application/octet-stream";
return res.blob().then(blob => ({ blob, contentType }));
})
.then(({ blob, contentType }) => {
// ✅ 直接使用原始 blob，不二次封装
const url = window.URL.createObjectURL(
new Blob([blob], { type: contentType }) // 此处 [blob] 合理（blob 是 ArrayBufferView 或 Blob）
);
const a = document.createElement("a");
a.href = url;
a.download = attachmentName;
document.body.appendChild(a);
a.click();
document.body.removeChild(a); // 推荐用 removeChild 替代 remove（兼容性更稳）
window.URL.revokeObjectURL(url); // 及时释放内存
})
.catch(err => console.error("Download failed:", err));
⚠️ 关键注意事项：
- 绝不嵌套 Blob：new Blob([blob]) 中的 blob 若已是 Blob 实例，将触发隐式 toString()，导致二进制失真；
- 优先复用响应头 Content-Type：硬编码 "application/octet-stream" 可能导致浏览器无法正确识别文件类型（如 PDF 预览失败）；
- 务必调用 URL.revokeObjectURL()：防止内存泄漏；
- 服务端需正确设置 CORS 头：若跨域请求，后端必须包含 Access-Control-Expose-Headers: Content-Type, Content-Disposition，否则前端无法读取关键响应头。
? 当 CORS 或中间层导致不可控问题时（如题中“内部 API 无法暴露”场景），可采用安全的降级方案：
利用浏览器地址栏直连（无 CORS 限制）+ window.open() 触发下载。需确保目标 API 支持 Content-Disposition: attachment; filename="xxx" 响应头，并已配置好认证（如 SSO 或 Cookie 共享）：
// 安全前提：用户已登录，且 API 域名与当前页同源或信任域
const apiDirectUrl = `https://internal-api.example.com/files/${fileId}`;
window.open(apiDirectUrl, '_blank'); // 浏览器自动触发下载
此方案绕过 JavaScript 二进制处理，完全交由浏览器原生下载逻辑，规避所有前端解析风险，适用于受信内网环境。
总结：文件损坏多源于 Blob 的误用而非网络问题。坚持「一次 res.blob() + 原始 Blob 直接构造 URL」原则，并严格校验响应头与 CORS 配置，90% 的下载损坏问题即可解决。
