使用Fetch API时，多次获取数据复用同一函数是否更优？

长期直接调用原生fetch的实际问题 #

• 原生fetch的设计存在容易踩的盲区：只有请求因网络中断、CORS拦截等完全没拿到服务端响应的情况，才会触发Promise的reject；只要服务端返回了404、500这类非成功状态，fetch都会走正常的then分支，需要手动判断response.ok，新手很容易漏掉这层校验，把错误响应当成正常数据处理。
• 重复代码冗余度极高：每个独立的请求调用都要重复写状态校验、数据格式解析、错误捕获的逻辑，项目规模变大后，零散的请求逻辑会带来极高的维护成本，后续要统一调整错误提示方式、加鉴权头的时候，需要逐个修改所有请求文件，效率极低。

你提供的示例封装的可取之处与可优化方向 #

已经符合通用封装逻辑的部分 #

• 主动增加了response.ok的状态校验，补上了原生fetch不会自动抛出HTTP错误的短板
• 用try/catch兜住了整个异步流程的异常，避免未捕获的Promise错误打乱页面运行逻辑

可调整的实用细节 #

• 当前封装硬编码了return await response.json()，仅能适配JSON格式的接口，如果后续需要拉取文本、二进制图片流等格式的资源，这个函数就无法复用，可以增加配置参数灵活指定返回解析格式
• 当前在catch块中直接alert(err)把错误处理逻辑写死在了工具函数里，实际业务场景往往需要差异化的错误交互（比如用轻量Toast提示、错误埋点上报、特定状态码跳转登录页），可以把捕获到的错误向上抛出，或者支持传入自定义错误回调
• 可以把公共请求配置（比如接口超时控制、统一鉴权token拼接、公共请求头设置）统一放在封装层处理，不用每个单独的请求重复传入配置

适合直接调用原生fetch的场景 #

只有临时验证的demo、一次性的小型脚本，总共就一两次请求且没有长期复用需求时，直接写原生fetch的代码量最少，不需要为了“规范”硬加封装增加无意义的代码复杂度。

内容的提问来源于stack exchange，提问作者Harsh Kulkarni