关键是要将业务错误码（如{code:40102,msg:"登录已过期"}）纳入统一拦截体系，通过自定义错误类、请求层识别、拦截器分类响应及调用链上下文保障实现。
要实现支持业务错误码的统一拦截，关键不是只捕获网络或语法错误，而是把后端返回的业务态异常（比如 { code: 40102, msg: "登录已过期" }）也纳入可识别、可分类、可响应的错误体系中。
定义语义化业务错误类
创建继承自 Error 的自定义错误类，携带 code、msg、data 等字段，便于后续判断和处理：
- 区分错误类型：用
code标识业务含义（如40100表示未登录，40301表示权限不足） - 保留原始响应：将完整 response body 或 parsed data 挂在 error 实例上，供拦截器或 UI 层使用
- 避免魔数：所有业务码建议集中管理为常量对象，例如
BIZ_CODE.UNAUTHORIZED
在请求层完成业务错误识别与抛出
fetch 封装函数中，在 JSON 解析成功后立即检查响应体结构，按约定字段触发业务错误：
- 假设后端统一返回
{ code: number, msg: string, data: any } - 若
code !== 200（或不在合法范围），构造业务错误并throw - 注意：不要在
.catch()中吞掉这个 throw，要让它冒泡到拦截器或调用点
配置错误拦截器做统一响应
在请求库的 error interceptor 中，根据错误实例类型和 code 值执行差异化逻辑：
- 网络/超时错误：提示“网络异常，请重试”
-
code === 401或40100：清空 token，跳转登录页 -
code === 403：弹窗提示“权限不足”，不刷新页面 - 其他业务码：默认 toast 提示
error.msg，或交由组件自行处理
确保调用链不丢失业务错误上下文
避免在 async 函数中漏掉 await 或忽略 catch 后的 re-throw：
- 每个
await request.get(...)都应处于 try-catch 内，或被外层错误边界捕获 - 不要写
request.get().then(...).catch(...)链式调用，容易遗漏中间 Promise 的 reject - 推荐统一用
async/await + 拦截器，让业务错误自然进入 error interceptor 流程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
