Context的出現解決了什么問題？

Vue中的provide/inject和React中的Context非常相似，具體區別如下：

可以看到實際上最大的區別在于Vue是響應式，React是非響應式

那么context具體解決了什么問題？我們先看下面這個例子：

function ComponentA() {const count = 10;return <ComponentB count={count} />
}function ComponentB({ count }) {return <ComponentC count={count} />
}function ComponentC({ count }) {return <ComponentD count={count} />
}function ComponentD({ count }) {return <ComponentE count={count} />
}function ComponentE({ count }) {return <div>{count}</div>
}

這種層層傳遞的形式就是典型的prop drilling (prop下鉆)，會產生什么問題？

1.性能損耗（props改變會導致所有傳遞組件重新渲染）

2.難以維護（這個就不用多說了吧，可讀性很差）

3.心智負擔（react經典問題）

**那使用Context足夠完美嗎？**當然是不夠，Context依舊有性能損耗問題，Context中任意的屬性變化會引起所有使用該Context的組件發生re-render(重新渲染)，及無法只訂閱局部變量，如何解決：
1.拆分Context，保證每個組件有屬于自己的獨立依賴空間且各組件間互不影響。

2.使用memo或者useMemo包裹組件（常見的react優化）。

為什么有Context還需要狀態管理庫，區別是什么？

根據上文我們可以知道context在優化是可以滿足全局狀態管理的需求的，那為什么還是要使用zustand這種狀態管理庫呢？

Context 可以實現全局狀態管理，但優化（如避免重復渲染）會增加代碼復雜度和心智負擔，且功能性有限。Zustand 提供選擇性訂閱、異步支持等特性，易用性更強。

Context 依賴組件樹，耦合度高，而 Zustand 獨立于組件樹，靈活性更高。Context 優勢在于輕量、無依賴，適合簡單場景。

狀態管理庫與設計模式

redux的核心是發布訂閱模式，而zustand等大部分狀態管理庫的核心是觀察者模式。

如何理解觀察者模式？vue的響應式核心就是使用的觀察者模式，一個觀察者和多個被觀察者直接通信，耦合度較高；發布訂閱模式其實就是觀察者模式的升級，多了一個用于派發的中間件（事件總線），發布者和訂閱者不直接通信，耦合度較低；

redux和zustand有什么區別

redux的核心是發布訂閱模式，zustand核心是觀察者模式，從設計模式角度，redux比zustand多了事件總線用來派發任務，在任務量大的情況下由于發布訂閱模式的中間件及事件派發會像虛擬dom一樣造成一定的性能損耗，所以性能不如觀察者模式，延遲也相對較高。

所以zustand就像一個功能性更強的全局useState更加輕量易用適合中小型項目，而redux更適合像企業級電商那種需要大量且復雜狀態管理的情況。