React18搭配Redux时Next.js生产环境路由切换慢问题问询

• 环境表现：使用React 18.0.0~18.2.0版本的Next.js应用，生产环境下路由切换耗时约7秒，开发环境运行完全正常
• 问题背景：该问题从React 18正式发布后就持续存在，项目最初使用legacy版传统Redux时就触发该性能问题，后续花费数周时间迁移至Redux Toolkit后，问题没有任何改善
• 已完成排查：项目服务端Redux采用next-redux-wrapper方案实现，排查过程中发现应用存在多次非必要的hydrate操作，已向该库提交工单反馈，得到官方答复为问题根源不在next-redux-wrapper库本身
• 核心诉求：征集遇到同类问题开发者的排查思路、解决方案参考

以下是同类问题社区验证过的有效排查方向，按排查成本从低到高排序：

• 第一优先级做版本对照测试：将React版本临时锁到17.0.2做生产构建，验证路由耗时是否恢复正常，先确认问题是否由React 18本身的变更触发。如果React 17下表现正常，优先检查React 18自动批处理的兼容问题，可以在createRoot初始化时临时关闭自动批处理做对照：

  import { createRoot } from 'react-dom/client'
  const root = createRoot(document.getElementById('app'), {
    unstable_batchedUpdates: (fn) => fn()
  })
  

  不少Next.js 12.x版本搭配React 18.0~18.2时，路由切换阶段的状态更新会被自动批处理逻辑错误合并，形成长任务阻塞主线程，升级Next.js到12.3.2以上的12.x终版，或者升级到Next.js 13的pages router模式即可修复该兼容问题。
• 检查next-redux-wrapper的HYDRATE动作处理逻辑：绝大多数多次非必要hydrate的问题都来自reducer层的错误配置，不要在根reducer里全量覆盖客户端状态，只针对需要服务端注水的状态切片做浅合并，其余状态切片遇到HYDRATE动作直接返回原state即可。全量合并会导致每次路由触发服务端数据拉取时，所有全局状态的引用都发生变更，连带所有接入Redux的组件全量重渲染，路由切换阶段叠加hydrate逻辑很容易形成数秒的卡顿。
• 排查全局状态订阅的绑定位置：不要在_app组件的函数体顶层直接调用store.subscribe，这类绑定会在_app每次重渲染时生成新的订阅实例，叠加hydrate动作会形成状态更新的链式触发。所有全局订阅逻辑都要放到useEffect中执行，且在effect的销毁回调中解绑订阅。
• 做生产环境的渲染性能定位：生产构建时保留React DevTools的性能分析能力，录制路由切换全过程的火焰图，定位渲染耗时异常的组件。这类长耗时卡顿很多时候是单个接入全局状态的列表、表单类大组件没有做React.memo包裹，在每次hydrate触发的状态更新中都全量重渲染，拖慢整个路由切换流程。
• 排查React 18 StrictMode的兼容问题：如果项目从React 17升级后保留了StrictMode配置，检查所有副作用逻辑是否做好了清理函数，开发环境下的热更新会掩盖重复执行副作用的问题，生产环境下这类重复执行的逻辑（比如重复注册全局事件、重复拉取接口、重复生成大对象缓存）会在hydrate阶段阻塞主线程。

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