對於許多 React 開發者來說，Jotai 是一個非常輕量且強大的狀態管理庫。它採用的是 Atomic State（原子化狀態）的概念，也就是將狀態拆分成最小單位的 atom，讓元件能精準地訂閱需要的狀態，避免像傳統全域狀態管理那樣導致整個應用程式不必要的重新渲染。
最近發佈的 Jotai v2.20 版本雖然在 API 層面上對一般開發者幾乎沒有變動，但其內部進行了一次重要的重構，特別是針對高吞吐量（High-throughput）場景下的效能表現。這對於理解狀態管理庫如何平衡靈活性與效能是一個很好的案例。
效能瓶頸的來源：靈活性與 WeakMap 的代價
在 v2.12.0 版本中，Jotai 引入了 Building Blocks（構建區塊）的概念。簡單來說，這是一種讓外部擴展庫（例如 jotai-effect 或 jotai-scope）能夠在 Store（狀態儲存庫）建立時注入自定義邏輯的機制。
為了讓這個機制足夠靈活且安全，開發團隊在內部使用了 WeakMap。WeakMap 是一種特殊的 JavaScript 集合，它允許使用物件作為鍵，且不會阻止垃圾回收機制回收這些物件。雖然這在設計上很優雅，能讓 Store 的擴展變得非常彈性，但在極高頻率的狀態更新場景下，WeakMap 的查找開銷導致了明顯的效能下降。
針對這個問題，v2.20 採取了較為務實的做法：捨棄 WeakMap，改為直接將必要的參數傳遞。雖然這種做法在程式碼結構上可能不如之前簡潔，但它大幅降低了執行時的開銷，解決了高頻更新時的效能退化問題。
這對工程實務的啟示
這次更新告訴我們，在設計框架或底層庫時，追求高度的抽象與靈活性（如使用 WeakMap 實現動態擴展）可能會在極端效能需求下變成瓶頸。當效能成為首要目標時，有時候回歸到最簡單的參數傳遞（Parameter Passing）才是最有效的解決方案。
對一般開發者的影響
如果你只是在專案中使用 Jotai 進行狀態管理，這次更新對你幾乎是透明的，你不需要修改任何程式碼。但如果你是開發 Jotai 插件或依賴其內部 API 的庫作者，則需要注意內部 building blocks 的變動。例如 jotai-devtools 已經更新至 v0.14.0 以相容新的內部結構。
此外，需要提醒的是 atomFamily 已經被標記為廢棄（Deprecated），官方建議未來遷移至 jotai-family 套件，這也是為了迎接 v3 版本所做的準備。
邁向 Jotai v3 的路線圖
v2.20 的重構實際上是為 v3 鋪路。根據作者 Daishi Kato 的規劃，v3 將會帶來更激進的變革：
首先是徹底重新設計 building blocks 的陣列結構，進一步優化內部運作效率。
其次是現代化環境的清理。v3 預計將停止支援 CommonJS（CJS）模組格式，全面轉向 ESM（ECMAScript Modules）。雖然絕大多數開發者使用打包工具（Bundler）可以無縫接軌，但這對某些特殊的伺服器端渲染（SSR）環境可能會有影響。
最後是縮減支援範圍，例如停止支援 React 18 以下的版本，並移除 setSelf 等較少使用且複雜的選項。
總結：Jotai 在狀態管理版圖的位置
在目前的 React 生態中，Daishi Kato 創造了三款互補的工具：Zustand 提供頂層向下的單一 Store（類似 Redux 但更簡單）；Valtio 基於 Proxy 提供可變狀態的直覺操作；而 Jotai 則提供底層向上的原子化狀態（類似 Recoil）。
Jotai v2.20 的這次調整，再次證明了該項目在追求極致效能與 React 深度整合上的堅持。對於追求高效能 React 應用程式的團隊來說，關注這些底層變動將有助於在未來升級 v3 時做出更準確的技術決策。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。