EdgeLegacyPDF下载功能是否可用？

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

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

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

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

Content-Type: application/pdf
Content-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 下它就是个摆设。

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

今天关于《EdgeLegacyPDF下载功能是否可用？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于常见HTML属性兼容性问题有哪些的内容请关注golang学习网公众号！