React函数组件在Props未变更时异常重渲染问题排查（基于useSelector）

根据你描述的场景，这个问题的核心原因大概率是组件重渲染并非由useSelector触发，而是来自父组件的强制重渲染，或者是Redux reducer的写法间接影响了组件的渲染逻辑。下面分点拆解原因和对应解决方案：

一、最可能的原因：Component A未被React.memo包裹 #

你提到给子组件加了React.memo但无效，这是因为如果父组件（Component A）本身发生了重渲染，即使子组件用了React.memo，只要父组件在渲染时传递的props引用没有变化，子组件不会重渲染——但问题出在Component A本身：

• React的默认行为是：父组件重渲染时，所有未被React.memo包裹的子组件都会跟着重渲染，不管子组件的props是否变化。
• 当Component B修改store.B时，整个Redux store的根对象会生成新的引用（因为reducer会返回{...state, B: newB}），如果包裹Component A和B的父组件（比如App组件）没有做渲染优化，父组件会因为store变化而重渲染，进而导致Component A也跟着重渲染。

解决方案： #

给Component A也加上React.memo包裹：

const ComponentA = React.memo(() => {
  // 组件逻辑
});

这样，当Component A的props（包括useSelector返回的数据）没有变化时，即使父组件重渲染，A也会跳过重渲染，子组件自然也不会被触发。

二、排查Redux reducer的写法是否有误 #

虽然你说useEffect监听useSelector的结果未触发，但仍需确认reducer在处理store.B的action时，是否意外修改了store.A的引用：

比如错误的reducer写法（不小心复制了store.A）：

const appReducer = (state, action) => {
  switch(action.type) {
    case 'UPDATE_B':
      return {
        ...state,
        A: {...state.A}, // 这里错误地创建了新的A对象，导致引用变化
        B: action.payload
      };
    default:
      return state;
  }
};

这种情况下，store.A的引用会变化，useSelector返回的state.A是新对象，理论上useEffect会触发，但如果你的useEffect依赖是store.A的某个属性而非整个对象，可能不会触发。

解决方案： #

确保reducer仅修改需要更新的state分支，不要触碰其他分支：

const appReducer = (state, action) => {
  switch(action.type) {
    case 'UPDATE_B':
      return {
        ...state,
        B: action.payload // 只更新B分支，A分支保持原引用
      };
    default:
      return state;
  }
};

三、优化useSelector的比较逻辑 #

虽然你的场景中useSelector返回数据未变，但可以显式指定比较函数来确保不会误判：

import { shallowEqual } from 'react-redux';

const dataA = useSelector(state => state.A, shallowEqual);

shallowEqual是React Redux提供的浅比较函数，确保只有当返回值的浅层次属性变化时才触发重渲染，避免因根state变化导致的误判。

四、排查Component A的重渲染触发源 #

可以在Component A中添加日志快速定位问题：

const ComponentA = () => {
  console.log('Component A 重渲染了');
  // 其他逻辑
};

结合Redux DevTools查看action触发时的调用栈，确认重渲染的触发源头是否来自父组件或其他意外逻辑。

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