API是程序间约定的远程通信规则，需通过HTTP请求调用；fetch()是标准方法，须手动处理状态码、JSON解析及CORS等细节。
API 不是某个具体工具，而是程序之间约定好的“对话规则”；用 JavaScript 调用它，核心就是发送 HTTP 请求并处理响应，而不是调用本地函数。
什么是 API：别把它想成 JS 里的一个方法
API（Application Programming Interface）本质是一套远程服务暴露出来的通信契约——比如你访问 https://api.github.com/users/octocat，不是在运行某段 JS，而是在向 GitHub 的服务器发请求，它按约定返回 JSON 数据。浏览器里不能直接 require 或 import 一个 API，必须走网络。
常见误解：
- 把 API 当作像
Array.prototype.map那样的内置方法 - 以为不配 CORS 就能跨域读取任意接口（浏览器会直接拦截）
- 忽略状态码，只看
response.ok却不检查response.status === 404等具体错误
fetch() 是当前最稳妥的调用方式
fetch() 是现代浏览器原生支持的标准方法，比 XMLHttpRequest 更简洁，也比第三方库（如 axios）更轻量、无依赖。但它默认不带 cookie，且不会因 HTTP 错误状态码（如 400、500）自动 reject，这点必须手动处理。
立即学习“Java免费学习笔记（深入）”；
基础用法示例：
fetch('https://jsonplaceholder.typicode.com/posts/1')
.then(response => {
if (!response.ok) throw new Error(`HTTP error: ${response.status}`);
return response.json();
})
.then(data => console.log(data.title))
.catch(err => console.error('请求失败:', err.message));
关键点：
- 必须链式调用
response.json()（或response.text()）才能读取响应体，fetch()返回的Response对象本身不可直接打印 - 要显式判断
response.ok或检查response.status，否则 4xx/5xx 响应仍会进入then - 若需携带凭证（如登录态 cookie），得加
{ credentials: 'include' }选项
POST 请求要注意 Content-Type 和数据格式
发 POST 不等于把对象直接传进去。后端通常要求明确的 Content-Type 头和对应格式的请求体。
例如提交 JSON 数据：
fetch('https://httpbin.org/post', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name: 'Alice', age: 30 })
})
.then(r => r.json())
.then(data => console.log(data.json));
容易出错的地方：
- 漏写
headers导致后端收不到 JSON（默认是text/plain） - 忘记
JSON.stringify()，直接传对象，结果发出去的是[object Object] - 用
FormData上传文件时，不要手动设Content-Type，浏览器会自动生成带 boundary 的 multipart 头
CORS 报错不是代码问题，是服务端没授权
浏览器报 Blocked by CORS policy，说明请求已发出，但服务端响应头缺失 Access-Control-Allow-Origin。前端无法绕过，只能：
- 确认目标 API 是否本就支持跨域（如
https://jsonplaceholder.typicode.com是开放的） - 开发时用代理（如 vite 的
server.proxy或 webpack devServer 的proxy）把请求转到同源地址 - 后端加响应头，例如 Express 中：
res.header('Access-Control-Allow-Origin', '*') - 避免在生产环境硬编码代理，那只是开发阶段的权宜之计
真正难的从来不是怎么写 fetch，而是理解谁控制着响应头、谁决定数据结构、谁定义了错误码含义——这些都在 API 提供方那边。写调用代码前，先看清文档里 curl 示例和字段说明，比猛敲 JS 重要得多。
