以我所主，为我所用

链式 Follow 如果中间环节报错前端怎么捕获

4 min read

面试防线：链式 Follow 客户端如果中间环节报错怎么捕获与反馈

面试官提问：
“你在 SDK 里封装了极其优雅的 client.follow(self).follow(approve).post(payload) 链式调用。但是在复杂的网络中，每调用一次 follow 其实背后可能都在隐式发请求拿最新的状态资源。如果中间这一大串异步链条在某个节点断了或者鉴权报错了，前端 UI 怎么精准捕捉错误并给用户有效反馈？”

核心回答思路 (STAR法则)

  1. 业务痛点 (Situation)
    当把原本平铺的 fetch 调用封装为高度抽象的 Fluent API（链式流接口）后，开发者写起来很爽，但 Debug 起来很痛苦。如果是 follow(a).follow(b) 在请求 B 链接时报 403 权限不足，前端常规的 try-catch 往往只能拿到一个模糊的“网络错误”，导致页面只弹出一个无意义的“系统异常” Toast。

  2. 技术考量 (Task)
    这其实是 RxJS 或者高阶 Promise 链经常面临的“错误溯源不清”问题。我必须在 SDK 底层拦截链条的每一步，并抛出一个定制化异常领域模型。

  3. 架构决策 (Action)

  • 领域异常类封装 (Domain Error Classes)：我重写了底层的基础错误抛出类，不再使用普通的 Error。一旦在某一次隐式的 fetch 中遇到非 200 响应，系统会立即阻断当前执行链，并抛出特定的 HateoasTraversalError 领域错误。
  • 保留轨迹的断点快照 (Breadcrumb Context)：这个定制化的 Error 对象中，包含了一个极其关键的属性 breadcrumb（面包屑轨迹）。当抛错时，它会记录：当前请求到第几层链路了（比如 [self, approve]）、上一个成功节点返回的原始数据是什么、此次报错的具体 URL 和 HTTP 状态码是什么。
  • 全局拦截层与降级渲染 (Error Boundaries 融合)：业务研发在页面级捕获这个 Error 后，不再是瞎猜。他可以通过异常上的属性直接让 UI 弹出精确的反馈：“尝试拉取审批节点信息失败，暂无权限 (403)”，甚至将之前成功的上下文直接交由 React 的 ErrorBoundary 进行带状态的降级局部渲染，而不会导致整个页面因为中间一个资源抓取失败而整体崩溃。
  1. 业务价值 (Result)
    通过给高度抽象的链式调用挂载“可自证的面包屑错误轨迹”，我们将高度解耦带来的难以追踪的调试负担彻底抹平。业务开发者极度享受 API 的优雅，而测试与线上排障团队也极度享受它带来的精准报错信息，大幅降低了团队引入这套超媒体架构的心智门槛。

Graph View