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，而是请求失败时用户是否知道发生了什么、开发者能否三秒定位问题、换域名时改几处就能上线。
