Redux-Toolkit createSlice状态更新反模式及赋值写法有效性咨询

问题1：createSlice 更新状态时的反模式 #

以下操作属于createSlice状态更新中的反模式，应避免：

• 在reducer中执行异步逻辑：createSlice的reducers必须是同步纯函数，异步操作（如接口请求）应使用createAsyncThunk或RTK Query实现，不能直接写在reducer里。
• 手动修改action.payload：payload通常来自组件的状态或外部数据，直接修改它会导致组件侧的状态被意外篡改，引发不可预测的bug。
• 返回新状态时未合并原有属性：比如直接return { customEquipment: action.payload }，会丢失state中的其他字段，导致状态被错误覆盖。
• 不必要的深/浅拷贝操作：明明可以通过Immer直接修改state，却手动做return {...state, customEquipment: [...action.payload]}这类冗余拷贝，违背了RTK简化状态更新的设计初衷。
• 依赖外部变量：reducer中引用全局变量、组件状态等外部值，会破坏reducer的纯函数特性，让状态更新逻辑变得不可预测，难以调试和测试。

问题2：直接赋值（Variant A）的合法性分析 #

Variant A 是合法且推荐的写法 #

createSlice的reducer函数是被Immer库包裹的，Immer允许你以“看似可变”的方式修改state，实际上会自动将这些修改转换为不可变的状态更新。所以state.customEquipment = action.payload这种直接赋值的写法完全符合RTK的规范，而且代码更简洁，是官方推荐的方式。

Variant B 的写法（修正后）合法但冗余 #

你提供的Variant B存在语法错误，正确的写法应该是：

return {
  ...state,
  customEquipment: action.payload
}

这种写法是传统Redux的不可变更新方式，在RTK中也可以使用，但属于冗余操作——因为Immer已经帮我们处理了不可变性，直接修改state的写法更高效简洁。除非你明确需要手动控制状态的合并逻辑，否则没必要用这种方式。

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