<button>无法直接触发下载，必须通过JavaScript创建临时元素或使用fetch+Blob API；download属性仅对标签有效，且需注意CORS、Content-Disposition、Safari兼容性及内存泄漏等问题。
<button> 本身不能触发下载，必须配合 JavaScript 才能实现真正意义上的“点击下载” —— 尤其当目标文件是跨域、动态生成或二进制（如 Excel、PDF）时。
为什么不能直接给 <button> 加 download 属性？
download 是 <a> 标签的专属属性，写在 <button> 上完全被浏览器忽略。常见错误写法：<button download="data.csv">下载</button> → 点击无反应，控制台也无报错，纯静默失效。
哪怕你用 JavaScript 动态设置 button.download，依然无效 —— DOM 属性不等于 HTML 属性，且浏览器根本不读取 button 元素上的 download。
- 唯一合法使用
download的地方是<a>标签 -
<button>只能作为“触发器”，真正干活的是 JS 创建的临时<a>或fetch流程 - 想绕过同源限制、处理 API 返回的 blob、支持 Safari 移动端？必须走 JS 路线
用 fetch + Blob 下载 API 返回的文件
这是目前最通用、兼容性最好、能处理跨域和动态内容的方式。适用于后端返回 Content-Type: application/octet-stream 或 application/vnd.openxmlformats-officedocument.spreadsheetml.sheet 等响应的场景。
立即学习“前端免费学习笔记（深入）”；
关键点不是“怎么写 fetch”，而是怎么把响应正确转成可下载的 blob 并触发点击：
- 务必指定
response.blob()，不能用response.text()处理二进制文件（会乱码） - 创建
URL.createObjectURL(blob)后，必须配对调用URL.revokeObjectURL(url)，否则内存泄漏 -
<a>元素必须已挂载到 DOM（document.body.appendChild(a)），Safari 才认这个 click - 设置
a.download值时，不要带路径（如"./export/report.xlsx"），只写文件名（如"report.xlsx"）
简短示例：
function downloadFromApi(url, filename) {
fetch(url, { method: 'GET' })
.then(r => {
if (!r.ok) throw new Error(`HTTP ${r.status}`);
return r.blob();
})
.then(blob => {
const url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.href = url;
a.download = filename; // 如 "data-202407.xlsx"
document.body.appendChild(a);
a.click();
document.body.removeChild(a);
URL.revokeObjectURL(url);
})
.catch(err => console.error('下载失败:', err));
}
用 <a> 模拟按钮样式，但保留原生下载能力
如果文件是静态资源（如 /assets/manual.pdf），且与页面同源，最简单可靠的做法是：不用 <button>，改用 <a>，再用 CSS 把它“伪装”成按钮。
这样既享受原生 download 属性的稳定性，又避免 JS 错误、CORS、内存泄漏等所有潜在问题。
- 确保 href 指向真实可访问的 URL（不能是
javascript:void(0)或空字符串） - 同源前提下，
<a href="/files/log.zip" download="app-log.zip">下载日志</a>就是完整闭环 - Safari 桌面版支持
download，但 iOS/iPadOS 全系不支持 —— 此时需 fallback 到window.open(href)（会打开新页预览，无法强制下载） - 本地开发时用
file://协议？download属性彻底失效，必须起本地 HTTP 服务（如npx serve）
容易被忽略的三个硬伤
实际项目里，90% 的下载失败不是代码写错，而是卡在这几个细节上：
- 服务端没配 CORS：跨域请求
fetch时，若响应头不含Access-Control-Allow-Origin，fetch 直接拒绝，连 blob 都拿不到 - 后端返回了
Content-Disposition: inline：这会让浏览器优先尝试预览，即使前端用了 blob 方案，也可能被拦截（尤其 Chrome） - 移动端 Safari 对
blob:URL 的支持极不稳定：部分版本点击无反应，或提示“无法下载”，此时只能降级为跳转预览
真正健壮的下载逻辑，从来不是“写完就跑”，而是先确认协议、域名、响应头、终端环境这四层是否全部过关。
