javaScript调用rest api应使用fetch+async/await,手动检查response.ok或status,try/catch捕获异常;封装apiClient统一处理Token、序列化、超时及错误;ui需响应加载、错误、空状态;URL应常量化管理。

javascript 调用 REST API 的核心是使用 fetch(现代推荐)或 XMLhttpRequest(旧式),但关键不在“能不能发”,而在“怎么发得稳、可维护、易调试、防出错”。以下聚焦实用、落地的最佳实践。
用 fetch + async/await 写清晰可读的请求逻辑
避免嵌套 .then(),统一用 async/await 处理异步流。注意:fetch 默认不拒绝 4xx/5xx 状态码,需手动判断:
- 检查
response.ok(等价于 status 在 200–299) - 用
response.status做细粒度错误分支(如 401 跳登录,404 提示资源不存在) - 始终用
try/catch包裹 await 表达式,捕获网络失败、jsON 解析异常等
封装通用请求函数,收敛配置和错误处理
不要每个组件都写一遍 fetch(url, {...})。抽一个 apiClient:
- 默认加
Content-Type: application/json和认证 token(从 localStorage 或 context 读) - 自动序列化
body(若传对象则JSON.stringify) - 统一超时控制(可用
AbortController) - 对常见错误码返回结构化错误对象(如
{ code: 'NETWORK_ERROR', message: '请求超时' })
正确处理加载、错误、空状态,别只写 success 分支
真实 UI 必须响应三种状态:
立即学习“Java免费学习笔记(深入)”;
- 加载中:显示 skeleton 或 loading 按钮,禁用重复提交
- 失败:区分网络错误、服务异常、业务校验失败,给用户可操作提示(如“重试”按钮)
- 空数据:比如列表接口返回
[],要明确展示“暂无内容”,而非留白或报错
避免硬编码 URL 和魔数,用常量或配置管理端点
把 API 地址从代码里提出来,好处明显:
- 环境切换方便(开发用
http://localhost:3000/api,生产用https://api.example.com) - URL 拼接不易出错(用
new URL(base, path)或模板字符串) - 接口变更时全局搜索修改,不漏掉某个
fetch('/v1/users/...')
基本上就这些。不复杂但容易忽略——真正拉开差距的,不是会不会调 API,而是请求失败时用户是否知道发生了什么、开发者能否三秒定位问题、换域名时改几处就能上线。