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更适合像企业级电商那种需要大量且复杂状态管理的情况。