核心逻辑：两个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方法。