ofetch同构请求

要解决什么问题

在 Nuxt/SSR 项目里，请求代码经常被复制成两份：一份跑在浏览器，一份跑在 Node 服务端，两边的 baseURL、Header、错误处理逻辑稍有不同，就会出现“前端正常、SSR 报错”的隐蔽 bug。本技能围绕 ofetch 封装一套同构请求层，浏览器、Node、Workers 共用同一份 API，体验对齐 Nuxt 的 $fetch。它解决三个具体痛点：

• 请求层重复：前后端各写一套 fetch/axios 封装，逻辑随时间漂移；
• 错误处理不统一：非 2xx 响应没人管，JSON 解析全靠手动；
• 鉴权注入混乱：Token 写死在源码里，或被拦截器整条吐出来。

核心能力与工作方式

技能导出单例 createOfetchClient，内部完成三件事：

• Token 注入：Token 从安全存储或 getToken 注入，由拦截器统一附加，禁止写死密钥；
• 类型化方法：提供 apiGet（列表）与 apiPost（保存）两组封装，返回值类型可推导；
• 错误策略：默认对 4xx/5xx 抛错，业务 code 交给调用层再判；重试优先幂等 GET，POST 慎开高次数。

实施时的关键步骤是：创建客户端单例 → 定义 get/post 封装 → 捕获错误时读取 error.data → 自测覆盖无 token、超时、Node 脚本同构跑通三类场景。实现要点会标注 小四原创。

适用边界

这套封装的定位是“同构一份 API”，因此：

• 纯浏览器极简场景不必上它，继续用 Ky 这类薄封装更合适；若两者并存，规则是同构/SSR → ofetch，浏览器薄封装 → ky；
• 不要在拦截器里打印完整 Authorization，调试请用脱敏字段；
• 不要为“兼容”同时接 ofetch 与 axios 双栈，行为不一致的代价远高于迁移成本。