React服务端响应后组件未触发重渲染问题排查

这是React/Redux开发里非常典型的不可变更新失效+浅比较误判问题，新增逻辑能生效只是刚好碰中了重渲染触发条件，编辑/删除场景才是逻辑问题的真实表现。
具体原因对应你的代码和现象：

• Reducer没有做全路径的不可变更新
  从代码写法看你大概率用的是Immer（Redux Toolkit默认集成），但如果你是手动写的原生useReducer，直接给state[flag]、state.showMessages[flag]赋值而不返回全新的state根对象，Redux/React的浅比较会判定state引用未变化，不触发组件重渲染。
  新增消息能生效是因为数组长度改变，会触发你项目里其他依赖消息数、列表滚动的组件重渲染，间接带动消息列表刷新；删除操作不改变数组长度，没有额外的重渲染触发点，自然不会更新。
• 列表key设置错误+子组件缓存逻辑缺陷，完全匹配你描述的异常现象
  你提到「发新消息→点删除→再发新消息才会显示变更」，这是非常明确的信号：你用数组索引作为列表项的key，同时单条消息组件内部用useState或useMemo缓存了消息内容，没有把最新的props消息作为依赖同步更新。
  这种写法下，单条消息组件只会在首次挂载时读取一次消息内容，后续props更新不会同步修改内部缓存。在数组末尾发新消息时，已有消息的索引key不变，组件不会重挂载，就一直显示旧内容；只有数组长度变化触发全量列表diff、或者某一项key变化导致组件卸载重挂时，才会读到最新的删除状态。
• 对浅拷贝的作用存在认知偏差
  你写的[...response.data]、[...state[flag]]都只是浅拷贝数组第一层，仅生成了新的数组实例，数组内部的消息对象如果和旧state里的引用一致（比如开了axios响应缓存、前端做了对象复用），被React.memo包裹的子组件做props浅比较时，会判定消息对象未变化，直接跳过渲染。
  新增消息时数组里多了一个全新的对象引用，子组件能检测到新增项，所以正常渲染；删除只是修改已有对象的属性，没有更换对象引用的话，就会被浅比较逻辑跳过。

• 修正Reducer的不可变更新逻辑
  如果是原生useReducer，必须逐层生成新的引用，返回全新的state对象，不要直接修改原state：

  setMessages(state, action) {
    const { fetchedMessages, flag } = action.payload;
    return {
      ...state,
      [flag]: fetchedMessages,
      showMessages: {
        ...state.showMessages,
        [flag]: fetchedMessages
      }
    }
  }
  

  如果用Redux Toolkit的Immer，不需要手动返回新对象，但要避免复用旧state里的对象引用。
• 更换列表项的key
  不要用数组索引作为key，在服务端存储消息时给每条消息生成全局唯一的固定id，渲染列表时key绑定这个唯一id，避免索引变化导致的组件状态错乱。
• 修正子组件的缓存逻辑
  单条消息组件不要用内部state缓存props传入的消息内容，直接消费props渲染即可；如果用useMemo做渲染优化，必须把传入的message对象加入依赖数组；如果用了React.memo，确保自定义比较逻辑不会跳过必要的更新。
• 移除无意义的浅拷贝
  axios解析JSON响应生成的response.data本身就是全新的数组/对象，不需要额外写[...response.data]做一层浅拷贝，避免引入不必要的引用问题。

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