JavaScript接口异常处理需统一捕获、解析响应体并分类：先用try/catch捕获Promise拒绝，再检查HTTP状态码与业务code；建立错误码映射表，区分网络异常、业务错误和系统异常；配合超时、重试、降级与上下文上报实现主动防御。
在 JavaScript 接口调用中处理服务器返回的未知异常，核心是**不依赖响应状态码做唯一判断，而是统一捕获错误、解析响应体、分类处理业务错误与网络异常**。
用 try/catch 包裹 await，捕获所有 Promise 拒绝
fetch 或 axios 返回的是 Promise，未手动 catch 时，未处理的拒绝会变成 unhandledrejection。即使 HTTP 状态码是 200，后端也可能返回 { code: 500, message: "数据库连接失败" } 这类业务异常，它不会触发 catch —— 所以不能只靠 catch 网络层错误。
正确做法是：无论状态码如何，都检查响应体中的业务字段（如 code、success、error）。
- fetch 场景下，先用 response.ok 判断 HTTP 是否成功（即 200–299），再用 response.json() 解析，之后再检查业务 code
- axios 默认对非 2xx 状态码抛错，但建议关闭该行为（validateStatus: () => true），自己统一判断，避免遗漏 4xx/5xx 中携带有效业务信息的响应
- 不要写
catch(err) { console.error(err) }就完事，要区分 err 是网络中断、超时、CORS 失败，还是后端返回了 { code: 1001 } 的结构化错误
统一响应结构 + 错误映射表，把“未知”变“可知”
后端应尽量约定标准响应格式，例如：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
{
"code": 0, // 0=成功，非0=失败
"message": "ok",
"data": { ... }
}
前端可建立一个错误码映射表：
- code === 0：走正常逻辑
- code 在预定义范围内（如 1001, 2003）：提示对应中文消息，或跳转特定页面
- code 为未知值（如 9999）或无 code 字段：归为“系统异常”，显示兜底提示（如“服务暂时不可用，请稍后重试”），并上报错误日志
- 若响应根本不是 JSON（如返回 HTML 错误页、空响应、超时中断），则视为网络或服务端严重故障，同样走兜底流程
主动防御：加超时、节流、重试、离线降级
未知异常常出现在弱网、服务抖动场景，仅靠错误提示不够，需前置干预：
- fetch 加 AbortController 实现请求超时（如 8s 后自动 abort）
- 对非幂等请求（如 POST）禁用自动重试；对查询类接口可配置最多 1 次重试，间隔 1s
- 关键接口（如登录、提交订单）失败时，允许用户点击“重试”，而非静默失败
- 有缓存或本地数据时，可先渲染旧数据（stale-while-revalidate），再拉新数据，提升感知可用性
记录上下文，方便定位“未知”从哪来
当捕获到无法识别的异常时，不要只打 console.error，要带上关键上下文上报：
- 请求 URL、method、timestamp
- 原始响应状态码、headers（特别是 X-Request-ID）、响应体截断（防敏感信息）
- 用户设备、浏览器、网络类型（navigator.onLine + effectiveType）
- 当前页面路径、用户是否已登录、是否有未保存的表单数据
这些信息能快速区分是偶发网络问题、CDN 故障、还是某次发布引入的新错误码。
