download属性跨域时被浏览器同源策略静默忽略，仅同源有效；服务端设Content-Disposition响应头最可靠，纯前端需fetch+Blob fallback但受限于内存和iOS Safari。
download属性跨域时根本不起作用，不是兼容性问题
现代浏览器（Chrome、Firefox、Edge、Safari）对 download 属性执行的是同源策略硬限制：只要 href 与当前页面协议、域名、端口任一不同，该属性就被静默忽略——点击后跳转或预览，不会下载，也不会报错。这不是“不兼容”，而是主动拦截。
常见误判场景包括：
- 本地双击 HTML 文件（
file://协议），所有相对路径或绝对 URL 都被视作跨源 -
https://app.com页面里写<a href="https://cdn.example.com/report.pdf" download="report.pdf">→ 实际打开 PDF - 接口地址如
/api/export?id=123与前端不同源 →download完全无效
验证是否生效最直接的方法：右键链接 → “另存为”，弹出保存框才说明起效；否则就是被浏览器绕过了。
服务端加 Content-Disposition 是最轻量可靠的解法
如果后端可控，一行响应头就能彻底绕过前端所有限制：Content-Disposition: attachment; filename="data.csv"。它不依赖 JS、不关心同源、兼容 IE11+，且对静态资源（CDN）、动态接口都适用。
立即学习“前端免费学习笔记（深入）”；
但必须满足两个硬性条件：
- 响应头需被 CORS 显式暴露：
Access-Control-Expose-Headers: Content-Disposition - 中文文件名必须用
filename*=UTF-8''report%E5%8D%B0%E5%85%B3.csv格式，否则旧版 Safari 可能截断
注意：若服务端返回的是 text/plain 或 application/json 等可预览类型，即使有 download 属性，浏览器也可能优先渲染；而 Content-Disposition 会强制覆盖该行为。
纯前端 fallback：fetch + Blob 方案的实操要点
当服务端不可控（如第三方 CDN、遗留 API），唯一可行的前端方案是用 fetch 拉取二进制流，再通过 Blob 构造同源临时 URL。关键点不是“能不能做”，而是“怎么不翻车”：
- 必须用
response.blob()，不能用response.text()—— 否则 PDF/ZIP 会损坏 -
a.download值必须显式指定，不能依赖 URL 路径（接口地址本身不含文件名） - 每次调用
URL.createObjectURL(blob)后，必须立即配对调用URL.revokeObjectURL(url)，否则内存持续增长 - 大文件（>50MB）慎用，全量加载进内存可能卡死页面甚至 OOM
iOS Safari 全系不支持脚本触发下载（a.click() 无效），此方案在此平台彻底失效，只能引导用户手动“另存为”。
容易被忽略的边界细节：空值、中文、路径字符
download 属性值不是“建议名”，而是强制使用的文件名，但它有明确限制：
- 值中不能含
/、\、控制字符等路径分隔符，否则整个属性被静默丢弃 - 空字符串（
download=""）会让浏览器尝试从href解析文件名，失败则 fallback 到unknown - 中文支持没问题，但含空格时属性值必须用引号包裹：
download="销售报表 2024.xlsx"
最麻烦的是：这个限制在开发阶段极难暴露——本地 file:// 下测试全绿，上线后跨域即崩；而错误又没有任何提示，只能靠右键“另存为”验证是否真触发了下载逻辑。
