allow-downloads 必须作为 sandbox 属性的值中一个 token 才生效，需搭配 allow-scripts（js）、allow-forms（表单）等使用，仅 chrome 89+ 支持，firefox/safari 不支持，推荐用 postmessage 或服务端 content-disposition 替代。
allow-downloads 要配在 sandbox 里才生效
allow-downloads 不是独立属性，必须作为 sandbox 的一个 token 出现在其值中。只写 allow-downloads 或单独加 download 属性没用——浏览器根本不会识别。
常见错误写法：<iframe src="report.html" allow-downloads></iframe>（无效），或 <iframe sandbox="allow-downloads" src="report.html"></iframe>（能启用下载，但其他能力全锁死，连 JS 都不执行）。
- 必须搭配
allow-scripts才能让页面内触发<a download></a>的 JS 逻辑跑起来 - 如果页面还要提交表单导出文件，得额外加
allow-forms -
allow-downloads本身不开放网络请求权限，fetch/XHR 仍受同源限制，除非也加allow-same-origin（仅同源时有效）
Chrome 89+ 才支持，旧版浏览器会静默忽略
allow-downloads 是 Chrome 89（2021 年初）引入的，Firefox 和 Safari 目前**完全不支持**。这意味着：
- 在 Firefox 中，即使写了
sandbox="allow-downloads"，<a download="data.csv"></a>点击后仍会被拦截，控制台无报错，行为静默失败 - Edge 基于 Chromium，支持；Safari 用户看到的是“无法下载”或链接无响应
- 不能靠 UA 判断，必须实测：可在控制台执行
document.querySelector('iframe').sandbox，返回字符串含allow-downloads才说明被识别
和 allow-same-origin 一起用有风险，别乱加
allow-downloads 本身不破坏隔离，但它常被误配进高危组合里。比如：
-
sandbox="allow-scripts allow-same-origin allow-downloads"→ 如果 iframe 加载的是跨域不可信内容，allow-same-origin实际被浏览器忽略，但配置暴露了安全疏漏；若真同源，则 localStorage / cookie 可读写，下载功能反而成了攻击入口点 - 真正需要下载的场景（如内部报表系统），应确保 src 是同源可信地址，且避免同时开
allow-top-navigation或allow-popups - 如果只是让用户点击下载预生成的文件（如 PDF），用
srcdoc+sandbox="allow-downloads"更轻量、更可控
替代方案比硬配 allow-downloads 更可靠
依赖 allow-downloads 容易掉坑里，尤其要兼容多浏览器时。更稳的做法：
- 父页提供下载按钮，通过
postMessage触发子页返回 Blob URL，再由父页创建<a download></a>下载（跨域/同域都行，且不依赖 sandbox） - 子页用
fetch获取文件后调用window.open(URL.createObjectURL(blob))，绕过download属性限制（但需注意 popup 拦截） - 服务端直接设
Content-Disposition: attachment响应头，让链接点击即下载，完全不走 iframe 内 JS
真正难的不是怎么写这个 token，而是判断它是否必要——多数生产场景里，下载逻辑挪到父页或服务端，比在 sandbox 里开洞更干净。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
