高频异步计算的核心矛盾是并发后的可控、可溯、可稳，需通过流控机制将异步爆发力约束在体验安全区，而非单纯追求并发能力。
大型 SPA 项目在高频异步计算场景下，核心矛盾不是“能不能并发”，而是“并发之后能否可控、可溯、可稳”。选型不是比参数，是比结构适配性——前端运行时环境的单线程本质、用户交互的不可预测性、网络与计算资源的动态波动，共同决定了：必须用流控机制把“异步爆发力”约束在体验安全区之内。
明确高频异步计算的真实边界
先区分三类典型场景，它们对流控的要求截然不同：
- 用户触发型：如搜索联想、表单实时校验、拖拽反馈。特点是低延迟敏感（
- 数据驱动型：如仪表盘多维聚合、实时图表重绘、大表格虚拟滚动计算。特点是计算密集、中间状态需保留、结果有优先级（如最新请求覆盖旧请求）。适合 RxJS 或自研 Observable 流 + 操作符（switchMap、exhaustMap）做请求调度。
- 后台协同型：如离线任务提交、批量导出、AI 推理请求排队。特点是长耗时、需状态持久化、失败可重试、用户需感知进度。适合引入轻量级任务队列（如使用 Web Worker 封装的 queue-microtask 或 custom event loop），配合 IndexedDB 存储任务元数据。
关键能力维度必须验证
不依赖框架宣传话术，用真实前端约束反推能力刚性需求：
- 内存泄漏防御：所有订阅必须显式销毁；自动清理未完成的异步操作（如组件卸载时 cancel 所有 pending fetch）；避免闭包中长期持有 DOM 引用。
- 错误传播路径清晰：拒绝静默失败；错误必须能原路回传至触发源（如按钮点击事件）；支持按错误类型分级处理（网络超时走重试，数据格式错走 fallback UI）。
- 可观测性内置：提供开箱即用的 trace ID 注入、耗时打点、并发数监控；支持 DevTools 插件或自定义 performance.mark/measured 标记关键路径。
- 降级开关就绪：能在运行时一键关闭某类异步逻辑（如禁用所有自动保存），不依赖代码重新部署；降级后 UI 行为保持一致（如变灰按钮 + 提示文案）。
主流方案落地要点对比
不是非此即彼，而是按模块分层选用：
- RxJS：适合中大型团队、已有 Angular 或强响应式经验的项目。优势在操作符生态成熟（retryWhen、delayWhen 等精细控制），劣势是学习成本高、包体积大（需 tree-shaking + operator patching）。
- React Query / SWR：聚焦服务端状态同步，天然解决请求去重、缓存、背景更新。但对纯前端计算流（如 Canvas 渲染帧计算）无直接支持，需额外封装。
- 原生 AbortController + 自定义 Hook：轻量、零依赖、调试直观。适合对性能极致敏感或需深度定制的场景，但需团队统一约定取消策略与生命周期绑定方式。
- Web Worker + MessageChannel：真正隔离 CPU 密集型计算，防止主线程卡顿。必须配合 transferable 对象（如 ArrayBuffer）减少拷贝开销；注意 Worker 启动延迟与跨域限制。
必须写进项目规范的底线规则
白皮书最终要落地为可执行的工程纪律：
- 所有异步调用必须声明 timeout，全局默认 8s，关键操作（如登录）≤3s；
- 任何异步操作不得直接修改全局状态，必须通过统一 dispatcher（如 Redux store.dispatch 或 Zustand set）；
- 每个异步流程入口必须携带 context（如页面路径、用户操作动作、traceId），用于错误归因与日志关联；
- 禁止在 useEffect 中发起无 cleanup 的定时器或轮询；轮询必须用 useRef 保存 timerId 并在卸载时 clearTimeout。
