Redux dispatch action耗时过长但绑定reducer执行速度快如何排查

• 优先排查重渲染开销：dispatch执行完reducer后，会触发所有订阅store的组件执行状态比对和重渲染逻辑，这部分开销完全计入dispatch总耗时，但不会被reducer内部的打点捕获。你可以先注释掉所有依赖该action修改的state字段的组件，再复测dispatch耗时，如果耗时大幅下降，说明是组件重渲染/selector比对逻辑的问题，常见的诱因包括：大量组件订阅了相关状态、useSelector没有配置浅比较每次都触发重渲染、mapStateToProps返回新对象导致不必要的重渲染。
• 排查Redux中间件开销：所有插入到dispatch链路的中间件逻辑都会计入总耗时，比如redux-devtools会序列化全量state做时间旅行、日志中间件会打印全量state、自定义中间件的遍历/拷贝逻辑，都可能带来数百ms的开销。你可以临时禁用所有非必要中间件后复测，快速定位是否是中间件的问题。
• 排查不可变数据更新的隐式开销：如果你的reducer使用了immer/immutable.js这类库，你打点统计的只是业务计算逻辑，库生成新的不可变对象的耗时发生在你修改draft后、reducer返回前，尤其是当你修改的state节点数据量大、层级深时，这部分开销很容易被忽略。你可以临时替换为原生手写的不可变更新逻辑，对比耗时变化确认问题。
• 用Chrome Performance面板精准定位耗时点：录制性能快照时开启「JavaScript samples」选项，找到对应800ms的dispatch任务块，展开调用栈即可看到所有子函数的耗时占比，非reducer的子函数总耗时就是你缺失的770ms的去向。如果调用栈里出现大量render、useSelector、memoizedFn相关的调用，即可快速定位到问题链路。
• 排查微任务队列阻塞开销：你的thunk action是async函数，dispatch执行过程中如果触发了大量Promise微任务，这些微任务会在当前调用栈清空后执行，整体会被计入setTimeout handler的总耗时。你可以用下面的代码补充打点确认：

const t = performance.now();
dispatch(someAction(data));
Promise.resolve().then(() => {
  console.log('dispatch+微任务总耗时', performance.now() - t);
})

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