React应用中同时使用Redux与useContext的原因及适用场景示例

二者从设计上就不是互斥的替代关系，硬要二选一反而会写出维护性差、性能拉胯的代码。

很多人纠结要不要联用，本质是没搞清楚这俩工具本来要解决的问题根本不一样。

useContext的适用边界 #

• 它本质是跨层级传参的解决方案，本身不自带状态管理能力，状态怎么改、改完怎么同步，全要自己搭配useState/useReducer实现，别把它当轻量版Redux用。
• 最适合放更新频率极低、全局都要用到的配置类数据：比如应用主题、国际化语言配置、CDN静态资源前缀、用户登录后基本不变的基础信息（uid、昵称、头像）这类。
• 天生性能短板：只要传入Provider的value引用变了，所有调用useContext消费这个值的组件，不管实际用到的字段有没有变，都会强制重渲染。它没有内置的细粒度订阅能力，要是自己拆Context、包memo做优化，复杂场景下的工作量远大于直接用成熟的状态管理工具。
• 没有内置调试能力，状态改了之后为什么改、是谁改的，全靠自己打日志排查，状态流一复杂根本追不动。

Redux（以当前主流的Redux Toolkit用法为准）的适用边界 #

• 它是专门为全局状态共享设计的管理容器，天生带状态变更可溯源、时间旅行调试、中间件扩展、细粒度订阅的能力。
• 最适合放更新频率高、多组件共用、变更逻辑复杂的业务状态：比如电商购物车的增删改查、多步骤表单的跨页联动、实时消息列表、需要全局缓存的接口数据、动态权限点匹配逻辑这类。
• 性能优势明确：搭配useSelector可以让组件只订阅自己真正用到的状态片段，只要这部分数据没变化，哪怕store里其他数据改翻天，组件也不会重渲染。
• 有固定接入成本：要定义slice、配置store，哪怕RTK已经比原生Redux简化了很多，对于只是传个全局静态配置的场景来说，完全是多余的样板代码。

说白了就是让工具干自己最擅长的事：

• 静态弱更新的全局配置，用useContext传，写起来快，没有多余样板代码，反正数据几乎不变，也碰不到Context的性能短板。
• 动态高频更新的业务状态，交给Redux管，靠它的细粒度订阅、调试能力hold住复杂交互场景，不用自己费劲做性能优化。
  既不用为了个主题配置硬写Redux slice，也不用硬扛Context的性能短板存高频更新的业务数据，开发效率和运行性能都能兼顾。

拿最常见的企业中后台系统举例子：

1. 全局配置层用useContext实现
   应用初始化的时候，拉取一次全局静态配置和用户基础信息，直接放到Context里，用Provider包在根组件外层：

const AppConfigContext = createContext(null)

function App() {
  // 这部分数据应用加载完就基本不变，不需要进Redux
  const [appConfig] = useState({
    theme: 'light',
    locale: 'zh-CN',
    staticCdnPrefix: 'https://xxx.cdn.com/assets/',
    userInfo: {
      uid: 10023,
      nickname: '李四',
      avatar: 'default-avatar.png'
    }
  })

  return (
    <AppConfigContext.Provider value={appConfig}>
      <Router />
    </AppConfigContext.Provider>
  )
}

这类数据要是硬塞到Redux里，纯纯增加无意义工作量：它整个生命周期可能都不会更新一次，Redux的订阅优化、调试能力完全用不上，反而要多写一套slice的定义代码。

2. 复杂业务状态层用Redux实现
   比如订单管理模块的业务状态，全部放到Redux里统一管理：

import { createSlice, configureStore } from '@reduxjs/toolkit'

const orderSlice = createSlice({
  name: 'order',
  initialState: {
    list: [],
    filter: { page: 1, pageSize: 20, status: 'all' },
    loading: false
  },
  reducers: {
    updateFilter(state, action) {
      state.filter = action.payload
    },
    setOrderList(state, action) {
      state.list = action.payload
    },
    setLoading(state, action) {
      state.loading = action.payload
    }
  }
})

const store = configureStore({
  reducer: {
    order: orderSlice.reducer
  }
})

组件消费的时候，按需从两个地方取数据就行：

// 订单列表组件
function OrderTable() {
  // 业务状态从Redux取，只订阅自己用到的list和loading，筛选条件变化不会触发当前组件重渲染
  const list = useSelector(state => state.order.list)
  const loading = useSelector(state => state.order.loading)
  // 静态配置从Context取
  const { staticCdnPrefix } = useContext(AppConfigContext)

  return (
    <Table 
      loading={loading} 
      dataSource={list}
      rowKey="id"
    />
  )
}

// 订单筛选组件
function OrderFilterBar() {
  // 只订阅filter状态，列表数据更新不会触发当前组件重渲染
  const filter = useSelector(state => state.order.filter)
  const dispatch = useDispatch()

  const handleFilterChange = (newFilter) => {
    dispatch(orderSlice.actions.updateFilter(newFilter))
  }

  return <FilterBar value={filter} onChange={handleFilterChange} />
}

要是把这部分高频更新的业务状态放到Context里，只要筛选条件或者列表数据变，所有消费这个Context的组件（哪怕是和订单模块没关系的头部导航、侧边栏）都会跟着重渲染，页面组件多了之后会明显卡顿，自己拆Context、包memo做优化的时间，比直接用Redux多好几倍。

不要为了联用而联用。如果是简单的展示类应用，全局没几个动态状态，单独用Context甚至逐层传props都够用；如果应用没有多少静态全局配置要传，全是复杂交互的业务状态，单独用Redux也完全没问题。

内容的提问来源于stack exchange，提问作者Bear Bile Farming is Torture