如何禁用serializable state invariant middleware及RTK Query卡顿排查

DevOps 小满

2026-8-26

问题成因

该报错和RTK Query的endpoints数量无直接关联，不存在固定的接口数量阈值触发这类性能问题。
serializable state invariant middleware是Redux Toolkit默认仅在开发环境启用的校验工具，会递归遍历所有派发的action、全量store state，校验所有值均为可序列化类型。你在新增接口后触发耗时告警，核心原因通常是以下几类：

新增接口的响应数据中混入了不可序列化值，包括但不限于类实例、DOM节点引用、Symbol类型值、带循环引用的对象
该接口对应的transformResponse、onQueryStarted、缓存更新逻辑中，往RTK Query缓存或action元数据中传入了不可序列化内容，比如Promise实例、函数、组件引用
接口返回数据存在异常的深层嵌套结构，即使整体数据体积不大，递归遍历校验的过程也可能出现耗时陡增，触发默认32ms的耗时告警阈值
默认告警逻辑不会直接打印触发问题的具体action路径和值，所以会出现无法定位具体问题内容的情况。

排查步骤

不要直接全局禁用序列化检查，先定位具体问题点：

调整store的中间件配置，放开日志限制，打印完整的校验异常信息：

export const store = configureStore({
  reducer: {
    [userAuthApi.reducerPath]: userAuthApi.reducer,
    cart:cartSlice.reducer
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware({
      serializableCheck: {
        warnAfter: 200, // 临时调高耗时阈值，避免日志被截断
        ignoredActions: [], // 清空默认忽略列表，确保所有action都进入校验范围
      }
    }).concat(userAuthApi.middleware)
})

控制台会直接输出检测到的不可序列化值所在的action类型、state/action的具体路径，优先检查新增接口的响应处理逻辑、缓存更新逻辑即可定位问题。

解决方案

根据排查结果对应处理：

若确实存在不可序列化值：将这类值移出Redux state和RTK Query缓存，函数、DOM引用、Promise实例这类内容本身就不应该存储在Redux中，应放在组件ref等非响应式存储位置。
若确认所有存储内容都是合法可序列化值，仅校验递归过程拖慢开发速度：针对性调整序列化检查配置即可，无需全局禁用：

middleware: (getDefaultMiddleware) =>
  getDefaultMiddleware({
    serializableCheck: {
      // 根据自身机器性能调整告警阈值，通常设置为100~200ms即可消除误报
      warnAfter: 128,
      // 忽略RTK Query内部的流转action，这类action由框架内部生成，无用户侧不可序列化风险
      ignoredActions: Object.values(userAuthApi.endpoints).flatMap(endpoint => [
        endpoint.matchPending.type,
        endpoint.matchFulfilled.type,
        endpoint.matchRejected.type
      ])
    }
  }).concat(userAuthApi.middleware)

注意：该中间件默认不会在生产环境启用，所有配置调整仅影响开发环境运行速度，不会对生产构建包体积、运行性能产生影响。

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