showsavefilepicker需在https或localhost安全上下文中运行，否则静默失败或抛securityerror；用户取消时promise会reject而非返回null，须用catch捕获；types是类型建议而非过滤器，suggestedname需显式匹配内容类型后缀；批量保存应打包为zip单次调用；ios safari不支持，需降级为download链接。
直接用 window.showSaveFilePicker，但必须在 HTTPS 或 localhost 环境下运行，否则会静默失败或抛出 SecurityError。
为什么 showSaveFilePicker 调用后没反应或报错？
最常见原因是环境不满足安全要求：该 API 只在安全上下文（HTTPS 或 localhost）中可用。开发时若用 file:// 协议双击打开 HTML，必然失败，且控制台可能只显示模糊的 DOMException，不带具体信息。
另一个高频问题是未正确处理 Promise 拒绝：用户取消对话框时，Promise 会 reject，不是返回 null 或 undefined。不加 catch 容易让后续逻辑中断。
- 检查当前 URL 是否以
https://或http://localhost（含端口）开头 - 避免在页面加载完成前就调用，确保 DOM 和执行环境就绪
- 始终用
.catch(e => console.error('保存被取消或出错:', e))捕获拒绝情况
showSaveFilePicker 的 types 参数怎么写才真正生效？
types 不是“过滤器”，而是“建议列表”——它影响系统对话框里默认显示哪些文件类型，但用户仍可手动切换到“所有文件”。它的实际作用是提升体验，而非强制限制。
MIME 类型写得太宽泛（比如 application/*）会导致浏览器忽略 accept 中的扩展名；写得太窄（比如 application/json）又可能让非标准后缀（如 .smm）无法被选中。
- 推荐写法：
{ description: 'JSON 文件', accept: { 'application/json': ['.json', '.smm'] } } - 如果想支持多种 MIME，可传多个对象：
[{...json...}, {...text...}] -
suggestedName很有用：它会预填对话框里的文件名，用户可直接回车确认，减少操作步骤
保存 Blob 时，怎么确保文件名和类型匹配？
浏览器不会根据 Blob 的 type 字段自动修正后缀名。比如你传入一个 type: 'image/png' 的 Blob，但 suggestedName 是 'report.txt'，最终保存的仍是 .txt 文件——系统不会帮你改成 .png，也不会报错。
这意味着：文件名后缀必须由你显式控制，且应与内容类型一致，否则用户双击可能打不开。
- 生成
suggestedName时，优先从内容类型推导后缀：例如type === 'application/json' ? 'data.json' : 'export.pdf' - 如果用户修改了文件名但删掉了后缀，
showSaveFilePicker仍会按原accept列表中的扩展名补全（仅限桌面 Chrome/Edge） - 不要依赖 Blob 的
type做校验——它只是提示，可被伪造；关键靠你自己构造合法的suggestedName和types
一次选路径、多次写文件，为什么不能直接循环调用 showSaveFilePicker？
每次调用 showSaveFilePicker 都会弹新对话框，用户得重复点三次“保存”才能存三个文件。这不是设计缺陷，而是规范明确要求：每个文件都需独立授权，防止恶意脚本静默写入。
真要批量保存，唯一合规路径是打包——用 JSZip 合并为单个 ZIP，再调用一次 showSaveFilePicker 保存这个压缩包。
- ZIP 方案兼容性好，且能保留原始文件名和目录结构
- 注意：
JSZip.generateAsync({ type: 'blob' })返回的是 Promise，需 await 再传给writable.write() - 移动端 Safari 目前不支持
showSaveFilePicker，打包后仍需降级为download属性链接
真正麻烦的不是 API 多难写，而是每一步都依赖用户主动授权、每一步都可能因环境或配置被截断——它不是“保存文件”的快捷键，而是一套最小权限模型的落地。别绕过它，得顺着它设计交互。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
