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

download 属性在 Edge Legacy 中对 PDF 无效，因其 PDF 引擎强制内嵌打开且未实现该属性；唯一可靠方案是后端设置 Content-Disposition: attachment 响应头。

download 属性在 Edge Legacy 中对 PDF 文件基本无效 —— 它不会触发下载，也不会绕过内置 PDF 查看器，而是被直接忽略。

为什么 download 在 Edge Legacy 里不生效

Edge Legacy 使用的是独立的 PDF 渲染引擎（非 PDFium），且其行为受浏览器策略强管控。当遇到 <a href="doc.pdf" download> 这类标记时，它会优先走内建 PDF 阅读器流程，而非下载逻辑。

这个限制不是 bug，而是设计使然：微软当时将 PDF 视为“第一类网页内容”，默认强制内嵌打开，download 属性未被该引擎识别或实现。

• 即使 PDF 响应头包含 Content-Disposition: attachment，Edge Legacy 仍可能忽略并坚持渲染
• download 对同源 HTML、图片、ZIP 等文件有效，唯独 PDF 是特例
• 没有已知的 polyfill 或 JS 替代方案能绕过这一限制（Blob + createObjectURL 同样被拦截）

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

前端无法靠 download 属性解决，必须后端配合。服务端需确保响应中明确设置：

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

这样 Edge Legacy 才会放弃内嵌，弹出保存对话框。

• 仅设 Content-Type 不够，必须带 attachment 指令
• 如果使用 Nginx，需确认未启用 pdf 类型的自动 inline 处理模块
• IIS 用户注意：MIME 类型映射正确，且 staticContent 节点未覆盖 .pdf 的处理行为

升级到 Chromium Edge 后行为变化

Chromium 内核的 Edge（v79+）已支持 download 属性对 PDF 生效，但前提是满足两个条件：

• PDF 文件必须同源（跨域时会被 CORS 阻止，即使加了 crossorigin 也无用）
• 服务器不能返回 Content-Disposition: inline，否则仍会优先打开

换句话说：Chromium Edge 下 download 可用，但比普通文件更敏感；而 Edge Legacy 下它就是个摆设。

真正要兼容旧环境，别指望属性，得从服务端响应头入手 —— 这是唯一稳定可控的路径。