Edge Legacy中download属性对PDF文件有效吗？

Edge Legacy 浏览器中 PDF 下载问题的分析与解决方案

先说一个比较棘手的问题：在 Edge Legacy 下，想要让用户下载 PDF 文件，直接使用 download 属性实际上是行不通的。它既不会触发下载，也不会绕开内置的 PDF 查看器，基本等同于无效。

出现这个问题的原因在于 Edge Legacy 的 PDF 渲染引擎基于独立技术开发（并非后来 Chromium 所用的 PDFium），其默认优先执行“内嵌查看”流程，而非“下载”逻辑。你写下的 ，在它看来几乎与普通链接没有区别。

这不算严格意义上的 Bug，更像是一种设计选择——微软当时将 PDF 视为“第一类网页内容”，默认以内嵌方式打开，而 download 属性并未被该引擎识别或实现。

需要注意几个细节：

• 即便服务器响应头已经设置了 Content-Disposition: attachment，Edge Legacy 有时仍会强制展示 PDF。
• 同一个 download 属性对同源的 HTML、图片、ZIP 文件均有效，唯独 PDF 成为例外。
• 目前也没有 JavaScript polyfill 能够绕开这个限制，连 Blob 配合 createObjectURL 的方式也被堵死。

替代方案：使用 Content-Disposition 响应头强制下载

既然前端无法通过属性解决，就需要后端配合。唯一可靠的办法是服务端在返回 PDF 文件时明确设置响应头：

Content-Type: application/pdf
Content-Disposition: attachment; filename="document.pdf"

这样 Edge Legacy 才会放弃内嵌，弹出保存对话框。仅设置 Content-Type 是不够的，必须带上 attachment 指令。

另外，如果使用 Nginx，需要确认是否开启了 PDF 类型的自动 inline 处理模块；若使用 IIS，则需确保 MIME 类型映射正确，并且 staticContent 节点没有被覆盖。

升级到 Chromium Edge 后的变化

切换至 Chromium 内核的 Edge（v79 及更高版本）后，download 属性对 PDF 开始生效，但仍有两个前提条件：

• PDF 文件必须同源。跨域情况下会被 CORS 阻止，即便添加了 crossorigin 属性也无济于事。
• 服务器不能返回 Content-Disposition: inline，否则浏览器仍会优先打开而非下载。

简单总结：在 Chromium Edge 下 download 属性可用，但对 PDF 的敏感度远高于普通文件；而在 Edge Legacy 下，该属性完全无效。

因此结论很明确：要实现旧版 Edge 下的 PDF 下载兼容，不应只依赖前端属性，从服务端响应头入手才是最稳定可控的路径。