由 Daishi Kato 创建的 React 原子化状态管理库 Jotai 发布了 Jotai v2.20.0。这是一次以性能为重点的更新，重新设计了该库内部的存储构建模块，并为未来的 Jotai v3 做好了准备。
Jotai v2.20.0 围绕一个核心主题展开：提升高吞吐场景下的性能。本次发布归功于核心贡献者 David Maskasky，并带来了一小组内部改动，包括避免使用 getInternalBuildingBlock 函数（#3293）、为 onMount hooks 引入 Rev3 类型收窄（#3311），以及在 ensureAtomState 中为新的 atom state 引入延迟 hooks（#3313）。
这项改动有着较长的发展历史。正如 Kato 在他的 Read the Code newsletter 中解释的那样，构建模块（building blocks）的理念最早于一年多前的 v2.12.0 版本中引入，通过暴露部分内部机制，让 jotai-effect 和 jotai-scope 等生态库能够扩展 Jotai 核心能力。
Kato 并没有选择在 store 创建完成后再允许扩展，因为他担心这种方式可能会导致能力随着时间推移出现不匹配的问题。相反，他选择在构建 store 的时候接受定制化配置。他表示，大约到了 v2.15.0 版本，这套 API 既具备灵活性，同时也足够安全，或者说“不容易被误用”。
这种灵活性也带来了代价。有人反馈出现了性能下降，而主要原因是为了让构建模块更加灵活而引入的 WeakMap（#3280）。修复方案是放弃 WeakMap 方案，改为通过参数传递所有内容。Kato 将这个解决方案描述为“不是特别优雅，但符合我的思维模型”，并表示这次发布是他开始认真思考 Jotai v3 之前的最后一步。
对于大多数开发者来说，日常使用的 API 没有任何变化。创建和使用 store 的方式与之前完全一致。
“破坏性变更”这一标签针对的是供库作者使用的内部构建模块，而不是普通应用代码。影响会体现在下游生态中，例如 jotai-devtools v0.14.0 增加了对 INTERNAL_buildStoreRev3 的支持，并移除了旧版本支持，以保持兼容性。
仍然使用 Jotai v1 的团队应该参考官方 v2 迁移指南，而依赖 atomFamily 的用户需要注意，该功能已经被弃用，Jotai v3 将推荐使用 jotai-family 包替代。
目前已经发布了两个后续补丁版本，分别是 v2.20.1 和 v2.20.2，用于解决更多边缘情况。
社区对于这个小版本更新的直接反响较为平淡，这也符合其“底层改动”的性质。不过，围绕 v3 长期规划展开的讨论仍然持续吸引贡献者参与。
在相关讨论中，Kato 提出了 Jotai v3 的规划，其中明确包括重新设计构建模块数组结构——也就是本次版本涉及的核心内部机制，同时还计划移除 CommonJS 构建、停止支持 React 18 以下版本，以及移除 setSelf 选项。
这些提议引发了一些讨论，其中一位贡献者重点关注了移除 CJS 的计划：
关于移除 CJS——我认为这甚至不应该成为一个问题。99.9999% 的 Jotai 用户都在使用某种构建工具，而所有这些工具都很好地支持 ESM。剩下的 0.0001% 可能是使用纯 ESM 模块的用户，在这种情况下……嗯……他们本来就在使用 ESM 模块 :D
Kato 的回复强调，仍然需要考虑服务端渲染用户的需求。对于降低 Jotai 与 React 的耦合、吸引其他框架用户的建议，他则明确表示了坚持 React 优先的立场。
从更广泛的生态环境来看，Jotai 仍然是领先的原子化状态管理方案之一，不过在原始下载量方面，它排在 Kato 自己创建的 Zustand 之后。
该项目自己的对比说明中，将 Jotai 描述为自底向上的 atoms 模型，类似 Recoil；而 Zustand 提供的是单一自顶向下的 store，更接近 Redux；Kato 基于代理机制的 Valtio 则针对的是另一种思维模型。
Jotai 采用 MIT 许可证开源，可以通过 npm 安装。
原文链接：
https://www.infoq.com/news/2026/07/jotai-rework-performance/
