a标签download属性仅同源有效，跨域时被浏览器静默忽略；真正触发CORS的是fetch请求，需后端配置Access-Control-Allow-Origin等响应头，或采用服务端代理方案。
下载链接触发 CORS 错误，其实根本没走下载流程
浏览器对 <a download></a> 标签有严格限制：只有同源 URL 或 blob: 协议的地址才能触发下载；如果 href 指向跨域资源（比如 https://api.example.com/file.pdf），点击后浏览器会直接导航跳转或报错，**不会发起带 Origin 头的请求**，所以你看到的“跨域错误”往往不是 CORS 本身报的，而是控制台里出现的 Failed to execute 'download' on 'HTMLAnchorElement': Invalid filename or URL 或空白页跳转。真正触发 CORS 的是 JS 主动 fetch，不是 <a download></a>。
用 fetch + Blob 绕过 download 同源限制
想让跨域资源可下载，必须由前端主动拉取内容，再构造本地 Blob URL。关键点在于后端要允许跨域且返回 Access-Control-Allow-Origin: *（或指定域名），否则 fetch 就卡在预检或响应拦截。
- 后端必须设置
Access-Control-Allow-Origin，仅设Access-Control-Allow-Headers不够 - 如果资源需认证（如带
Authorization头），后端还得加Access-Control-Allow-Credentials: true，且fetch要显式传credentials: 'include' -
fetch响应不能是redirect（如 302），否则跨域重定向会被浏览器拒绝；后端最好直接返回文件内容，不要跳转 - 示例代码：
const link = document.createElement('a'); fetch('https://api.example.com/report.xlsx', { credentials: 'include' }) .then(r => r.blob()) .then(blob => { link.href = URL.createObjectURL(blob); link.download = 'report.xlsx'; link.click(); URL.revokeObjectURL(link.href); // 及时释放 });
Content-Disposition 头影响文件名，但不解决跨域
后端返回 Content-Disposition: attachment; filename="xxx.xlsx" 能提示浏览器保存名，但这个头对跨域请求是否成功毫无作用——它只在响应已成功到达前端后才起效。如果 fetch 因 CORS 被拦，这个头压根不会出现在响应里。
- 前端无法通过 JS 读取响应头里的
filename，除非后端额外提供Access-Control-Expose-Headers: Content-Disposition - 更可靠的做法是：后端在响应体或单独接口里返回文件名，或前端自己约定命名规则（如从 URL path 提取）
- 注意：Safari 对
Blob下载支持不稳定，大文件可能触发内存警告，建议加try/catch并 fallback 到新窗口打开（window.open(url)）
代理或服务端中转是最稳妥的兜底方案
当无法控制第三方 API 的 CORS 配置，或资源本身不允许跨域读取（比如 S3 默认私有桶），唯一通用解法是走自己后端代理：
立即学习“前端免费学习笔记（深入）”；
- 前端请求自己的
/api/proxy-download?url=https%3A%2F%2Fthird-party.com%2Ffile.zip - 后端用 HTTP client（如 Node.js 的
axios、Python 的requests）转发请求，并把响应流式透传回前端 - 这样前端始终请求同源地址，完全规避 CORS；同时后端可统一加鉴权、限流、日志
- 注意：代理需处理好响应头（如
Content-Type、Content-Length），并避免缓存污染（加Cache-Control: no-store）
真正难的不是写几行 fetch，而是厘清「谁在发请求」「谁在检查跨域」「谁决定能不能下载」——这三个角色经常被混为一谈。一旦发现控制台没网络请求，或者请求方法是 OPTIONS 卡住，问题就一定出在服务端响应头配置上，而不是前端 JS 写错了。
