7月22日，React 原子化状态管理库 Jotai 发布 v2.20.0，核心变化是重新设计了 Store 构建模块，目的是提升高吞吐场景下的性能。这次改动为即将到来的 Jotai v3 铺平道路，但对普通开发者无感——破坏性变更仅影响库作者。
Jotai 的构建模块理念最早在 v2.12.0 引入，目的是让生态库（如 jotai-effect、jotai-scope）能够扩展核心能力。当时的方案是暴露内部机制，让库作者在创建 store 时通过配置定制化。到 v2.15.0，这套 API 被认为是“足够灵活且安全”。
但灵活带来了代价：WeakMap 方案导致性能下降。高吞吐场景下，频繁的 WeakMap 查询成为瓶颈。痛点被报告在 Issue #3280 中。
注：横轴表示版本成熟度，非量化指标。v2.20.0 是里程碑，解决了前序版本的性能问题。
修复方案非常直接：放弃 WeakMap，改为通过参数传递所有内容。核心贡献者 David Maskasky 实现了这一改动，包括：
使用 WeakMap 实现灵活扩展，代价是每次 store 操作都要查询 WeakMap，高并发场景下性能下降明显。
通过参数传递构建模块，避免 WeakMap 查找。作者评价“不是特别优雅，但符合思维模型”。
注：普通开发者 API 无任何变化，创建 store 方式与之前完全一致。仅影响使用内部构建模块的库作者。
对于这个小版本更新，直接反响较为平淡——毕竟对大多数用户来说什么也没变。但围绕 Jotai v3 的长期规划引发了贡献者讨论，尤其是关于移除 CommonJS 的提议。
“移除 CJS——我认为这甚至不应该成为一个问题。99.9999% 的 Jotai 用户都在使用某种构建工具，而所有这些工具都很好地支持 ESM。”
—— 一位贡献者在相关讨论中表示但作者 Daishi Kato 回应指出，仍需考虑服务端渲染用户的需求。对于降低 Jotai 与 React 的耦合、吸引其他框架用户的建议，他明确表示坚持 React 优先的立场。
Kato 在《Read the Code》newsletter 中解释，这次改动是他开始认真思考 Jotai v3 之前的最后一步。v3 规划已明确包括：
注：竖线长度表示该变更在 v3 中的优先级（非量化）。移除 CJS 因 SSR 需求仍在讨论中。
一个诚实的注脚：
虽然 Jotai 在 atom 状态管理领域领先，但原始下载量落后于 Kato 自己创建的 Zustand。Jotai 采用自底向上的 atoms 模型（类似 Recoil），而 Zustand 提供单一自顶向下的 store（接近 Redux）。两者满足不同思维模型，没有绝对的优劣。
底层架构的每一次重构，都是对「灵活性与性能」平衡的重新校准。Jotai v2.20.0 证明：当灵活性开始拖累性能时，果断放弃优雅的 WeakMap 方案、回归参数传递，是务实的工程选择。v3 的规划更值得关注——它可能决定 Jotai 是成为下一个 Recoil 还是下一个 Redux。
Jotai v2.20.0 已发布至 npm，通过 npm install jotai@latest 即可升级。现有项目无需修改代码。