2026年了，React 里筛选项切得越快越容易看到上一组数据，是接口返回顺序乱了吗？

结论先说：React 里筛选项切得越快越容易看到上一组数据，多数不是接口返回错，而是请求竞态——后点的筛选先发请求，不代表先回来；慢的旧请求返回时，把新结果覆盖了。2026 年做搜索联想、Tab 筛选、分页列表时，这类问题更常见，重点不在 React 本身，而在有没有给每次请求做身份识别与过期丢弃。

为什么快速切换时旧请求会顶掉新数据

浏览器发出请求的顺序，不等于响应回来的顺序。CDN 命中差异、接口冷热、弱网重试、HTTP/2 多路复用，都可能让先发的请求后返回。React 常见写法是事件触发或 useEffect 发请求，then 里直接 setState；如果不记录这次响应属于哪次筛选，旧响应也会写进同一块 state。

只加 loading 通常不够。loading 只说明有请求在飞，不能说明哪次请求是当前要的那一次。典型场景包括：搜索框里连续输入，短词先回来；Tab 从待付款切到已完成，旧 Tab 数据覆盖新 Tab；分页快速点第 2 页再点第 3 页，表格内容与页码对不上；详情从商品 A 切到 B，A 的价格或库存先落地。

怎么判断是竞态，不是缓存或状态没更新

竞态、浏览器缓存、数据请求库缓存、状态放错位置，表面都像显示旧数据，但排查路径不同。竞态有个特征：慢速操作正常，连续快速切换才复现；缓存往往刷新后还是同一份旧值，和操作速度关系不大。

1. 固定复现路径：连续快速切换 5 到 10 次，记录第几次出现旧数据；快速切换就复现，优先怀疑竞态。
2. 看 Network 时序：对比请求发出顺序与响应返回顺序，再点开响应内容，看旧参数是否晚于新参数落地。
3. 加请求标识：在 then 里打印参数、requestId 和落地时间；旧参数结果最后写入，基本可确认是竞态，而不是缓存命中。

另一个容易忽略的点是组件卸载后请求仍在跑。较新的 React 版本对卸载后 setState 的警告不再明显，但请求没有停，快速切回时可能把旧数据写进新页面。

可核对的收口：请求时序四核对

把竞态当成请求生命周期问题，比在 then 里零散加 if 更容易验收。2026 年常见交付习惯是核对四步：触发源、标识、取消、落地。

1. 触发源：确认请求由点击、useEffect 依赖变化、轮询还是路由切换发起，先统一入口，避免同一份数据多个触发点。
2. 标识：每次请求带 requestId 或参数快照，并在组件里保存当前有效标识。
3. 取消：能用 AbortController 就取消旧请求；不能取消的接口，把过期响应标记出来。
4. 落地：setState 前比对标识，只处理与当前标识一致的结果；卸载或依赖变化时在 cleanup 里清理。

验收可以写成可核对清单：连续快速切换 10 次，内容与当前选中项一致；Network 里旧请求显示已取消或已过期；报错或超时时进入明确错误或空状态，不保留上一次数据；切走再切回，筛选条件和列表内容同步。这样比“看起来没问题”更容易回归。

几种做法的对比与经验区间

取消请求、标记过期、交给数据请求库没有绝对好坏。下面按适用对象、经验区间和边界对比，周期只是常见区间，以项目复杂度为准。

• AbortController + useEffect cleanup：适合原生 fetch、请求量不大、列表和筛选共用一个请求函数。改动集中在请求层，经验区间约 0.5~1 人天。边界是老接口或第三方 SDK 不接收 signal 时，要退回过期标记。
• requestId 或参数快照比对：适合 axios 项目、接口不方便取消、多个组件共用一个请求函数。经验区间约 0.5~1 人天，但新增调用点要记得比对标识，容易漏。
• React Query、SWR 等数据请求库：适合请求多、缓存复杂、分页与筛选并发的项目。库会处理缓存、去重和部分竞态，但查询键设计仍要自己负责；引入与迁移经验区间约 3~5 人天，另加团队熟悉成本。

交付现场：快切筛选时旧数据是怎么暴露的

一类列表页项目里，约束条件很典型：两轮联调、接口由第三方提供、不方便加取消逻辑，筛选参数还经常变。做法是先在请求层加 requestId，useEffect cleanup 里标记过期，来不及接 AbortController 的接口只做丢弃。上线后仍有用户反馈“切快了会显示上一组数据”，排查发现分页组件单独发请求，没走同一个请求层，后来把筛选和分页统一收口才稳定。代价是返工约半天到一天，还要补一轮回归；如果一开始按四核对统一入口，这段成本常见区间可以省掉。团队在做网站与 H5 交互交付时，也把这条列入联调检查项，尽量避免上线后靠用户反馈发现。

适用与不适用边界

竞态收口适合“切换频繁 + 数据落点共用”的页面，比如搜索联想、Tab 筛选、分页列表、详情快速切换、仪表盘多卡片刷新。判断标准是：用户能在请求返回前发起下一次同类请求，并且两次结果写进同一块 UI。

不适用或不必上的情况同样明确：一次性静态数据、表单提交、后端已经按版本号只返回最新结果，或者切换后跳到独立页面且不共用数据落点。边界可以记成一句：读接口并发切换优先处理竞态，写接口和一次性加载先保证幂等与错误处理。

常见问题

用 useEffect 发请求，一定要写 cleanup 取消吗？

不一定。请求结果只写进已卸载组件时，取消能减少无效更新；页面不快速切换，影响有限。2026 年常见做法仍会加上，成本不高。

用了 React Query 还会显示上一次数据吗？

会。React Query 处理缓存与去重，但查询键没带筛选参数，或占位数据配置不当，切换后仍可能短暂显示旧数据，要先检查 queryKey。

为什么加了 loading 还是会闪旧数据？

loading 只控制显隐，不控制哪次响应落地。旧请求后返回时仍会写进 state，要拿 requestId 或取消机制拦住它，不能只靠 loading。

AbortController 和 axios CancelToken 该用哪个？

能用 AbortController 就用它，属于平台标准；axios 较新版本也支持 signal。CancelToken 属于旧接口，老项目按团队约定维护即可。

如果项目已经出现快速切换显示旧数据，先按请求时序四核对从触发源走到落地，再把取消或过期标记收口到统一请求层。它适合并发切换频繁、UI 共用一个数据落点的页面；静态展示页、后端已按版本返回最新结果的接口，不必额外引入请求库。按 2026 年交付习惯，先用小改动验证，再决定要不要上完整方案。