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