Firefox中FileSystem API的用途、可行场景及扩展lightning-fs构想

一、可行应用场景 #

针对Firefox支持的File System Access API核心能力（showOpenFilePicker、showDirectoryPicker、FileSystemWritableFileStream等），这些场景完全可行：

• 本地文档编辑器：读取用户指定的本地文本/Markdown文件，在线编辑后直接写回原文件，无需手动下载再替换，比如轻量的代码编辑器、笔记工具。
• 离线数据持久化：通过StorageManager.getDirectory()获取沙盒化的本地文件目录，存储离线应用的用户配置、离线缓存的媒体资源，比IndexedDB更贴近原生文件系统的操作逻辑。
• 批量本地文件处理：前端实现的图片压缩、音频格式转换、CSV数据解析工具，一次性读取用户指定目录下的批量文件，处理完成后直接写入目标目录，无需上传服务器再下载。
• 浏览器扩展增强：让扩展具备直接操作本地文件的能力，比如密码管理扩展备份密码库到本地指定文件夹，或者书签扩展导出书签到本地Markdown文件。

二、API实用价值判断 #

虽然Firefox暂不支持savePicker，但核心的文件读写、目录操作API已经在Firefox 111+稳定版落地，实用价值依然显著：

• 无需依赖后端服务，前端可直接完成本地文件的读写操作，大幅降低应用架构复杂度，提升用户操作效率。
• 基于用户主动授权的访问机制，安全性可控，不会像旧的requestFileSystem那样存在沙盒外的风险。
• 针对savePicker的缺失，可通过替代方案弥补：比如处理完文件后生成Blob URL让用户手动下载，或者在用户授权目标目录后，用FileSystemWritableFileStream直接写入指定文件。

三、关于废弃的requestFileSystem #

requestFileSystem属于旧版FileSystem API，早已被标准废弃，Firefox从未提供支持，完全无需在这个API上投入精力。当前应聚焦于现代File System Access API，这是W3C推荐的标准，也是各浏览器（包括Firefox）正在推进的方向。

四、适配isomorphic-git的扩展思路 #

要扩展lightning-fs适配isomorphic-git，核心是用Firefox支持的File System Access API实现lightning-fs兼容的文件系统接口，具体方向：

• 接口封装：实现lightning-fs的核心方法（readFile、writeFile、mkdir、readdir、stat等），内部调用File System Access API完成实际操作。
• 授权流程处理：首次调用时触发showDirectoryPicker获取用户授权的根目录句柄，可通过sessionStorage缓存句柄（会话内有效），或请求持久化授权实现跨会话复用。
• 路径映射：维护文件路径与对应FileSystemHandle的映射表，避免重复遍历目录查找文件，提升操作效率。
• 异步兼容：保持所有接口的Promise异步风格，与isomorphic-git、lightning-fs的调用逻辑完全对齐。
• 边界处理：完善错误捕获与处理，比如权限过期、文件不存在、目录创建失败等场景的提示与恢复逻辑。

内容的提问来源于stack exchange，提问作者jcubic