JavaScript无内置状态管理，是否使用外部库取决于应用复杂度：简单场景用useState足够，中大型项目才需Redux/Zustand等；当状态跨3+无关组件、依赖多异步、需时间旅行或持久化时，应切换方案；Zustand轻量易用，无需Provider；React Query专管服务端状态，不可替代客户端状态管理。
JavaScript 本身没有内置的状态管理机制，状态管理是应用架构层面的选择，不是语言特性。是否需要专门的状态管理，取决于应用复杂度——简单表单用 useState 足够，中大型交互界面才值得引入 Redux、Zustand 或 Jotai 这类方案。
什么时候该放弃 useState/useReducer，改用外部状态库？
当出现以下情况时，useState 开始暴露维护瓶颈：
- 同一份状态被分散在 3 个以上组件中读写，且这些组件无直接父子关系
- 状态更新逻辑依赖多个异步结果（如：先查用户，再查权限，再合并 UI 状态），
useReducer的dispatch链变得难以追踪 - 需要时间旅行调试、状态持久化到
localStorage、或服务端渲染时同步初始状态 - 团队协作中频繁因“谁该负责更新这个状态”产生冲突
Zustand 比 Redux 更轻量的实操要点
Zustand 是目前最接近“开箱即用”的选择，它不强制中间件、不需 Provider 嵌套，API 极简但可扩展性强：
- 创建 store 就是导出一个
create调用：import { create } from 'zustand';<br>export const useCounterStore = create((set) => ({<br> count: 0,<br> increment: () => set((state) => ({ count: state.count + 1 })),<br> reset: () => set({ count: 0 })<br>})); - 组件中直接解构使用：
const { count, increment } = useCounterStore();，无需connect或useSelector - 如需订阅部分状态（避免不必要重渲染），用
useCounterStore(state => state.count) - 插件如
zustand/middleware可轻松加入devtools或persist持久化
React Query 不是状态管理器，但常被误用作替代品
React Query（现名 @tanstack/react-query）专注的是「服务端状态同步」，不是全局 UI 状态容器：
立即学习“Java免费学习笔记（深入）”；
- 它自动处理请求去重、缓存失效、后台刷新、错误重试——这些
Redux或Zustand都不擅长 - 不要把表单输入、折叠面板开关、暗色模式开关塞进
queryClient；它们属于客户端状态，应由useState或Zustand管理 - 典型混合用法：
useQuery获取用户数据 → 存入useUserStore（Zustand）→ 组件从 store 读取并响应式更新 - 若强行用
useQuery管理本地状态，会触发无意义的 refetch，且无法做原子更新（比如只改一个字段）
状态管理真正的难点不在选型，而在于边界划分：哪些状态必须跨组件共享，哪些只需局部持有；哪些该随请求生命周期自动管理，哪些该由用户操作显式控制。过早抽象 store 结构，比选错库更容易拖慢开发节奏。
