能否用useLocation()钩子替代Redux-Toolkit实现React全局状态管理？

这种用法的核心隐患 #

你当前的用法存在几个关键问题，绝对不建议继续使用：

• 直接修改location.state不会触发组件重渲染：react-router的location对象是路由内部管理的状态，你直接修改state.data = res.data属于手动篡改不可变状态，依赖该数据的组件不会感知到变化，导致页面不更新，数据和UI不一致。
• 页面刷新后数据完全丢失：路由state是存在内存中的临时数据，一旦页面刷新或者路由跳转后回退，state会被清空，直接访问state.data[0].groupId会抛出Cannot read properties of undefined的错误。
• 状态管理逻辑混乱：路由state的设计初衷是传递路由跳转时的临时上下文数据（比如从列表页跳详情页传当前项ID），如果把它当成全局状态容器，随着变量增多，你会完全无法追踪数据的修改来源、流向，调试难度指数级上升。

什么时候适合用useLocation.state #

仅在以下场景使用是合理的：

• 路由跳转时传递一次性、和当前路由跳转强相关的临时数据，比如从列表页跳转到编辑页时，传递当前需要编辑的条目ID或基础信息。
• 不需要持久化、不需要跨多个路由长期共享的数据。

替代方案选择 #

针对你提到的「全局变量增多导致prop drilling」的问题，根据项目规模选择合适的全局状态管理方案：

1. 第三方全局状态库（推荐） #

如果项目规模会持续扩大，或者需要处理复杂的状态更新逻辑、异步操作，优先选择这类方案：

• Zustand：轻量无依赖，API简洁，不需要Provider嵌套，适合大多数中小型项目，学习成本极低。
• Redux Toolkit：Redux的官方推荐写法，简化了Redux的繁琐配置，内置异步处理、状态切片等功能，适合大型复杂项目，生态完善。
• Jotai：原子化状态管理，粒度更细，适合需要拆分独立状态的场景。

2. React内置方案（无额外依赖） #

如果不想引入第三方库，用React自带的Context API + useReducer也能解决prop drilling问题：

• 创建全局Context，通过Provider包裹根组件，在需要共享状态的组件中用useContext获取。
• 配合useReducer处理复杂的状态更新逻辑，避免在多个组件中分散修改状态。

3. 持久化全局数据 #

如果需要状态在页面刷新后不丢失，可以结合localStorage或sessionStorage：

• 在全局状态初始化时从本地存储读取数据。
• 状态更新时同步写入本地存储。

总结 #

绝对不要用useLocation.state存储全局共享状态，赶紧换掉。如果只是少量路由跳转临时数据，可以有限使用路由state，但绝不允许直接修改它的属性。针对全局状态管理，根据项目规模选择第三方状态库或React内置的Context方案，这才是长期可维护的做法。

内容的提问来源于stack exchange，提问作者user2989759