Jotai v2.20: Rework Store Building Blocks for High-Throughput Performance and Sets the Stage for v3
TL;DR · AI 摘要
Jotai v2.20.0通过重构内部存储构建块提升性能，并为v3版本铺路。核心改进包括避免WeakMap、优化钩子逻辑，对开发者日常API无影响。
核心要点
- v2.20.0用参数传递替代WeakMap解决性能回归问题
- atomFamily在v3中被jotai-family替代
- 内部重构不影响常规开发者API但影响库作者
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- Jotai v2.20.0更新
- 性能优化
- 移除WeakMap
- 钩子逻辑优化
- v3准备
- 架构升级
- 影响范围
- 库作者受影响
- 开发者API不变
金句 / Highlights
值得收藏与分享的关键句。
使用WeakMap导致性能回归，改用参数传递解决
atomFamily在v3中被jotai-family替代
内部重构不影响常规开发者API但影响库作者
Jotai v2.20：重构存储构建模块以实现高吞吐性能并为v3版本铺平道路 - InfoQ
InfoQ 首页 News Jotai v2.20：重构存储构建模块以实现高吞吐性能并为v3版本铺平道路
Web 开发
InfoQ AI 工程师认证（7月25日）：AI演示已成功运行。现在你需要确保其可靠性。
Jotai v2.20：重构存储构建模块以实现高吞吐性能并为v3版本铺平道路
2026年7月24日 3分钟阅读
作者：
- Daniel Curtis
#### 关注我们
YouTube
232K 粉丝
26K 粉丝
新
RSS
19K 读者
X
57.1k 粉丝
21K 点赞
Bluesky
收听本文音频 -
0:00
音频准备就绪
您的浏览器不支持音频元素。
正常
1.25x
1.5x
点赞
新下拉阅读列表
- 阅读列表
由 Daishi Kato 创建的 React 原子状态管理库 Jotai 已发布 Jotai v2.20.0，这是一个聚焦性能的更新，重构了库的内部存储构建模块，并为未来的 Jotai v3 版本铺平道路。
Jotai v2.20.0 围绕一个核心主题展开：在高吞吐场景中提升性能。此次发布归功于核心贡献者 David Maskasky，包含一系列内部改进，包括移除 getInternalBuildingBlock 函数（#3293）、为 onMount 钩子函数实现 Rev3 类型收窄（#3311），以及在 ensureAtomState 中为新原子状态引入懒加载钩子（#3313）。
这项变更有着深远的历史。正如 Kato 在其《Read the Code》通讯中解释的那样，构建模块的概念早在一年多前的 v2.12.0 版本中首次引入，通过暴露部分内部实现，使生态系统库如 jotai-effect 和 jotai-scope 能够扩展 Jotai 的核心功能。为了避免在创建后扩展存储可能导致的特性不匹配问题，Kato 选择在构建存储时立即接受自定义配置。他提到，从 v2.15.0 版本开始，该 API 既保持了灵活性，又实现了安全性，难以被误用。
这种灵活性也伴随着代价。有开发者报告了性能回归问题，主要原因在于使用了 WeakMap，而 WeakMap 是为了提升构建模块的灵活性而引入的（#3280）。修复方案将 WeakMap 的实现方式替换为通过参数传递所有内容。Kato 将该解决方案描述为“不够优雅，但符合我的思维模型”，并指出此次发布是他在认真思考 Jotai v3 版本前的最后一步。
对于大多数开发者而言，日常使用的 API 没有变化。创建和使用存储的方式与之前完全一致。
重大变更仅影响库作者使用的内部构建模块，而非典型应用代码。这种影响在下游可见，例如 jotai-devtools v0.14.0 新增了对 INTERNAL_buildStoreRev3 的支持，并移除了旧版本以保持兼容性。仍在使用 Jotai v1 的团队应参考官方的 v2 迁移指南，而依赖 atomFamily 的团队需注意该功能在 v3 版本中已被弃用，建议改用 jotai-family 包。后续两个补丁版本 v2.20.1 和 v2.20.2 已发布，进一步解决了其他边界情况。
社区对此次小版本更新的直接反应较为平淡，这与其“幕后改进”的特性保持一致。不过，关于v3版本的长期讨论仍在持续，并持续吸引贡献者参与。在该讨论线程中，Kato提出了一个明确的v3计划，其中包括重新设计构建块数组结构（即此次发布所涉及的核心内部结构），同时将移除CommonJS构建支持、不再支持React 18以下版本，并删除setSelf选项。
这些提案引发了评论，其中一位贡献者特别针对移除CJS支持发表了看法：
关于移除CJS支持——我认为这甚至不应该成为一个问题。99.9999%的Jotai用户都在使用某种打包工具，而所有打包工具都完全支持ESM。剩下的0.0001%用户可能是使用纯ESM模块的开发者……在这种情况下……嗯……他们本来就在用ESM模块 :D
Kato的回复强调仍需考虑服务端渲染用户的需求。关于降低Jotai与React的耦合度并吸引其他框架的建议，得到了坚定的“以React优先”立场回应。
在更广泛的生态格局中，Jotai仍然是原子化方案的首选库，但其原始下载量仍落后于Kato本人开发的Zustand。项目自身的对比说明指出，Jotai的底层原子设计类似于Recoil，而Zustand则提供了一个更接近Redux的单一顶层存储方案，Kato基于代理的Valtio则又针对不同的思维模型。
Jotai在MIT许可证下开源，可通过npm安装。
关于作者
作者信息
#### Daniel Curtis
显示更多
显示更少
#### 本文属于Web开发主题
##### 相关主题：
- 开发
- JavaScript
- Web开发
- TypeScript
- React
- 相关编辑内容
- 相关赞助商 设计用于失败：如何在云中断期间保证数据访问
- 相关赞助商 智能云基础设施用于您的备份、数据湖和AI。SoFi、Red Bull和Structured Web的团队使用Eon来简化备份、缩短恢复时间，并将数据转化为实时可搜索资产，同时将备份成本降低高达50%。立即了解更多信息 >
InfoQ新闻通讯
每周五内容精选，每周二发送。加入超过25万名高级开发者的社区。查看示例
我们保护您的隐私。