为何RTKQ的use*Query在refetch返回404错误时仍返回缓存数据

RTK Query默认不会在请求返回错误时清空已有成功缓存，这是框架本身的刻意设计，不是bug：

• 核心设计目标是保障弱网/临时异常场景下的用户体验，避免页面从已有内容的正常状态突然闪成空白、错误状态。不管是4xx还是5xx类的请求失败，只要对应缓存Key之前存过成功响应的有效数据，框架默认会把错误信息单独存在返回值的error字段中，不会主动覆盖、清空data字段的原有缓存值。
• 框架本身无法自动识别404响应的业务语义：它分不清这次404是网关临时异常、服务端重启导致的路由短暂不可用，还是资源真的被永久删除，因此不会自作主张执行清空缓存的操作，把状态判断的控制权交给业务层。

1. 组件层增加错误状态判断（最推荐，侵入性最低） #

不要仅依赖data字段做渲染判断，同时识别404错误状态走对应分支即可：

const { data, error, isLoading } = useGetResourceQuery(resourceId)

if (isLoading) return <LoadingSkeleton />
// 捕获404，走资源不存在的渲染逻辑
if (error && 'status' in error && error.status === 404) {
  return <EmptyState description="访问的资源已被删除" />
}
// 正常有数据的渲染分支
if (data) return <ResourceDetail content={data} />
return null

2. 特定接口局部配置缓存清空逻辑 #

如果某几个接口的404固定代表资源永久删除，可以在对应endpoint的生命周期里手动清空缓存：

const api = createApi({
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  endpoints: (builder) => ({
    getResource: builder.query({
      query: (id) => `/resource/${id}`,
      async onQueryStarted(id, { dispatch, queryFulfilled }) {
        try {
          await queryFulfilled
        } catch (err) {
          // 接口返回404时，主动把对应缓存置为undefined
          if (err.error.status === 404) {
            dispatch(
              api.util.upsertQueryData('getResource', id, undefined)
            )
          }
        }
      }
    })
  })
})

3. 全局统一配置（谨慎使用） #

如果你的业务全量场景下，404都代表资源永久不存在，可以在API实例的extraReducers里加全局匹配逻辑，统一处理404时的缓存清空。注意这个配置会影响所有接口，弱网下如果是网关/服务临时返回404，会导致页面直接清空原有内容，体验下降，非特殊需求不推荐用。

注意：不要随意修改RTK Query默认的错误状态缓存保留逻辑，这个默认策略覆盖了90%以上的常规网络异常场景，贸然调整全局默认行为很容易导致弱网环境下页面频繁闪白、内容跳变，优先用组件层判断错误的方案即可。

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