错误边界不能自动捕获流式响应中的业务错误（如token耗尽），仅能捕获子组件render、构造函数及生命周期方法中的同步javascript异常；需在流解析时显式throw才能触发，须配合拦截器、前置校验等分层防御。
错误边界（Error Boundary）在 JavaScript 异步流中**不能自动生效**——它不捕获流式响应中的业务错误（比如 Token 耗尽、后端返回的 {"code": "TOKEN_EXPIRED"}），也不处理 fetch 或 ReadableStream 读取过程中的异常，除非你主动把它“转化”成组件内可捕获的同步错误。
错误边界真正能捕获什么
它只对以下三类错误起作用：
- 子组件 render 函数 中抛出的异常（如访问 undefined 属性）
- 子组件 constructor 或 getDerivedStateFromError 等生命周期方法中抛出的异常
- 子组件树中任意位置 同步执行路径 上的
throw new Error()
而流式请求中常见的 reader.read() 返回值判断、response.body.getReader() 的调用、Promise resolve/reject、SSE event listener 内部错误——这些都属于异步或事件驱动逻辑，错误边界默认无视。
让错误边界介入流式错误的关键动作
必须在数据消费环节做显式判断，并立即 throw：
- 用
response.body.getReader()获取 reader 后，在每次await reader.read()后解析result.value - 若解析出
code === "TOKEN_EXPIRED"或status === 401，立刻throw new Error("Token expired") - 这个
throw必须发生在被错误边界包裹的组件内部（如useEffect的同步执行块、自定义 Hook 的顶层逻辑），否则不会触发componentDidCatch
例如：在 useEffect 中启动流读取，并在解析每一块 chunk 时校验业务状态；一旦发现失效 token，同步 throw，错误边界就能捕获并切换 fallback UI。
更实用的分层防御组合
单靠错误边界兜底风险高，推荐搭配使用：
-
HTTP 拦截器优先拦截：用
axios.interceptors.response或fetch包装函数统一处理 401/403，直接刷新 token，避免错误流入 React 渲染层 -
流请求前本地校验：读取 JWT 的
exp字段，提前拒绝已过期或即将过期（如剩余 -
服务端返回结构统一：所有业务错误都走标准字段（如
code、message、data），方便前端统一识别 -
错误边界 + 状态联动：捕获后不只渲染提示，还调用
onTokenExpired()触发刷新，并用 context/ref 通知重试，保持流程连贯
为什么不能依赖错误边界单独处理流错误
因为流错误本质是响应数据语义层面的问题，不是 JS 运行时崩溃。错误边界的设计目标是防止 UI 树崩塌，而不是替代网络层或业务逻辑层的错误判定。把它当作最后一道防线，而不是第一道闸门。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
