核心是将 await 作为同步协调器，配合 mock 服务的可预测异常契约（如 rfc 7807 结构化错误体、retry-after 等响应头），封装带超时重试的语义化 fetch，确保测试能精准 await 并断言异常载荷。
核心在于把 await 当作同步协调器，而不是简单“等完事”。它要配合 mock 服务的可预测异常契约，才能精准捕获并校验异常载荷。
明确 mock 服务需暴露可 await 的异常契约
不能只返回 status=500，而要让测试能 await 到结构化异常体。比如 MSW 或 Playwright route 拦截中，mock 响应必须包含：
- 标准 HTTP 状态码（如 429、503）
- RFC 7807 格式 body：{"type":"/errors/rate-limited","title":"Too Many Requests","detail":"Exceeded quota"}
- 关键响应头：Retry-After、Content-Type: application/problem+json、Access-Control-Allow-Origin
只有这样，await fetch(...) 才能拿到完整异常载荷，而非仅抛出网络错误。
用 await 驱动带超时与重试逻辑的请求封装
直接 await fetch 容易因 timeout 或 network error 中断，丢失异常体。应封装成可 await 的语义化函数：
- 设置合理的 fetch timeout（如 8s），避免无限挂起
- 捕获 AbortError / TypeError 后，区分是网络中断还是 mock 主动返回异常
- 对 408/429/503 等可重试状态码，自动按 Retry-After 头 await 再次发起
- 最终 resolve 的不是 Response 实例，而是 { status, headers, body, isMockError } 结构
在测试断言中 await 异常载荷的字段与时机
不要先 await 再手动解析 body，而应让断言逻辑本身可 await：
- 用 expect(await response.json()).toHaveProperty('type', '/errors/rate-limited')
- 对延迟触发的异常（如 p95 超时 mock），用 expect(await waitFor(() => ...)) 等待 UI 层反馈，而非硬 sleep
- 若 mock 返回 503 + Retry-After: 2，验证第二次请求是否在 ≥2s 后发出，且 await 得到成功响应
避免 await 在分布式 mock 场景下的陷阱
多个 mock 服务节点可能返回不一致延迟或异常策略，导致 await 行为非确定：
- 禁用 process.env.NODE_ENV === 'development' 这类硬编码开关，改用 header（如 x-mock-env: staging）路由 mock 策略
- mock 服务需支持基于请求指纹（如 URL + body hash）返回确定性异常，避免随机 throw
- Playwright 中使用 context.route() 时，确保所有 worker 上下文共享同一 mock 规则，而非每个 test 单独注册
