不能，File System Access API 仅允许用户授权后通过句柄读写文件，需调用 createWritable() 获取可写流并显式 close() 才能落盘，不支持追加模式，且仅 Chromium 102+ 支持、须 HTTPS/localhost 环境。
File System Access API 能否真正“直接编辑”本地文件？
不能，但可以无限接近——它允许网页在用户明确授权后，获得对单个文件或整个目录的读写句柄，后续操作（读、写、保存）不再需要反复弹窗。关键在于：showOpenFilePicker 和 showSaveFilePicker 返回的是 FileSystemFileHandle，它封装了底层访问权限，不是一次性 blob 读取。
为什么 await fileHandle.getFile() 之后不能直接改写磁盘？
因为 getFile() 只返回一个只读的 File 对象（类似 input[type=file] 的结果），它只是当前快照，不带写能力。真要编辑，必须用句柄创建可写流：
-
const writable = await fileHandle.createWritable()—— 这才是打开写通道的关键一步 - 写入后必须显式调用
await writable.close()，否则内容不会落盘（常见坑：忘了 close，以为写成功了） - 如果想追加内容，需先
await fileHandle.getFile()读出原内容，再拼接后全量重写（API 不支持 append 模式）
如何安全地实现“编辑-保存”闭环，避免覆盖误操作？
用户点“保存”时，不应默认复用原句柄——尤其当文件可能被外部程序修改过。推荐策略：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- 首次打开用
showOpenFilePicker({ multiple: false, excludeAcceptAllOption: true })获取句柄并缓存到组件状态（如 React 的useState） - 点击保存时，优先尝试
fileHandle.createWritable()；若失败（如文件被锁、权限变化），再 fallback 到showSaveFilePicker弹新对话框 - 务必捕获
NotAllowedError（用户取消授权）和SecurityError（跨域 iframe 或非安全上下文），这些错误无法静默恢复
示例核心片段：
async function saveContent(fileHandle, content) {
try {
const writable = await fileHandle.createWritable();
await writable.write(content);
await writable.close(); // 必须！
} catch (err) {
if (err.name === 'NotAllowedError') {
// 用户拒绝，引导重新 pick
const newHandle = await window.showSaveFilePicker({ ... });
await saveContent(newHandle, content);
}
}
}
兼容性与降级必须考虑的硬限制
该 API 目前仅 Chromium 102+ 原生支持（Chrome、Edge、Opera），Firefox 和 Safari 完全未实现。更关键的是：
- 必须运行在 HTTPS 或
localhost（http://127.0.0.1不行） - 不能在 sandboxed iframe 中使用（除非显式声明
allow="filesystem"） - 移动浏览器（包括 Chrome for Android）暂不支持 —— 所有“编辑本地文件”功能在手机端会直接不可用
真实项目中，建议用 if ('showOpenFilePicker' in window) 检测后，再决定是否渲染编辑控件；否则回退到传统 <input type="file"> + 下载 Blob 链接的组合方案。
