React 状态同步机制：分析基于代理（Proxy）的状态库在并发渲染中如何预防“僵尸回调”现象

各位同学，大家好！欢迎来到今天的“React 并发渲染：幽灵猎人指南”讲座。

我是你们的讲师，一个在 React 源码里摸爬滚打多年，看着组件从 Class 变成 Hooks，又看着 React 18 把整个世界搅得天翻地覆的老鸟。

今天我们要聊的话题有点“惊悚”。在 React 18 之前，状态管理就像是在高速公路上开车，你踩油门（setState），车就动，简单、直接。但在 React 18 之后，我们进入了“并发渲染”时代。这就像是把高速公路变成了赛车场，你一脚油门下去，车还没到终点，可能突然被叫停了，去旁边加个油，或者去修个轮胎，然后再继续跑。

在这种混乱的局面下，诞生了一种名为“僵尸回调”的恐怖生物。而我们要探讨的解决方案核心，就是——基于代理的状态库。

准备好了吗？我们要开始深扒这个机制了。

第一部分：并发渲染，也就是 React 的“精神分裂症”

首先，我们得搞清楚为什么会有“僵尸回调”。这得从 React 18 的并发特性说起。

在旧版本里，React 是单线程的。你点一下按钮，渲染开始，渲染结束，提交完成，这期间你的浏览器界面是卡死的。你 setState，然后你只能等着。这是同步的。

但在 React 18 里，引入了 Scheduler。这玩意儿就像是一个精明的调度员。当你调用 setState 时，React 并不是立刻给你渲染，而是把任务扔进队列。

然后，关键来了：中断。

假设你在渲染一个包含 1000 个列表项的组件。React 开始渲染。渲染到第 500 项的时候，系统突然说：“哎，用户要切换标签页了，或者网络请求回来了，我们暂停一下这个渲染任务，先去处理这个新任务。”

这时候，React 就把当前正在进行的渲染给“挂起”了。这叫“中断渲染”。等那个新任务处理完了，React 又会回头找那个渲染任务：“嘿，刚才说到哪了？接着渲染剩下的 500 项。”

这就是并发渲染的真相：渲染是可中断的、可暂停的、可丢弃的。

第二部分：什么是“僵尸回调”？

现在，让我们把目光投向你的状态管理库。

假设你有一个非常“勤奋”的回调函数。比如，你在 useEffect 里监听某个状态的变化，一旦变化，就发个网络请求。

// 假设的代码环境
const [count, setCount] = useState(0);

useEffect(() => {
  console.log("网络请求开始：", count);
  // ... 发起请求
}, [count]);

// 用户点击按钮
function handleClick() {
  setCount(1); // 旧版 React：立即执行 useEffect，请求发出
}

在旧版 React 中，这很安全。setCount 触发渲染，渲染触发 useEffect，请求发出。

但在并发渲染中，情况就变得诡异了。

1. 第一次渲染（中断）： setCount(1) 被调用。React 开始渲染。渲染过程中，useEffect 被执行了。此时，网络请求发出了！
2. 中断发生： 就在请求发出的一瞬间，React 发现有个更高优先级的任务（比如用户输入了文字），于是它中止了当前的渲染。刚才发出的网络请求，以及它产生的任何副作用，都被视为“垃圾数据”，直接丢弃。
3. 第二次渲染（恢复）： React 恢复渲染。useEffect 再次被执行。又发了一次网络请求！

结果是什么？你发了两次请求！一次被丢弃，一次可能成功。这就是“僵尸回调”的雏形——回调执行了，但它的上下文（渲染）已经死了。 如果你的回调里还修改了状态，那简直就是一场灾难，可能导致状态不一致。

更可怕的是，如果状态库没有处理好，这个回调可能会在后续的渲染中被再次触发，像僵尸一样挥之不去。

第三部分：传统的不可变模式是如何“中招”的

在 React 18 之前，大家最爱用的 useState 配合 useReducer，本质上是“不可变模式”。每次 setState，都要生成一个全新的对象。

这在并发渲染下有个巨大的坑：垃圾回收的压力。

想象一下，setCount 被调用了 10 次，每次都生成了新对象。React 可能渲染了 5 次，中断了 5 次。那么，那 5 次中断渲染产生的“全新对象”会被垃圾回收器回收吗？在复杂的场景下，这会导致大量的内存抖动，性能急剧下降。

而且，不可变模式在处理“副作用”时非常笨拙。因为每次状态变了，库都必须遍历整个状态树，对比新旧值，来决定要不要通知订阅者。这种“全量遍历”在并发渲染的频繁中断下，效率极低。

第四部分：代理（Proxy）—— 状态库的“读心术”

为了解决这些问题，现代状态库（如 MobX, Valtio, Immer 的某些模式）开始拥抱 JavaScript 的 Proxy 对象。

Proxy 是 ES6 引入的一个黑魔法。它允许我们拦截对象上的操作。比如，你平时是直接修改对象的属性 state.name = 'Tom'，但在 Proxy 里，我们可以拦截这个操作，在它修改之前插入我们的代码。

这就像是你给状态对象请了一个保镖。你伸手去拿水杯，保镖拦住你，问：“你要喝水吗？如果喝水，我要通知所有人，并且还要记录日志。”

代理如何工作？

const state = new Proxy({
  count: 0,
  name: 'React'
}, {
  set(target, key, value) {
    // 1. 拦截 set 操作
    console.log(`检测到属性 ${key} 正在被修改为 ${value}`);

    // 2. 执行实际的修改
    target[key] = value;

    // 3. 通知订阅者（比如 UI 更新）
    notifySubscribers(key, value);

    return true;
  }
});

看起来很简单？但这正是代理的强大之处。代理是可变的。你修改它，它就是变了。不需要生成新对象，不需要深拷贝。这就解决了并发渲染下的内存抖动问题。

第五部分：核心机制——如何用代理预防“僵尸回调”？

这是今天的重头戏。Proxy 本身只是一个工具，怎么用它来对抗僵尸回调？答案在于“订阅者管理”与“渲染上下文”的同步。

1. 订阅者列表：谁是活的，谁是死的？

基于代理的状态库，内部维护了一个“订阅者列表”。当你读取 state.count 时，你会把自己注册到这个列表里。

在并发渲染中，React 会不断地开始和结束渲染。状态库必须知道：“React 现在正在渲染吗？”

如果 React 正在渲染，状态库就应该暂停通知订阅者。为什么？因为渲染期间的状态变化是临时的、可能被丢弃的。如果这时候通知 UI 更新，UI 渲染了，结果 React 说“算了，这个渲染不要了”，那你岂不是在搞“自杀式更新”？

所以，代理库通常会维护一个 isRendering 标志位。

// 伪代码
let isRendering = false;
const subscribers = new Set();

function render() {
  isRendering = true; // 进入渲染模式
  try {
    // 执行组件渲染逻辑
    // ...
  } finally {
    isRendering = false; // 渲染结束，恢复通知
  }
}

// Proxy 的 set 拦截器
function set(target, key, value) {
  target[key] = value;

  // 只有在非渲染模式下，才通知订阅者
  if (!isRendering) {
    subscribers.forEach(sub => sub(key, value));
  }
}

这样，如果 setCount 在渲染期间被调用，代理会拦截它，但不会通知订阅者。这就防止了在“僵尸渲染”上下文下的副作用执行。只有当渲染真正完成并提交时，状态的变化才会通知 UI。

2. startTransition 的配合

React 18 提供了 startTransition。这是一个高级功能，告诉 React：“这个更新是次要的，不要阻塞用户的主要操作。”

当你在代码里写 startTransition(() => setCount(100)) 时，React 会把 setCount 标记为“过渡更新”。

基于代理的状态库可以监听这个标记。

• 场景： 用户正在输入文字（高优先级）。同时，你在后台异步加载了数据，想更新列表（低优先级）。
• 动作： 你调用 startTransition(() => updateList(data))。
• Proxy 的反应： 状态库检测到这是一个 startTransition。它可能会将这次状态更新放入一个“延迟队列”中，或者标记这次更新为“非阻塞”。
• 结果： 如果用户继续输入，React 会中断列表的渲染，去处理输入。代理库确保了列表的更新不会干扰用户的输入体验，也不会因为频繁的中断而产生大量的“僵尸回调”。

3. flushSync：强制同步的“核武器”

有时候，我们需要强制同步更新。比如在点击按钮时，必须立即更新状态并刷新 UI，哪怕这会阻塞线程。

React 提供了 flushSync。

function handleClick() {
  flushSync(() => {
    setCount(1); // 必须同步执行
  });
  // 此时 UI 已经更新
  setCount(2); // 可以异步执行
}

基于代理的库是如何处理 flushSync 的？

flushSync 的核心逻辑是暂停并发，强制单线程。

当状态库检测到当前处于 flushSync 上下文时，它会暂时关闭“订阅者队列”或“批处理逻辑”。它知道，接下来的所有操作必须立即生效。

在 Proxy 的 set 拦截器里，通常会有这样的逻辑：

function set(target, key, value) {
  target[key] = value;

  // 如果在 flushSync 模式下，直接触发所有订阅者
  if (isFlushSync) {
    subscribers.forEach(sub => sub(key, value));
    return;
  }

  // 如果在并发模式下，把更新推入批处理队列
  if (isConcurrent) {
    batchUpdate(key, value);
  }
}

通过这种方式，Proxy 确保了 flushSync 内部的状态变更能立即生效，而不会受到并发渲染中断的影响，从而避免了“僵尸回调”在同步上下文中被意外跳过。

第六部分：实战演练——手写一个抗“僵尸”的 Proxy 状态库

为了让大家更直观地理解，我们手写一个简化版的、具备并发防护能力的 Proxy 状态库。

这个库的核心思想是：在渲染期间，Proxy 修改状态但不通知；在渲染结束（提交）时，才通知。

class ZombieFreeStore {
  constructor(initialState) {
    this._state = new Proxy(initialState, {
      set: (target, key, value) => {
        // 1. 拦截设置
        target[key] = value;

        // 2. 核心逻辑：检查是否在渲染中
        if (this._isRendering) {
          console.log(`[DEBUG] 渲染中拦截修改 ${key} = ${value}，暂不通知订阅者`);
          // 这里我们也不通知，防止副作用
          // 但为了演示，我们可以记录一下“脏”状态
          this._dirty = true;
          return true;
        }

        // 3. 如果不在渲染中，通知订阅者
        console.log(`[DEBUG] 正常修改 ${key} = ${value}，通知订阅者`);
        this._notify(key, value);
        return true;
      }
    });

    this._listeners = new Map();
    this._isRendering = false;
    this._dirty = false;
  }

  get state() {
    return this._state;
  }

  // 模拟 React 的渲染周期
  triggerRender(renderCallback) {
    this._isRendering = true;
    this._dirty = false;

    try {
      // 执行组件渲染
      renderCallback(this._state);

      // 渲染结束，检查是否有脏状态
      if (this._dirty) {
        console.log("[DEBUG] 渲染结束，检测到脏状态，执行通知");
        // 这里可以遍历所有监听器进行更新
        // 在实际库中，这里会调用 React 的 scheduleUpdate
      }
    } catch (e) {
      console.error(e);
    } finally {
      this._isRendering = false;
    }
  }

  subscribe(key, callback) {
    if (!this._listeners.has(key)) {
      this._listeners.set(key, new Set());
    }
    this._listeners.get(key).add(callback);

    // 返回取消订阅函数
    return () => {
      this._listeners.get(key).delete(callback);
    };
  }

  _notify(key, value) {
    const callbacks = this._listeners.get(key);
    if (callbacks) {
      callbacks.forEach(cb => cb(value));
    }
  }
}

// --- 测试场景 ---

const store = new ZombieFreeStore({ count: 0, text: 'Hello' });

// 订阅者 1：监听 count
store.subscribe('count', (newVal) => {
  console.log(`订阅者 1 收到更新: count = ${newVal}`);
});

// 模拟 React 组件渲染函数
function MyComponent() {
  console.log("组件开始渲染...");
  console.log("当前状态:", store.state);

  // 模拟在渲染期间触发状态更新（这在 React 中是禁止的，但为了演示机制）
  // 在真实 React 中，这会抛出警告或被拦截
  // 这里我们假设这是一个异步回调里触发的更新
  setTimeout(() => {
    console.log("n--- 在渲染结束后，通过 setTimeout 修改状态 ---");
    store.state.count = 10; // 这会触发 _notify
  }, 100);

  return null;
}

// 开始渲染
console.log("=== 第一次渲染 ===");
store.triggerRender(() => MyComponent());

// 等待一下
setTimeout(() => {
  console.log("n=== 第二次渲染（模拟） ===");
  store.triggerRender(() => MyComponent());
}, 200);

运行结果分析：

1. 第一次渲染开始，_isRendering = true。
2. setTimeout 触发，修改 count。Proxy 拦截，检测到 isRendering = true，打印拦截日志，不通知订阅者。
3. 组件渲染结束，_isRendering = false。检测到 _dirty = true，触发通知。
4. 第二次渲染开始。
5. 再次修改 count。Proxy 拦截，检测到 isRendering = true，不通知订阅者。
6. 渲染结束，触发通知。

在这个简单的例子中，我们成功阻止了“僵尸回调”在渲染期间产生副作用。如果是在真实的 React 环境中，这能极大地减少无效的副作用执行。

第七部分：代理模式的局限性——当 Proxy 遇上 Diff

虽然 Proxy 很强，但它也有副作用。Proxy 是可变的。这导致 React 在进行 Virtual DOM Diff 算法时，无法像 Immutable 对象那样直接引用比较。

• Immutable (Immer): state = produce(state, draft => { draft.count++ })。这里返回的是一个全新的对象。React 拿到这个新对象，直接和旧的 Virtual DOM 对比，发现引用变了，重新渲染。简单、暴力、有效。
• Proxy (Valtio/MobX): state.count++。对象引用没变。React 的 Diff 算法可能会误以为状态没变，从而不触发重渲染。

这就是为什么很多基于 Proxy 的库（如 MobX）在 React 中需要配合 autorun 或者使用 observable.ref 等技巧。它们需要额外的机制来告诉 React：“嘿，虽然引用没变，但内容变了，快给我渲染！”

如何解决？
基于代理的库通常会在 set 拦截器中，手动触发 React 的更新机制（比如调用 scheduleUpdate）。它们实际上是在“欺骗” React 的 Diff 算法。

// MobX 的简化逻辑
function set(target, key, value) {
  target[key] = value;
  // 关键：手动通知 React
  ReactBatchedUpdates(() => {
    // 告诉 React 重新渲染
    ReactCurrentDispatcher.current.rerender();
  });
}

这就是为什么 Proxy 状态库在并发渲染下表现更好的原因——它们对 React 的调度机制有更强的控制权。

第八部分：深入探讨——为什么是“并发”？

你可能会问：“Proxy 不早就有了吗？为什么 React 18 以后才这么强调？”

因为时机。

在 React 17 及以前，渲染是同步的，没有中断。你修改了状态，渲染马上就发生。这时候，Proxy 拦截到修改，立即通知 UI，逻辑简单闭环，没有“僵尸”一说。

但在 React 18 的并发模式下，“渲染”变成了一个过程，而不是一个瞬间。

如果 Proxy 在渲染的任何阶段都通知订阅者，那么：

1. 渲染中途被中断： UI 更新了，但 React 说“别动”，UI 就悬空了。
2. 渲染被丢弃： UI 更新了，但数据被回滚了，UI 显示错误。
3. 副作用混乱： useEffect 在渲染中途触发，结果被丢弃，但副作用逻辑（比如发请求）已经执行了。

所以，基于代理的状态库必须进化。它们必须学会“看脸色行事”。它们必须知道 React 是在“渲染中”、“渲染暂停了”、“渲染丢弃了”还是“渲染提交了”。

第九部分：僵尸的终结者——总结与展望

回到我们的主题：基于代理的状态库如何预防“僵尸回调”？

通过“渲染上下文感知”和“订阅者生命周期管理”。

1. 渲染上下文感知： 代理拦截器会检查 React 的渲染状态。如果在渲染中，Proxy 会延迟通知，或者直接屏蔽通知，直到渲染真正完成并提交。这就像是在装修房子（渲染）的时候，不对外营业（通知）。
2. 订阅者清理： 并发渲染伴随着频繁的组件卸载和挂载。代理库必须高效地管理订阅者列表。当组件卸载时，必须立即从 Proxy 的监听器中移除，防止内存泄漏和僵尸回调。
3. 与 Scheduler 协作： 代理库不仅仅是监听 set，还要监听 React 的 Scheduler 信号。利用 requestIdleCallback 或 MessageChannel，在渲染间隙进行非阻塞的更新，进一步提升性能。

结语：拥抱并发，告别幽灵

各位同学，React 并发渲染不是洪水猛兽，它是 React 为了解决“卡顿”和“过时”问题而进化出的终极形态。

在这个形态下，基于代理的状态库就像是一位训练有素的特工。它们利用 Proxy 的强大拦截能力，结合对 React 渲染周期的深刻理解，成功地隔绝了“僵尸回调”的干扰。

作为开发者，我们不需要去深挖 React 的每一行源码，但我们需要理解这些机制背后的逻辑：状态更新不再是简单的赋值，而是一场与渲染引擎的对话。 只有理解了这场对话的规则，我们才能写出既流畅又健壮的代码。

下次当你点击按钮，看着屏幕丝滑地更新时，别忘了，在屏幕的背后，Proxy 正在默默地守护着你的状态，不让任何一个“僵尸”回调破坏这场盛宴。

好了，今天的讲座就到这里。下课！