React 原子状态管理：Recoil 与 Jotai 的“内存豪宅”与“极简胶囊”对决
各位听众，大家好。
今天我们不聊那些虚头巴脑的架构模式，也不谈什么“高内聚低耦合”的陈词滥调。今天，我们要来一场硬核的“内存大逃杀”。
在 React 生态里，状态管理就像是一场没有硝烟的战争。我们有了 Redux，有了 Context，但最近，一种名为“原子状态管理”的流派异军突起。它们像是一群崇尚极简主义的嬉皮士，试图打破 Redux 那种“万物皆 Store”的沉重枷锁。
今天我们的两位主角是：Recoil 和 Jotai。
这两位虽然都姓“原子”，但性格迥异。Recoil 就像是一座豪华的原子酒店，拥有复杂的客房管理系统、庞大的前台登记册，以及时刻准备吞噬你内存的“依赖图”。而 Jotai 则像是一个乐高积木盒，你想要什么就拿出什么，用完就扔，绝不留恋。
我们将深入探讨一个极其敏感的话题：当你的应用拥有海量依赖图时，这两个家伙在内存分布上到底在搞什么鬼？
让我们把麦克风递给技术，开始这场讲座。
第一部分：Recoil —— 那个囤积癖的酒店经理
首先，让我们欢迎 Recoil。Recoil 是由 Facebook 开发的，这注定了它的基因里带着一种“工业级”的严谨，但也带着一种“过度设计”的嫌疑。
1.1 核心概念：节点与边
Recoil 的核心是一个有向图。是的，图。不是树，是图。这意味着节点之间可以互相引用，形成复杂的网状结构。
想象一下，你有一个原子 atom('name', 'Alice')，它依赖另一个原子 atom('age', 30)，而 age 又依赖 atom('country', 'USA')。在 Recoil 的世界里，这就是一条边。当你读取 name 时，Recoil 的底层引擎会沿着这条边一路追溯，确保所有依赖的数据都是最新的。
1.2 内存大户：RecoilNode
为什么说 Recoil 是个内存大户？因为每个“节点”都是一个对象。
// Recoil 内部大概长这样（伪代码）
class RecoilNode {
key: string; // 唯一ID，比如 "selector_name$1"
loadable: Loadable; // 缓存值，可能是 Loading，可能是 Value，也可能是 Error
deps: Set<RecoilNode>; // 依赖的节点集合（这就是那个“依赖图”）
subscribers: Set<RecoilValue>; // 订阅者
// ... 还有各种生命周期钩子
}看看这个 deps: Set<RecoilNode>。这是一个巨大的内存消耗点。假设你有 1000 个原子，它们两两之间互相引用，或者通过复杂的 Selector 互相依赖，这个图的结构会迅速膨胀。
Recoil 的内存分布策略是：惰性加载 + 缓存。
当你第一次访问某个原子时，Recoil 才会在内存中创建这个 RecoilNode。如果你访问了 A，然后访问了 B，A 和 B 都会存在。如果你不再访问 A，它会被 GC（垃圾回收）回收吗？Recoil 有一个缓存机制，为了防止页面切换回来时重新计算，它会保留一部分缓存。
1.3 代码示例：构建一个“重”依赖图
让我们写一段代码，模拟一个拥有海量依赖的场景。
import { atom, selector, useRecoilValue } from 'recoil';
// 1. 创建基础原子
const userAtom = atom({
key: 'userAtom',
default: { name: 'Alice', age: 30 }
});
// 2. 创建一个 Selector，它依赖 userAtom
// 这在 Recoil 的依赖图中，就是在 userAtom 和这个 Selector 之间画了一条线
const userNameSelector = selector({
key: 'userNameSelector',
get: ({ get }) => {
const user = get(userAtom);
return `${user.name}'s Name`;
}
});
// 3. 再创建一个复杂的 Selector，依赖上面的 Selector
// 这又增加了一条边
const userGreetingSelector = selector({
key: 'userGreetingSelector',
get: ({ get }) => {
const name = get(userNameSelector);
return `Hello, ${name}!`;
}
});
// 4. 组件消费
function UserProfile() {
const greeting = useRecoilValue(userGreetingSelector);
return <div>{greeting}</div>;
}在这个简单的例子中，Recoil 内存里躺着三个 RecoilNode。但如果我们将这个逻辑扩展到 10,000 个层级，或者使用 atomFamily 来创建 10,000 个独立的用户状态，内存中的图就会变得庞大且臃肿。
Recoil 的依赖图是静态的（大部分情况下），一旦建立，节点就会一直躺在内存里，除非被显式清除。
第二部分：Jotai —— 那个不修边幅的极简主义者
现在，让我们把舞台交给 Jotai。Jotai 是由 Daishi Kato 开发的，它的哲学非常简单：“原子即一切”。
Jotai 不搞什么图，不搞什么树，不搞什么层级。它就是一个一个的 atom。你定义一个，它就存在。你不用它，它就只是内存里的一个对象。
2.1 核心概念：订阅即图
Jotai 没有显式的“依赖图”数据结构。它的依赖图是隐式的，存在于 React 的组件树中。
当你写 const [count, setCount] = useAtom(atom(0)) 时，Jotai 做了一件事：它把这个组件挂载到了这个 atom 的订阅列表里。
如果 atom 的值变了，Jotai 会遍历这个订阅列表，通知对应的组件重新渲染。这就是 Jotai 的“图”——它不是存储在全局变量里的，而是散落在各个组件的 useEffect 闭包里。
2.2 内存杀手？不，内存天才
Jotai 的内存分布非常干净。
// Jotai 的原子本质上就是一个可变的状态对象
// 没有复杂的元数据包装
let atom = {
read: () => { /* ... */ },
write: () => { /* ... */ }
};
// 没有额外的 deps 集合，没有额外的 key 集合
// 只有值本身，或者是一个 Promise当组件卸载时，useEffect 的清理函数会自动从订阅列表中移除该组件。不需要 Recoil 那种复杂的全局图遍历来清理资源。
2.3 代码示例：Jotai 的极简主义
import { atom, useAtom } from 'jotai';
// 1. 定义原子
const userAtom = atom({ name: 'Alice', age: 30 });
// 2. 定义派生原子（可选，但 Jotai 也支持）
// 在 Jotai 中，你也可以写一个函数来生成 atom，但这更多是语法糖
// 真正的依赖关系是在组件内部通过 useAtomValue 建立的
// 3. 组件消费
function UserProfile() {
// useAtom 返回 [state, setState]
// 这里的 state 就是原始值，或者是 Promise
const user = useAtom(userAtom)[0];
return <div>Hello, {user.name}!</div>;
}看到区别了吗？在 Jotai 里，没有 get(userAtom) 这种显式的依赖查询。依赖关系是 React 的 useEffect 自动管理的。这意味着，如果 UserProfile 组件被卸载了，关于 userAtom 的所有引用和订阅瞬间消失，就像从未存在过一样。
第三部分：实战演练 —— 模拟“海量依赖”场景
现在，让我们进入最刺激的环节。假设我们有一个超级复杂的电商后台系统。
我们需要展示 10,000 个商品。每个商品都有价格、库存、折扣、促销状态、物流信息、评论数量。这些信息之间还有复杂的关联。比如，价格变了，库存需要检查；库存不足，促销状态需要变灰。
场景 A：Recoil 的表现
如果我们要用 Recoil 来实现这个：
// Recoil 的 atomFamily 会为每个商品生成一个节点
const productAtomFamily = atomFamily({
key: 'product',
default: (id) => fetchProduct(id) // 惰性加载
});
// 我们还需要一个 selector 来计算总价格
const totalPriceSelector = selector({
key: 'totalPrice',
get: ({ get }) => {
// 假设我们要遍历所有商品
const products = get(productAtomFamily.getAll()); // 假设有个 getAll
return products.reduce((acc, p) => acc + p.price, 0);
}
});内存分析：
- 节点开销： Recoil 会为这 10,000 个商品创建 10,000 个
RecoilNode。每个节点都有key、loadable、subscribers等属性。 - 依赖图开销： 如果
totalPriceSelector依赖所有商品，那么在 Recoil 的全局图里，totalPriceSelector会有一万个邻居。这个图的边数是 $N times N$ 的量级（虽然它是稀疏的，但 Recoil 存储的是 Set，空间复杂度依然很高）。 - 缓存开销： Recoil 的
loadable缓存机制可能会保留这 10,000 个商品的最新状态。如果你在页面间切换，这些状态可能不会被立即释放，导致内存占用居高不下。
Recoil 的痛点： 当依赖图变得极其庞大时，Recoil 的更新机制（基于图的遍历）会开始变得迟钝。虽然 React 本身会处理批量更新，但 Recoil 内部维护的那个巨大的图结构，每次变动都需要更新图结构，这本身就是一种开销。
场景 B：Jotai 的表现
如果我们要用 Jotai 来实现这个：
// Jotai 的 atomFamily 同样生成 10,000 个 atom
const productAtomFamily = atomFamily({
key: 'product',
default: (id) => fetchProduct(id)
});
// 计算总价
// 在 Jotai 中，我们通常不会写一个 selector 来做这种聚合计算
// 因为这样会产生一个巨大的订阅者图。
// 我们通常会在组件内部做计算// 组件内部
function ProductList() {
const products = useAtomValue(productAtomFamily); // 这里 Jotai v2 支持批量读取
const totalPrice = useMemo(() => {
return products.reduce((acc, p) => acc + p.price, 0);
}, );
return <div>Total: {totalPrice}</div>;
}内存分析：
- 节点开销： Jotai 也创建了 10,000 个
atom对象。但 Jotai 的atom对象非常轻量，它没有deps集合，没有复杂的loadable包装器（它直接存储值或 Promise）。 - 依赖图开销： Jotai 的依赖图是组件级的。
ProductList组件订阅了这 10,000 个atom。当更新发生时，Jotai 只需要通知ProductList重新渲染。它不需要维护一个全局的“谁依赖谁”的图。 - 内存释放： 当
ProductList卸载时，useAtomValue的清理函数会断开所有 10,000 个订阅。这 10,000 个atom对象本身仍然在内存中（因为它们是全局单例），但它们与组件的连接断了。如果这些atom没有被其他组件使用，GC 最终会回收它们。
Jotai 的优势： Jotai 的内存模型是线性的。它不关心图的结构，它只关心值的变化。这种“去中心化”的策略使得它在处理海量状态时，内存压力远小于 Recoil。
第四部分：深入剖析 —— 为什么 Recoil 的图这么“重”？
让我们打开 Recoil 的源码（或者文档），看看它到底在图里存了什么。
Recoil 的核心是 RecoilNode。为了实现高效的依赖追踪和更新，它必须知道：
- 这个节点被谁依赖了？ (
dependencies) —— 为了更新时能找到所有受影响的组件。 - 谁订阅了这个节点？ (
subscribers) —— 为了更新时能直接触发渲染。 - 这个节点的当前状态是什么？ (
loadable) —— 为了避免重复计算。 - 这个节点是否正在加载？ (
state) —— 为了处理异步状态。
这就是一个典型的“控制反转”（IoC）陷阱。Recoil 把所有的控制权都拿到了全局，构建了一个巨大的状态机。这个状态机需要维护所有的状态、所有的依赖关系、所有的订阅者。这就是为什么 Recoil 的内存占用会随着依赖图的复杂度呈指数级增长。
第五部分：Jotai 的“订阅图” —— 真的更轻吗？
Jotai 也有“图”，它的图存在于 React 的 Effect 集合中。
当你调用 useAtom(atom) 时，Jotai 会创建一个 subscribe 函数，并将其放入 atom.subscribers 中。当 atom 变化时，遍历 atom.subscribers，执行 subscribe。
这个图是动态的。它随着组件的挂载和卸载而生长和枯萎。它不需要像 Recoil 那样存储“节点与节点之间的关系”，它只存储“组件与节点之间的关系”。
// Jotai 内部订阅逻辑（简化版）
class JotaiAtom {
// ...
subscribers = new Set(); // 只存组件引用
notify() {
this.subscribers.forEach(fn => fn(this.value));
}
}对比一下 Recoil：
// Recoil 内部依赖逻辑（简化版）
class RecoilNode {
// ...
dependencies = new Set(); // 存节点引用
subscribers = new Set(); // 存组件引用
// 更新时需要遍历 dependencies，找到所有依赖此节点的 selector，再找它们的 subscribers
// 这就是图遍历
update() {
this.dependencies.forEach(depNode => {
// 递归更新...
});
}
}Recoil 的图是双向且静态的（大部分）。这意味着如果你想查找“哪些 Selector 依赖了 atom A”，Recoil 可以瞬间告诉你，因为图已经构建好了。但 Jotai 需要遍历 React 的组件树（虽然很高效，但不是 O(1)）。
但是，对于内存而言，Jotai 胜出。因为 Recoil 的图结构是全局的、持久化的，而 Jotai 的图结构是局部的、暂时的。
第六部分：异步状态与内存 —— 隐藏的杀手
在处理海量数据时，异步状态是内存泄漏的重灾区。
Recoil 的 loadable 缓存：
Recoil 非常喜欢缓存异步数据。当你请求一个商品详情，Recoil 会把这个 Promise 和它的结果都存在 RecoilNode 里。
// Recoil Node
{
key: 'product_123',
loadable: {
state: 'hasValue',
contents: { ... } // 大对象
}
}如果你有 10,000 个商品，每个商品都在加载中或加载完成，Recoil 会把这些对象全部保留在内存里。即使你切换了页面，这些节点还在那里“守望”。
Jotai 的直接存储：
Jotai 默认情况下，如果原子值是 Promise，它会直接存储这个 Promise 对象。
// Jotai Atom
{
key: 'product_123',
value: Promise { <pending> } // 或者是 resolved 的值
}但是，Jotai 的哲学是“简单”。如果你不使用 atomWithStorage 或复杂的中间件，Jotai 不会主动去缓存这些数据。当你切换页面，组件卸载，订阅断开，Jotai 不会强行保留这些 Promise。当然，React 的默认行为也会回收这些闭包，除非你显式地用 useRef 持有它们。
结论： 在海量异步数据的场景下，Recoil 的内存管理更像是一个“囤积癖”，它怕你再次请求时数据没了；而 Jotai 则更像一个“健忘症患者”，它默认数据只活在当下。
第七部分：代码实战 —— 比较两者的内存占用模拟
为了让大家更直观地理解，我们写一个模拟代码。
// ==========================================
// Recoil 版本
// ==========================================
import { atom, selector, RecoilRoot } from 'recoil';
import { useRecoilValue } from 'recoil';
// 模拟 1000 个原子
const heavyDataFamily = atomFamily({
key: 'heavyData',
default: (id) => ({
id,
data: new Array(1000).fill(0).map((_, i) => Math.random()), // 每个节点存 1000 个数字
}),
});
// 一个聚合 Selector，依赖所有 1000 个原子
const heavySumSelector = selector({
key: 'heavySum',
get: ({ get }) => {
// 这里会触发全局依赖图的更新
const allData = [];
for(let i=0; i<1000; i++) {
allData.push(get(heavyDataFamily(i)));
}
return allData.reduce((acc, cur) => acc + cur.data.length, 0);
},
});
// ==========================================
// Jotai 版本
// ==========================================
import { atom, useAtomValue, atomFamily } from 'jotai';
// 模拟 1000 个原子
const jotaiHeavyDataFamily = atomFamily({
key: 'jotaiHeavyData',
default: (id) => ({
id,
data: new Array(1000).fill(0).map((_, i) => Math.random()),
}),
});
// 在 Jotai 中，我们不写聚合 Selector，而是让组件自己算
// 组件只订阅它需要的原子性能对比：
-
初始化时间：
- Recoil：需要遍历图，建立 1000 个节点，建立它们之间的依赖关系（如果是 Selector 依赖的话）。时间复杂度较高。
- Jotai：直接创建 1000 个对象。时间复杂度低。
-
更新时的内存抖动：
- Recoil：更新一个原子，Recoil 引擎需要遍历依赖图，找到所有受影响的 Selector，更新它们的
loadable，然后触发渲染。这是一个图遍历操作。 - Jotai：更新一个原子，Jotai 只需要遍历 React 的订阅列表（即组件树），通知渲染。这是一个树遍历操作。
- Recoil：更新一个原子，Recoil 引擎需要遍历依赖图，找到所有受影响的 Selector，更新它们的
-
GC 压力：
- Recoil：由于有大量的节点和缓存，GC 频率较高，且每次 GC 需要处理的对象体积较大（
RecoilNode对象本身 + 缓存的数据）。 - Jotai：对象体积小（纯数据对象），生命周期短（组件卸载即释放），GC 压力小，内存碎片少。
- Recoil：由于有大量的节点和缓存，GC 频率较高，且每次 GC 需要处理的对象体积较大（
第八部分：极端情况 —— 循环依赖与内存
Recoil 对循环依赖有很好的处理机制，但这通常是以内存为代价的。Recoil 会检测循环，并可能生成额外的节点或缓存状态来处理这种异常。
Jotai 则非常“暴力”。如果你在组件里写了一个死循环的更新逻辑（比如在 useEffect 里不断 setCount），Jotai 会忠实地执行。但好在，Jotai 的内存模型比较直接，不会因为循环而产生奇怪的内存堆积。
第九部分：总结 —— 选择你的武器
各位，现在我们回到最初的问题：海量依赖图下的内存分布。
-
Recoil 就像一个瑞士军刀。它功能强大，能处理复杂的依赖关系，能自动缓存，能处理异步状态。但是，它的内存开销是固定的、全局的、且随着图的大小线性增长（甚至由于图的稀疏性导致增长更快）。如果你在做一个超大规模的 SaaS 系统，且状态结构非常复杂，Recoil 的内存管理可能会成为瓶颈，特别是在移动端或低内存设备上。
-
Jotai 就像一个瑞士卷。你吃一口是一口，用完就扔。它的内存开销是动态的、局部的。它不维护全局图，只维护组件订阅。在处理海量数据、或者需要频繁创建销毁状态的场景下，Jotai 的内存表现要优雅得多。
给专家的建议：
如果你的应用是一个“静态配置型”应用，大部分状态是配置，且结构相对固定，Recoil 依然是一个强有力的竞争者，它的图结构带来的可预测性是很好的。
如果你的应用是一个“动态交互型”应用，状态随着用户的操作不断增减，组件频繁挂载卸载，或者你需要在一个页面里管理成千上万个独立的状态，那么 Jotai 绝对是内存分布上的赢家。
最后，记住这句话：最好的状态管理工具，是你不需要去管理它的工具。 Recoil 想管理你的图，而 Jotai 让你的组件自己去管理依赖。在这个内存为王的时代，Jotai 这种“无为而治”的策略，显然更符合我们的胃口。
谢谢大家，我是你们的编程专家。现在，让我们去写点更轻量级的代码吧！