用 content-length 长度确定后端返回的是不是真实的文件流

是的，你可以 100% 确定后端返回的绝对不是真实的文件流。

几百 MB 的文件，Content-Length 只有 39，这中间差了十万八千里。这个 39 字节，极大概率是后端返回的一段简短的文本提示或者错误信息。

🔍 为什么是 39？

你可以算一下，39 个字节通常就是一句非常简短的话。比如：

• 英文："File not found, please check." 刚好是 30 个字节左右。
• 中文："文件不存在，请核对后重试" 加上标点符号，UTF-8 编码下也差不多是 30-40 个字节。
• JSON：{"code":500,"msg":"error"} 这种简短的 JSON 字符串也在这个范围内。

🛠️ 接下来怎么排查？

既然确定了不是文件流，那这 39 个字节里到底写了什么，就是解决问题的关键。你可以用以下两种方法把它“揪”出来：

1. 在浏览器 Network 面板直接看：
   在开发者工具的 Network 标签页里，点击这个下载请求，切换到 Response（响应） 或 Preview（预览） 标签。里面显示的那短短的一行字，就是后端给你的真实反馈（比如“令牌已过期”、“文件ID无效”或“系统异常”等）。
2. 用 Postman 或 cURL 请求：
   带着你的令牌去请求这个接口，Postman 的 Body 里会直接把那 39 个字节的文本打印出来。

💡 补充一个技术细节

在极少数情况下，如果后端使用了 Transfer-Encoding: chunked（分块传输）并且没有正确设置 Content-Length，某些中间件（比如 Nginx、Vite 代理或 CDN）可能会错误地自动添加一个不准确的 Content-Length。
但即便如此，39 这个数值也太小了，完全不符合几百 MB 文件的特征。所以，大概率就是后端接口报错了，返回了一段简短的报错文本。

快去 Network 面板的 Response 里看看那 39 个字节到底写了什么吧，找到报错信息后，直接拿着去问后端同事，问题就能迎刃而解！