有用户反馈，在网站上点击一个PDF附件链接，本来想在线看一眼内容，结果浏览器直接弹出下载框，文件保存到本地才能打开。对于需要快速预览的合同、说明文档或报表来说，这种体验并不理想。更麻烦的是，同一份文件在别的网站能直接打开，在自己网站上却总是下载，说明问题大概率不在文件本身，而在服务端返回的响应头。
先要分清责任边界。浏览器看到PDF链接时，会综合两个信息做决定：一是Content-Type，告诉浏览器这是什么类型的文件；二是Content-Disposition，告诉浏览器是内联展示还是作为附件下载。只要其中一项表达得不够明确，浏览器就可能选择更保守的下载行为。所以核对顺序应当从服务端响应头开始，再往外扩展到代理层和浏览器设置。
第一层核对Content-Type。正常在线预览的PDF，响应头应返回application/pdf。如果服务端把它写成了application/octet-stream，浏览器会把它当成未知二进制流，直接触发下载。这种情况常见于上传组件按默认类型存储、下载接口统一走二进制输出，或者文件类型映射表里缺少pdf条目。核对方法是打开浏览器开发者工具，切换到网络面板，点击链接后查看该请求的响应头，确认类型字段的实际取值。
第二层核对Content-Disposition。这个字段有两个关键取值：inline表示尽量在浏览器内展示，attachment表示作为附件下载。如果代码里固定写成了attachment，无论Content-Type是否正确，浏览器都会下载。此外还要留意文件名编码，中文文件名如果编码处理不当，部分浏览器会退回下载行为。核对时既要看取值，也要看文件名部分是否规范。
第三层核对中间链路。即使源站响应头正确，请求经过反向代理、CDN或对象存储时，响应头也可能被覆盖或改写。对象存储的私有文件通常默认以附件形式返回，CDN缓存规则也可能统一改写类型字段。核对方法是绕过代理直接访问源站地址对比响应头，或者查看代理和存储侧的响应头配置，确认没有强制下载的策略。
第四层核对浏览器侧。部分浏览器内置PDF预览功能被关闭，或者安全策略、下载类扩展拦截了内联展示，也会表现为直接下载。这部分属于服务端不可控范围，可以通过换浏览器、换设备对比来区分。如果其他环境能正常预览，就说明服务端配置基本到位，问题出在客户端环境。
实际操作时，建议先记录现状：保存当前响应头截图，记录请求地址、状态码和各字段取值。然后按Content-Type、Content-Disposition、中间链路、浏览器环境的顺序逐项调整，每改一项就刷新验证一次，避免多处同时改动后无法判断哪一步生效。
it数运在网站维护中处理这类问题时，通常先确认响应头现状，再区分服务端可控与客户端不可控的部分，按链路顺序排查而不是凭感觉改配置。涉及具体服务器、代理和存储环境的配置方式各有差异，实际调整应以当前环境的真实配置为准。
