诡异的Bug：Zustand全局状态与React-KeepAlive的离奇互动

Posted on In

作为一名长期与 React 生态系统打交道的开发者，我最近遭遇了一个极其诡异的 bug——那种会让你怀疑自己理解能力、甚至怀疑整个世界物理定律的 bug。今天我想详细记录这个奇特的现象，希望能帮助遇到类似问题的开发者，同时也为未来的自己留下一个案例参考。

技术栈背景

首先介绍一下我的技术栈组合：

  • 前端框架：React + TypeScript
  • 构建工具：Vite
  • CSS 框架：TailwindCSS
  • 状态管理：Zustand
  • UI 组件库：Ant Design Mobile
  • 页面缓存：react-activation (KeepAlive)

这套组合在现代 React 开发中相当常见，各司其职都很出色，但就是在这个特定场景下产生了奇妙的”化学反应”。

问题现象再现

我的应用是一个移动端 web 应用，有一个主页(HomePage)和一个存款页面(DepositPage)。两个页面上都有一个”选择币种”的面板(SelectCoinPanel)，这个面板以弹出层(Popup)的形式存在。

关键点在于：

  1. 两个 SelectCoinPanel 的 visible 状态都是由同一个 Zustand 全局状态控制的
  2. HomePage 使用了react-activation/KeepAlive进行缓存
  3. 当从 HomePage 导航到 DepositPage 时，两个页面实际上是同时存在于 DOM 中的(因为 KeepAlive)

出现的 bug 症状极其诡异：

  • 触发打开时，两个面板都会打开（这不是预期的）
  • 关闭时：第一个面板关闭了但不完全(遮罩层仍然存在)，第二个面板只关闭了一部分
  • 导致页面卡死，无法交互（因为遮罩层阻挡）

最最诡异的部分来了：当我打开开发者工具，手动选中这些弹出层的 DOM 节点时——bug 消失了！就像量子态的坍缩一样，观测行为改变了程序的行为。不观测时 bug 有几率出现，一旦观测，绝对不会出现。

问题分析与思考

这个 bug 给我上了一堂深刻的”React 状态管理”+”DOM 观测效应”课。让我尝试分析几种可能性：

可能原因 1: KeepAlive 与 zustand 的冲突

react-activation的 KeepAlive 会保留组件实例和状态，而 zustand 的全局状态被两个实例共享。这可能导致：

  • 状态更新被两个实例分别处理
  • React 的渲染批次处理可能被打乱
  • 生命周期钩子的执行顺序可能异常

可能原因 2: React Strict Mode 的双重渲染

在开发环境下，React 的 StrictMode 会故意双重渲染组件以检测问题。可能与 KeepAlive 交互产生副作用。

可能原因 3: 观测效应(Observer Effect)

为什么使用开发者工具观测 DOM 会影响行为？可能原因：

  • Chrome 的开发者工具会强制同步布局(reflow)
  • 观测行为可能触发了某些事件处理器的重新绑定
  • V8 引擎可能对观测到的 DOM 节点采取不同的优化策略

解决方案与变通方法

我最终的解决方案是不再依赖 zustand 全局状态控制弹出层，而是改为每个组件自行管理自己的状态。这样虽然解决了问题，但我对根本原因依然充满好奇。

其他可能的解决方案：

  1. 为每个弹出层使用不同的 zustand 状态: 避免状态共享，从根本上消除冲突
  2. 使用 Context 替代全局状态: 提供更精细的状态管理边界
  3. 使用 key 属性强制重新挂载: <KeepAlive key={location.pathname}>

未解之谜与经验教训

  1. **开发者工具的观测能解决 bug？**这让我想起了量子物理中的”观测者效应”。在编程世界，观测行为(如 console.log、DOM 检查)有时确实会改变程序行为，这通常是由于时序或同步问题的改变。
  2. 状态管理的边界问题：全局状态看似方便，但容易引入隐蔽的耦合问题。组件最好管理自己的本地状态，除非确需共享。
  3. 缓存组件的陷阱：KeepAlive 这类缓存虽然提升用户体验，但会带来内存泄漏、状态残留等副作用，使用时需格外小心。

给遇到类似问题开发者的建议

如果你也遇到这种”观测才消失”的诡异 bug：

  1. 最小化复现：尝试创建一个最小化的复现环境，剥离无关逻辑
  2. 隔离测试：分别测试关闭 KeepAlive 和替换 zustand 的情况
  3. 版本检查：确认各库版本兼容性，有时更新版本能解决问题
  4. 记录时间线：详细记录 bug 出现的条件和变化情况