Logseq多窗口模式下本地存储状态管理问题分析

问题背景

Logseq作为一款知识管理工具，在处理多窗口场景时存在一个关键的设计缺陷。系统当前通过浏览器的localStorage存储当前打开的仓库路径，使用:git/current-repo作为键名。这种设计在多窗口环境下会导致状态冲突，因为localStorage是浏览器级别的共享存储空间。

技术原理分析

当用户同时打开两个不同知识库的窗口时，两个窗口会竞争写入同一个localStorage键值。后写入的窗口会覆盖前一个窗口的状态，导致前一个窗口出现各种异常行为。这种竞态条件会引发一系列难以追踪的bug，包括但不限于：

1. 错误的文件操作路径
2. 混淆的知识库引用
3. 不一致的界面状态显示

现有实现剖析

当前实现的核心代码如下：

(defonce ^:large-vars/data-var state
  (let [document-mode? (or (storage/get :document/mode?) false)
        current-graph  (let [graph (storage/get :git/current-repo)]
                        (when graph (ipc/ipc "setCurrentGraph" graph))
                        graph)]))

这段代码在初始化应用状态时直接从localStorage读取当前仓库路径，并通过IPC通知主进程。这种设计没有考虑多窗口场景下的隔离需求。

改进方案建议

更合理的实现应该基于以下原则：

1. 窗口状态隔离：每个窗口应维护自己独立的状态
2. 主进程协调：利用Electron主进程作为状态管理中心
3. 实时同步机制：窗口状态变化时及时通知主进程

具体技术方案可以改为：

• 移除localStorage中的:git/current-repo依赖
• 窗口初始化时通过IPC向主进程查询当前窗口对应的知识库路径
• 主进程维护窗口ID到知识库路径的映射表
• 窗口切换知识库时通过IPC更新主进程的状态

潜在影响评估

这种架构调整可能影响：

1. 启动流程需要等待主进程响应
2. 需要重构部分依赖localStorage的代码
3. 需要增强主进程的状态管理能力

但长期来看，这种改进将显著提升Logseq在多窗口场景下的稳定性和用户体验。

总结

Logseq当前的多窗口状态管理设计存在根本性缺陷，通过重构存储架构，采用主进程协调机制，可以彻底解决多窗口状态冲突问题。这种改进不仅修复当前bug，也为未来更复杂的多窗口协作功能奠定基础。