我不小心写了一个文件系统驱动。用于浏览器。🤔

Source: Dev.to

问题概述

数据消失了。没有错误，没有警告，也没有堆栈跟踪——就这么不见了。

你的应用使用 File System Access API 写文件，这是近年来最令人兴奋的浏览器特性之一。用户选择一个文件夹，你就可以本地、干净地写入，而不需要服务器。听起来很理想，对吧？

但在移动端，这个理想往往会悄然破灭。

• 浏览器进程在后台被杀死（在 Android 上内存紧张时很常见）。
• 可写流正处于写入过程中时被终止。
• 不会抛出错误；写入 simply 不会完成。

失效模式

1. 进程被杀 – 操作系统终止你的进程，正在进行的写入随之消失。
2. 句柄失效 – 重新打开应用后，你之前获取的文件句柄已经失效。
3. 并发写入 – 同时发起多个写入会导致 File System Access API 竞争；大多数写入会静默失败，因为 API 并不会对操作进行序列化。

这三种失效都是无声的，导致数据丢失。

解决方案

我针对移动浏览器的每种失效模式实现了一个小型的持久层：

• 预写缓冲区 – 在数据到达文件系统之前先排队。
• 按文件名排队 – 确保对同一文件的写入是串行的。
• IndexedDB 备用存储 – 当文件系统不可用时安全地存放待写入的数据。
• 恢复机制 – 在下次应用唤醒时重新执行已存放的写入。

这些组件共同构成了一个 预写日志（WAL） 系统，类似 PostgreSQL 用来在崩溃后恢复的机制，只是实现于浏览器标签页内部。

反思：浏览器即操作系统

这些关注点——写入顺序、进程生命周期、I/O 持久性、崩溃恢复——传统上是在操作系统层面解决的，而不是在 Web 应用中。令人不安的事实是 浏览器本身已经充当了操作系统：

• 它拥有进程管理器（标签页生命周期、后台杀死策略）。
• 它提供自己的文件系统、持久存储、计算管线以及进程隔离。

大多数框架仍把浏览器视作服务器之上的“哑巴 UI 层”，但平台已经悄然进化。像 Electron、Tauri 和 Capacitor 这样的包装器，仅仅是把浏览器已有的类 OS 能力暴露出来，而不是新增功能。

对开发者的意义

我们正处于一个转折点。浏览器运行时已经足够强大，能够充当一流的操作系统，但仍有许多开发者把它当作仅仅是视图层来构建。能够认识到这一点的开发者可以直接在浏览器之上构建系统服务——文件系统驱动、进程管理器、持久层。

Gnoke Suite 旨在提供这样一个系统层，它运行 在 浏览器之上，而不是 于 浏览器之中。这一细微的转变可以改变我们构建基于 Web 的应用的方式。

查看代码

如果你想看到浏览器文件系统驱动的实际实现，请查看：

• gnoke‑savenative on GitHub

征求反馈

如果你也遇到过类似的问题——写入静默失败、句柄失效、移动端进程被杀——请在评论中分享你的经历。我猜很多人都遇到过这些问题，但很少有人写出来。