download属性在移动端不可靠，ios safari全系无效，android主流浏览器仅部分支持，微信等webview普遍禁用，纯前端无法实现无缝下载，必须依赖服务端content-disposition响应头与同源代理配合。
download属性在移动端根本不可靠，别指望它能“无缝”
直接说结论：download 属性在绝大多数移动端浏览器里，要么被静默忽略，要么触发后变成预览而非保存。尤其是 iOS Safari 全系（包括 2026 年最新版），download 属性完全无效，且不响应 a.click() —— 这不是 bug，是 Apple 明确的设计限制。Android 上 Chrome/Edge 虽支持，但微信、QQ、支付宝等内置 WebView 基本都禁用该行为，防止页面未经用户确认就写入文件。所谓“无缝保存”，在纯前端层面不存在；能做的，只是在不同环境里争取最接近目标的降级路径。
同源 + HTTPS 是 download 属性唯一能生效的前提
即使在支持它的 Android 浏览器中，download 也只对严格同源的 URL 生效：
-
href必须和当前页面协议、域名、端口完全一致，比如页面在https://app.example.com，那么href="/files/report.pdf"可以，但href="https://cdn.example.com/report.pdf"（子域不同）或href="https://api.example.com/export?id=123"（跨端口或需鉴权）就会退化为跳转或预览 - 控制台会静默出现警告：
download attribute has no effect on cross-origin links，但不会报错，容易被忽略 -
file://协议下该属性彻底失效，本地双击 HTML 文件测试毫无意义，必须走http://localhost或真实 HTTPS 域名 - 服务端响应头最好带
Content-Disposition: attachment; filename="xxx.pdf"，这比仅靠download属性更可靠，尤其对微信内嵌浏览器
跨域或 iOS 场景必须用 fetch + Blob + click 组合拳
这是目前覆盖最广的“强制下载”方案，但要注意它在 iOS Safari 中仍会失败（只预览），所以必须配合服务端兜底：
- 前端用
fetch拉取文件流，调用res.blob()转为 Blob，再用URL.createObjectURL(blob)创建同源临时 URL -
a.download的值只是建议名，Safari 可能无视它而用原始 URL 名或 fallback 为unknown；真正可控的文件名要靠服务端在响应头里设Content-Disposition - 必须在用户手势（如
click事件）内调用a.click()，否则会被浏览器拦截为非交互行为 - 每次调用后务必执行
URL.revokeObjectURL(url)，否则 Blob 对象长期驻留内存，大文件多次下载可能引发 OOM - 对 >50MB 的文件，此法风险高，应改由服务端生成直链并重定向，或使用
<iframe src="xxx"></iframe>触发（部分安卓 WebView 支持）
iOS Safari 和微信 WebView 需要服务端主动配合
这是最容易被忽略的硬性依赖：纯前端代码在 iOS 上无法绕过“只能预览”的限制。唯一可行路径是让服务端返回正确的响应头，并确保链接可被识别为附件：
- 后端接口（如
/api/export?format=pdf）必须返回Content-Type: application/pdf+Content-Disposition: attachment; filename="xxx.pdf" - 链接不能是 CDN 直链（iOS 不认
Content-Disposition），必须走同源代理（如/proxy/file?u=https://oss.xxx.com/a.pdf），由代理服务透传响应头 - 微信内打开时，如果响应头正确，用户长按链接会弹出“在浏览器中打开”或“用XX应用打开”，此时选择 Safari 才可能触发下载；直接点开仍大概率预览
- 对 PDF，可在页面加显式提示：“长按链接 → 选择‘在Safari中打开’→ 点击右上角‘分享’→ ‘存储到文件’”，这是目前 iOS 用户唯一稳定保存路径
Content-Disposition 响应头和服务端同源代理都是绕不开的基础设施。前端能控制的只是触发时机和提示文案，真正的保存动作，永远需要操作系统和浏览器共同放行。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
