已使用Redux的项目能否用Context API作为额外状态可信源？

不建议通过混用Context API的方式解决这个字段重名问题，这种做法会直接破坏Redux单一可信源的核心原则，引入更高的维护成本，字段命名冲突是非常基础的状态结构设计问题，完全不需要新增第二套状态管理方案就能解决。

为什么不推荐混用两套状态方案 #

• 混用Redux和Context管理全局状态会直接打破单一数据源约定，后续状态调试、更新逻辑追踪、跨模块状态同步都会变得混乱，为了省重命名字段的一点工作量引入长期维护负担，性价比极低。
• 字段重名本质是状态树语义设计不合理导致的，不是Redux本身的能力缺陷，引入新方案属于典型的治标不治本。

推荐的解决方式 #

方案1：优化原有状态字段的语义命名（优先推荐） #

你当前将当前登录用户信息存在state.users路径下，本身语义就不够精准——users从字面含义上更适合指代用户集合、用户列表，你完全可以将原有存储个人信息的字段调整为更匹配语义的路径，比如迁移到state.currentUser下，空出state.users路径存储接口返回的用户数组，调整后的mapStateToProps写法如下：

const mapStateToProps = state => ({
  myInfo: state.currentUser.myInfo,
  activeUsers: state.users
})

如果项目中已经有大量逻辑依赖原有state.users路径，你可以先给原有字段加兼容层，逐步替换旧逻辑，不需要一次性全量修改。

方案2：给新模块的状态定义独立的不冲突字段名 #

如果暂时不想调整原有代码逻辑，完全不需要强行占用state.users路径存新的接口数据：Redux没有任何规则要求前端存储接口数据时，必须和接口返回的字段名保持一致，接口字段是后端定义的，前端存入store时可以自由映射到自定义的状态路径下。
比如你可以把接口返回的活跃用户数组存在state.activeUsers或者state.userModule.activeUsers这类独立路径下，完全不会和原有字段冲突，示例逻辑如下：

// 接口请求拿到响应后，dispatch时直接映射到自定义字段
const res = await getActiveUsersApi()
dispatch({
  type: 'activeUsers/update',
  payload: res.users // 接口返回的users数组直接存入自定义的状态字段
})

// 组件取数时原有逻辑完全不需要改动
const mapStateToProps = state => ({
  myInfo: state.users.myInfo, // 原有逻辑保持不变
  activeUsers: state.activeUsers // 新状态从独立路径取数
})

补充说明 #

Context API本身适合做组件树范围内的、轻量的、不需要跨全局共享的状态传递，如果你新模块的状态完全是模块内闭环、不需要和其他Redux状态联动，也可以用Context，但这和解决字段重名冲突没有任何关系，也完全没必要为了规避命名问题特意选用。

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