download属性在跨域HTTP(S)链接中被浏览器静默忽略，仅对同源URL、blob:或data:协议生效；真正可控的下载路径是fetch获取二进制流后转为Blob并创建blob: URL触发下载。
download 属性在跨域文件流中根本不起作用
浏览器对 download 属性的执行有硬性安全边界：它只对同源 URL、blob: 或 data: 协议生效，对跨域 HTTP(S) 链接（如 https://oss.example.com/report.pdf）会静默忽略——不是“失效”，而是压根不触发下载逻辑。控制台通常不报错，但 Network 面板能看到请求发出后页面跳转或直接预览，这就是被拦截的典型表现。
常见误判是以为加了 download 就能强制下载，其实它连校验都不做，更谈不上“拦截”或“传输安全”。真正起作用的是浏览器内置的同源策略（Same-Origin Policy），而非该属性本身。
fetch + Blob 是唯一可控的前端文件流下载路径
要下载跨域资源或 API 返回的二进制流，必须走 JavaScript 主动拉取 + 本地构造的路径。核心在于绕过 a[download] 的同源限制，把响应体转为可信的 blob: URL：
-
fetch必须显式声明{ mode: 'cors' }，否则即使服务端开了 CORS，也可能因默认no-cors模式导致响应不可读 - 务必调用
response.blob()，而不是response.text()—— 后者会破坏二进制内容（PDF、Excel、ZIP 全乱码） - 从
Content-Disposition头提取文件名需服务端开启 CORS 共享该 header：Access-Control-Expose-Headers: Content-Disposition - 每次下载都应调用
URL.revokeObjectURL()，否则 blob URL 持久驻留内存，大文件多次操作易触发 OOM
服务端 Content-Disposition 才是真正的下载控制开关
前端 download 属性只是“建议”，而服务端返回的 Content-Disposition: attachment; filename="xxx.pdf" 响应头才是全浏览器兼容的强制下载指令。它不依赖同源，不关心前端用不用 <a> 标签，甚至直接访问 URL 也会触发下载对话框。
立即学习“前端免费学习笔记（深入）”；
关键点：
- 若接口需鉴权（如带 Cookie），服务端
Access-Control-Allow-Origin不能设为*，必须指定域名，且需配合credentials: 'include' - Nginx 等静态服务可通过
add_header Content-Disposition "attachment";统一启用，但无法动态设filename，适合固定命名资源 - iOS Safari 完全无视
download属性，也不支持blob:URL 的download，唯一稳解就是服务端加这个头
容易被忽略的兼容性与内存陷阱
看似几行代码就能搞定下载，实际卡点常在细节：
- IE 11 及更早版本不支持
fetch和Blob，需降级为XMLHttpRequest+responseType: 'blob' -
file://协议下所有方案均无效——本地双击 HTML 文件时，download、fetch、blob:全部罢工，必须起本地 HTTP 服务 - 动态创建
<a>元素后，必须先document.body.appendChild(a)再a.click()，否则 Safari 可能拒绝触发下载 - 不要复用同一个
blob URL多次下载，每次都要重新createObjectURL+revokeObjectURL，否则旧引用未释放会导致内存持续增长
真正难的不是写对代码，而是判断资源来源是否可控、服务端是否配合、目标用户是否用 Safari —— 这些决定你到底该写三行 JS 还是去改 Nginx 配置。
