React状态管理三选一：别在第二个月就踩坑

每个React项目都会在第二个月遇到同一个岔路口。prop drilling让人崩溃，有人说"得搞状态管理了"，接下来两天就是一场观点混战：Redux因为团队熟悉，Zustand因为有人看了篇博客，Context因为"这不是内置的吗？"

真正的错误不是选错工具，而是没意识到这三样东西解决的问题压根不一样。

Context API是传输机制，不是状态库。它让值跨组件树传递，不用层层props往下传。仅此而已。Context里的"状态"就是你在provider旁边写的useState。值一变，所有consumer都重渲染。没有selector层，没有批量更新，没有调试工具。它是根电线，不是仓库。

Redux是单一仓库，更新可预测、可追溯。一个reducer，一个数据源，每次改动走同一条管道，你能回放整个流程。时间旅行调试是设计自带的功能。

你记忆中的Redux大概不是现在人写的Redux。action types、action creators、reducer里的switch语句、connect高阶组件、mapStateToProps——这些让Redux成梗的样板代码，都是老黄历了。Redux Toolkit（RTK）才是现在的写法。创伤是真的，样板代码是假的，这个认知差让大多数"Redux vs X"对比都失了公允。

Zustand是包裹在hook里的仓库。没有provider，没有reducer，没有action。你定义一个store，用selector读取，直接调方法更新。更像"住在组件外面的useState"，而非Flux架构。

同一个简单例子，三种写法，体感差距一目了然：

Context API需要createContext、Provider包裹、useContext取值，setUser藏在context对象里。Redux Toolkit用createSlice定义slice，configureStore创建store，useSelector读值，dispatch触发更新。Zustand直接create一个hook，里面放state和setter，用selector精准订阅，调用即更新。

选型看场景：跨组件传值且更新不频繁，Context够用。需要可预测的状态流、调试能力、中间件生态，Redux Toolkit。想要极简API、无样板、灵活组合，Zustand。

没有银弹，只有错把螺丝刀当锤子的人。