如何利用 Web Locks API 在多窗口多线程环境下实现对本地磁盘的原子化写入-js教程-PHP中文网

Web Locks API 无法实现对本地磁盘的原子化写入，因浏览器沙箱禁止 JS 直接访问文件系统；它仅能协调 IndexedDB、Cache API 等受控存储层的并发操作，且必须包裹完整异步流程并 await tx.done 或等效完成信号。

如何利用 web locks api 在多窗口多线程环境下实现对本地磁盘的原子化写入

Web Locks API 无法实现对本地磁盘的原子化写入——浏览器沙箱机制完全禁止 JavaScript 直接访问本地文件系统（如 /home/user/data.txt 或 C:\temp\log.json），更不存在“原子化磁盘写入”这一能力。

你真正能控制的，只有浏览器提供的受控存储抽象层：IndexedDB、Cache API、甚至通过 File System Access API 打开的用户显式授权的单个文件。而 Web Locks 只能在这些抽象层之上协调并发，它本身不触碰磁盘，也不提供文件系统语义。

为什么 navigator.locks.request() 对本地磁盘写入无效

浏览器不允许 JS 调用 fs.writeFileSync()、fwrite() 或任何 POSIX/Win32 系统调用
所谓“写入磁盘”，在前端语境中实际是：
- 写入 IndexedDB（最终由浏览器引擎异步刷盘）
- 写入 caches.put()（Service Worker 缓存，底层也是封装的存储后端）
- 通过 showSaveFilePicker() + WritableFileStream.write() 写入用户选中的单个文件（需用户主动授权，且每次操作独立）
Web Locks 只能包裹异步操作；而上述合法写入路径中，只有 IndexedDB 和 Cache API 是可被锁包裹的异步流程；File System Access 的 write() 是异步，但无法跨窗口共享同一文件句柄——每个标签页打开的是独立的 WritableFileStream 实例，锁名相同也互不影响

哪些场景能用 Web Locks + 实际存储组合出“类原子写入”效果

IndexedDB 的读-改-写闭环（推荐）
锁必须包住整个事务生命周期，且显式等待 tx.done：

await navigator.locks.request(`note-${id}`, { mode: 'exclusive' }, async () => {
const db = await openDB('notes', 1);
const tx = db.transaction('notes', 'readwrite');
const store = tx.objectStore('notes');
const note = await store.get(id) || { id, content: '', version: 0 };
const updated = { ...note, content: newContent, version: note.version + 1 };
await store.put(updated, id);
await tx.done; // 关键：不 await 这行，锁会在事务提交前释放
});

caches 的缓存更新（仅限 Service Worker 或主线程显式控制）
注意：多个标签页无法共用同一个 Cache 实例，但可通过锁协调「谁来触发更新」：

await navigator.locks.request('cache-refresh-lock', async () => {
const cache = await caches.open('main-v2');
await cache.put('/api/config', new Response(JSON.stringify(config)));
});

File System Access API 的单文件写入（不跨窗口）
每个窗口只能操作自己 showSaveFilePicker() 选中的文件，锁无意义；若强行复用同一锁名，只会让其他窗口排队，但写入目标仍是各自独立的文件流

常见误用与后果

尝试锁住 localStorage.setItem()：
localStorage 是同步阻塞 API，navigator.locks.request() 的回调执行顺序 ≠ 写入完成顺序，覆盖仍会发生
把锁名设为固定字符串（如 'disk-write'）：
所有业务共用一把锁，导致购物车编辑阻塞笔记保存，粒度失控
在锁内做 fetch() 或上传大文件：
锁持有时间过长，其他标签页无限排队；应只包「本地读+计算+本地写」，网络请求移出锁外
忽略 Safari 兼容性：
navigator.locks 在 Safari 17.5 及更早版本返回 undefined，不加降级逻辑等于在 iOS/macOS 上完全失效

真正容易被忽略的点是：锁解决的从来不是“怎么写磁盘”，而是“谁先写同一份逻辑数据”。如果你的数据最终落盘路径不同（比如每个窗口写自己的临时文件），锁就毫无作用；只有当多个上下文竞争修改同一份逻辑资源（如 ID 为 123 的笔记、名为 theme 的用户设置），锁才有意义——而这部分资源，必须建在 IndexedDB 或 Cache 这类浏览器可控的异步存储之上。