React 18 并发渲染下 useEffect 清理竞态产生幽灵状态，如何在线上可观测地捕获并归因到具体组件？

【背景】 React 18.2 + Vite 5 的 B 端中台，约 120 个路由，大量使用 useEffect 做副作用（API 请求、WebSocket 订阅、定时器）。今年启用了 Concurrent Mode（startTransition + Suspense 包裹列表页），同时保留了 useEffect 做数据拉取和订阅。

【现象】 近一个月线上出现一类"幽灵状态"：用户反馈"列表页偶尔显示上一页的数据"、"筛选条件已切换但图表还是旧数据"。这类问题不抛错、不白屏，ErrorBoundary 完全捕获不到；RUM 里也没有异常上报，只是业务数据不一致。本地复现极不稳定（依赖渲染时序），一旦复现就能确认是 useEffect cleanup 和 effect body 之间的竞态窗口——具体来说：

1. 用户快速切换路由（<Suspense> 边界内组件 unmount → mount），旧组件的 useEffect cleanup 被推迟（因为并发渲染下 unmount 不保证同步执行），而新组件的 effect 已经跑完；
2. 旧 cleanup 执行时调用 clearInterval / ws.close()，但因为 React 18 的调度器把 cleanup 排到了 microtask 之后，此时新组件已经用同一个全局 store 写入了新数据，旧 cleanup 又触发了一次 dispatch({type: 'RESET'})；
3. 结果：新组件拿到的是被旧 cleanup 重置后的空状态，但 UI 上因为 useMemo 缓存还显示着旧值——用户看到"筛选变了但数据没变"。

【已尝试的排查】

1. React DevTools Profiler 录操作回放：能看到 unmount/mount 的时序，但 cleanup 的实际执行时机在并发模式下被调度器重排，Profiler 里看不到真实的 cleanup 执行点（只看到 delete all children 的 commit）；
2. 在 useEffect cleanup 里加 console.trace + 自定义 mark：线上采 0.1% 用户，抓到过 3 次，但 trace 栈里只有 commitDeletion → commitHookEffectList，无法区分是"正常卸载清理"还是"竞态窗口里的延迟清理"；
3. 给全局 store 的 dispatch 包了一层，记录每次 dispatch 的调用栈 + 当前 React fiber 的 stateNode：理论上能追踪到"谁 dispatch 了 RESET"，但并发模式下 fiber 树在 commit 前可能已被替换，拿到的 stateNode 有时是旧组件、有时是新组件，无法稳定归因；
4. 把 useEffect 全部换成 useLayoutEffect 试了一版：问题确实消失了（因为 layout effect 同步执行），但列表页首屏 INP 涨了 40ms（200+ 个列表项的 layout effect 同步跑），不能接受。

【期望得到的答案形态】

1. 可观测性方案：如何在 React 18 并发模式下，稳定地在线上捕获"effect cleanup 延迟执行"这一事件？具体地：在什么 hook 里埋点、采哪些字段（fiber id、组件路径、cleanup 排队时刻 vs 实际执行时刻的 delta）、如何区分"正常卸载"和"竞态窗口延迟"——最好有可复现的埋点代码（含 __DEV__ 守卫和线上采样策略）；
2. 归因方案：拿到一条"cleanup 延迟"事件后，如何把 delta > 阈值的事件关联到具体的路由切换操作 / 具体的 useEffect 声明位置（源码行号），而不是只看到 commitHookEffectList 这种调度器内部函数名？
3. 长期解法：除了 useLayoutEffect（性能代价太大）和"避免在 cleanup 里写全局状态"（改动面太大），社区里有没有更轻量的模式？比如：a) 用 useRef 标记"本组件是否已被新实例替代"来 guard cleanup；b) 用 AbortController 链式取消；c) React 19 的 useEffectEvent（如果已稳定）能否从根源消除这类竞态？各方案的适用边界和已知坑是什么？
4. 测试方案：这类时序竞态在单测里怎么覆盖？jest 的 fake timers 够吗？还是需要 react-test-renderer 的 act + 手动调度 flushSync 来模拟并发窗口？有没有更贴近线上真实调度时序的测试手段？

我比较关注可复现性：最好能给出埋点代码片段、字段设计、以及一个最小可复现的 demo（两个组件共享一个 store，模拟快速切换路由触发竞态），而不是只讲原理。