点击下载却秒开文件？这个HTTP头暗藏玄机

一次“乌龙”需求引发的思考

某天下午，后端程序员老张收到测试的紧急反馈：用户点击“下载合同”按钮，PDF文件却直接在浏览器里打开了，手机端用户抱怨根本找不到文件路径。老张一脸疑惑：“明明后端返回了文件流啊？”经过排查，他发现代码里少了一行设置——Content-Disposition: attachment。就是这行“消失的代码”，让用户操作体验天差地别。

核心逻辑：两个HTTP头如何“操控”浏览器行为

浏览器处理文件响应的逻辑，本质是一场资源类型和处理策略的博弈

Content-Type：告诉浏览器“这是什么”

例如application/pdf声明文件是PDF，浏览器会尝试用预览插件打开；

若设置为application/octet-stream，则视为“未知二进制流”，默认触发下载。 （但仅靠它并不完全可靠！）

Content-Disposition：告诉浏览器“怎么处理”

• inline：默认策略，允许浏览器自行决定（通常是预览）；
• attachment：强制下载，可搭配filename指定文件名（如filename=“合同.pdf”）；
• 特殊场景：attachment模式下，即使浏览器支持预览（如图片），也会跳过直接下载。

进阶避坑：为什么你设置了头却“不生效”？

优先级冲突：

Content-Disposition的权重高于Content-Type。若同时设置Content-Type: image/png和Content-Disposition: inline，浏览器仍会优先预览图片。

浏览器兼容性：

部分旧版浏览器（如IE）对filename中文编码识别异常，需额外转码

Safari浏览器对某些MIME类型（如text/plain）强制预览，需搭配attachment使用。

服务端代码误区：

Node.js中若使用res.sendFile()未设置header，默认Content-Disposition: inline；

Spring Boot需手动注入HttpServletResponse并调用setHeader方法。

终极方案：一张表搞定配置策略

需求场景	Content-Type	Content-Disposition
强制下载（通用文件）	application/octet-stream	attachment; filename=xxx
强制下载（特定类型）	真实类型（如image/jpeg）	attachment; filename=xxx
允许预览（可内嵌展示）	真实类型（如text/html）	inline（或省略）

细节决定用户体验

一个看似简单的“下载”功能，背后是HTTP协议与浏览器行为的精密配合。下次遇到类似问题时，不妨先打开开发者工具，在Network面板中揪出这两个关键头，或许答案就藏在其中。

🔥 关注我的公众号「哈希茶馆」一起交流更多开发技巧