File System API 的 showSaveFilePicker() 在弹出窗口（popup）中调用时会因跨浏览上下文权限限制而静默失败——虽能获取文件句柄，但后续 createWritable() 和 write() 操作被阻断，导致生成空文件且无错误日志。根本原因在于弹出窗口缺乏持久的用户手势上下文（user gesture context），无法维持对现代存储 API 的完整访问权限。
file system api 的 `showsavefilepicker()` 在弹出窗口（popup）中调用时会因跨浏览上下文权限限制而静默失败——虽能获取文件句柄，但后续 `createwritable()` 和 `write()` 操作被阻断，导致生成空文件且无错误日志。根本原因在于弹出窗口缺乏持久的用户手势上下文（user gesture context），无法维持对现代存储 api 的完整访问权限。
现代浏览器（Chrome 86+、Edge 86+）对 File System Access API 施加了严格的用户手势（user gesture）绑定机制：showSaveFilePicker() 必须在由用户直接触发（如 click、keydown）的同步执行路径中调用，且该手势上下文不可跨 window.open() 创建的独立浏览上下文（即 popup 窗口）传递。即使你显式传入 win = popupWindow 并调用 popupWindow.showSaveFilePicker()，一旦 popup 是通过 window.open() 动态创建的（尤其在同源受限或跨域场景下），其内部的 showSaveFilePicker() 虽能返回 FileSystemFileHandle（因此日志显示 “got a file handle”），但后续 fileHandle.createWritable() 会因缺少有效手势上下文而静默拒绝——既不抛出异常，也不触发 .catch() 回调，最终仅创建零字节文件。
这正是你观察到的现象：代码执行到 console.log("got a file handle") 后中断，createWritable().then(...) 中的回调完全不执行，也无任何 rejectWritable 日志输出。
✅ 正确解决方案（推荐两种实践路径）
方案一：避免弹出窗口 —— 使用模态 div 覆盖层（推荐首选）
将编辑界面嵌入主窗口 DOM，通过 CSS 实现“伪弹窗”，完全复用主窗口的用户手势上下文：
<!-- 主页面中 -->
<div id="editorModal" style="display:none; position:fixed; z-index:1000; top:20%; left:50%; transform:translateX(-50%); background:white; padding:20px; border-radius:8px; box-shadow:0 4px 12px rgba(0,0,0,0.15);">
<textarea id="editArea" rows="10" cols="50"></textarea>
<br><br>
<button onclick="saveFromModal()">保存到文件</button>
<button onclick="document.getElementById('editorModal').style.display='none'">取消</button>
</div>// 复用原函数，无需传 window 参数
async function saveFromModal() {
const text = document.getElementById('editArea').value;
try {
const options = {
types: [{
description: 'Text files',
accept: { 'text/plain': ['.txt'] }
}],
suggestedName: 'EditedContent.txt'
};
const fileHandle = await window.showSaveFilePicker(options);
const writable = await fileHandle.createWritable();
await writable.write(text);
await writable.close();
console.log('✅ 文件保存成功！');
} catch (err) {
console.error('❌ 保存失败：', err);
}
}✅ 优势：零跨上下文风险、完整错误捕获、响应式友好、无需服务端介入。
⚠️ 注意：确保 saveFromModal() 绑定在用户直接触发的事件（如按钮 click）上，避免异步延迟（如 setTimeout）导致手势失效。
方案二：服务端代理（适用于需真正独立窗口场景）
若必须使用独立窗口（如需多屏协作、强制焦点隔离），应避免前端直接调用 File System API，改用服务端中转：
- 弹出窗口（HTTPS 上下文）通过 fetch 将编辑后数据 POST 至后端（如 PHP/Node.js）；
- 后端接收数据并生成文件，返回下载链接或直接流式响应；
- 主窗口或弹窗调用 location.href = '/download?file=xxx' 触发浏览器原生下载。
// 弹窗中（需 HTTPS）
async function saveViaServer() {
const text = document.getElementById('editArea').value;
const response = await fetch('/api/save-text.php', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ content: text, filename: 'data.txt' })
});
if (response.ok) {
const blob = await response.blob();
const url = URL.createObjectURL(blob);
const a = Object.assign(document.createElement('a'), { href: url, download: 'data.txt' });
document.body.appendChild(a);
a.click();
document.body.removeChild(a);
URL.revokeObjectURL(url);
}
}✅ 适用场景：需跨域协作、支持旧浏览器、规避客户端存储权限限制。
⚠️ 注意：必须确保弹窗为 HTTPS 加载（window.open('https://...')），否则 fetch 可能被混合内容阻止。
总结
- ❌ window.open() 创建的弹窗无法继承主窗口的 File System API 权限，createWritable() 静默失败是设计使然，非代码 Bug；
- ✅ 优先采用 模态 div + 主窗口 API 调用，安全、简洁、可调试；
- ? 若必须独立窗口，请转向 服务端文件生成 + 下载流，绕过客户端存储限制；
- ? 所有 File System API 调用务必置于用户直接触发的同步事件处理函数中，并使用 async/await + try/catch 替代 .then().catch() 以确保错误可捕获。
遵循以上原则，即可彻底规避“零字节文件”与“无日志静默失败”问题。
