fetch本质是Promise封装的网络请求接口，核心逻辑为「发起→处理响应→错误分流」：URL必填、Options可选但常用、返回Promise需链式解析；响应处理分两层Promise链，res.ok判状态、.json()等方法再解析；错误需三层分流：网络层reject、HTTP异常手动throw、解析失败单独catch；进阶支持AbortController取消、Promise.race超时、async/await封装。
直接画思维导图不靠“背概念”，而要抓住 fetch 的行为逻辑主线：它本质是 Promise 封装的网络请求接口，核心围绕「发起 → 处理响应 → 错误分流」展开。下面按实用维度分层梳理，方便你用 XMind / MindNode 等工具结构化呈现：
一、基础调用结构（必写三要素）
每个 fetch 调用都隐含三个关键部分，缺一不可：
- URL（必需）：字符串或 Request 实例，支持相对路径（同源）和绝对 URL；注意跨域时需服务端配合 CORS 或使用代理
- Options 对象（可选但常用）：包含 method、headers、body、credentials（如 'include' 传 cookie）、cache、redirect 等字段；body 只对 POST/PUT 等方法有效，且需匹配 Content-Type（如 JSON 需 JSON.stringify + 设置 header）
-
返回值（Promise
） ：不是 Promise，而是 Promise；Response 是流式可读对象，需显式调用 .json() / .text() / .blob() 等方法解析，这些方法也返回 Promise
二、响应处理的两层 Promise 链（易错点集中区）
fetch 不因 HTTP 状态码（如 404、500）reject，只在网络失败（断网、DNS 失败、跨域被拦）时 reject —— 这是和 axios 最大区别：
- 第一层 .then(res => { ... })：拿到 Response 对象后，先检查 res.ok（等价于 status in [200, 299]）或 res.status 判断业务状态
- 第二层必须链式调用解析方法：res.json().then(data => ...)，且该解析过程可能失败（如返回非 JSON 文本），需单独 catch
- 典型错误写法：
fetch(...).then(res => res.json()).catch(...)—— 这里 catch 同时捕获网络错误和 JSON 解析错误，难以区分原因
三、错误处理的合理分流策略
建议三层分离处理，让调试更清晰：
- 网络层错误：fetch() 返回的 Promise reject → 用最外层 .catch() 捕获（如“请检查网络”）
- HTTP 状态异常：在第一个 .then 中 if (!res.ok) throw new Error(`${res.status} ${res.statusText}`) → 被同一个 .catch 或后续 .catch 捕获
- 响应体解析失败：res.json() 等方法的 Promise reject → 单独在解析链上 .catch()（如“服务器返回了非预期格式”）
四、进阶控制与常见搭配
实际项目中常需扩展能力，这些不是语法必需，但属于高频实践：
- 取消请求：通过 AbortController.signal 传入 options.signal，调用 controller.abort() 可中断未完成请求（注意：已发出的请求无法撤回，只是终止 Promise）
- 超时控制：fetch 本身无 timeout 参数，需结合 Promise.race() 包裹 fetch 和 setTimeout Promise
- 与 async/await 结合：更线性地表达流程，但记得 try/catch 仍需覆盖网络错误 + 状态校验 + 解析错误三层
- 封装建议：统一处理默认 headers、base URL、token 注入、全局 loading 状态；避免裸用 fetch
思维导图主干建议按「调用结构 → 响应流程 → 错误分类 → 扩展能力」四级展开，每个分支下用关键词+简短说明（如「res.ok：判断 2xx 状态，非网络连通性」），避免堆砌代码。重点标红「Response 不是数据」「.json() 返回新 Promise」「404 不触发 catch」这三点，基本就覆盖 80% 的踩坑场景。
