fetch API封装的必要性
在前端开发中，与后端api进行交互是常见任务。fetch api是现代浏览器提供的强大网络请求工具，但其默认行为在错误处理方面可能不够直观。例如，fetch在接收到http 4xx或5xx状态码时并不会抛出错误，而是将其视为成功的响应，需要开发者手动检查response.ok属性。此外，网络故障、请求配置错误等情况则会直接导致promise被拒绝。为了提升代码的可读性、可维护性和健壮性，通常需要对fetch进行一层封装，统一处理各种成功与失败场景，并提供清晰的返回值或错误信息。
利用async/await简化异步操作
async/await语法是处理Promise的强大工具，它允许我们以同步的方式编写异步代码，极大地提高了代码的可读性。在封装fetch时，async/await能帮助我们更优雅地处理Promise链，避免回调地狱，并方便地使用try...catch结构捕获错误。
一个基本的fetch调用通常如下：
async function myFetch(url, options) {
// 假设这是对fetch的直接调用或一个更底层的封装
return fetch(url, options);
}我们的目标是创建一个callApi函数，它能封装myFetch的调用，并根据业务需求返回特定格式的数据或错误。
处理文本响应的封装策略
当API预期返回纯文本内容时，我们需要使用response.text()方法来获取响应体。值得注意的是，response.text()本身也返回一个Promise，因此需要await等待其解析。
我们将探讨两种主要的错误处理策略：
策略一：始终解决（Resolve），通过返回值指示状态
这种策略的优点是调用者总是会收到一个Promise的解决结果，无需在调用链中使用catch。但缺点是调用者必须检查返回对象中的ok或error字段来判断请求是否成功。
/**
* 封装API调用，处理文本响应。
* 总是解决Promise，通过返回对象中的属性指示成功或失败。
* @param {string} url - 请求URL
* @param {object} options - fetch请求选项
* @returns {Promise策略二：失败时拒绝（Reject）Promise
这种策略更符合Promise的惯用模式，即成功时解决，失败时拒绝。调用者可以使用try...catch或.catch()来捕获错误。
/**
* 封装API调用，处理文本响应。
* 成功时解决Promise并返回响应体，失败时拒绝Promise并抛出错误信息。
* @param {string} url - 请求URL
* @param {object} options - fetch请求选项
* @returns {Promise} 成功时返回响应文本，失败时拒绝Promise
* @throws {string|Error} 失败时抛出错误信息
*/
async function callApiForTextRejectOnFailure(url, options) {
try {
const response = await myFetch(url, options);
const body = await response.text(); // 等待文本内容解析
if (!response.ok) {
// HTTP状态码非2xx，抛出错误
throw `${response.status}: ${body}`;
}
return body; // 成功时返回文本内容
} catch (e) {
// 网络错误、请求配置错误或上一步抛出的HTTP错误
// 如果是自定义的HTTP错误字符串，直接抛出；否则包装为Error对象
if (typeof e === 'string') {
throw e;
}
throw e.message || "网络请求失败";
}
}
// 示例调用
async function fetchDataWithReject() {
try {
const data = await callApiForTextRejectOnFailure('/api/data', { method: 'GET' });
console.log('数据获取成功:', data);
} catch (error) {
console.error('数据获取失败:', error);
// 根据错误类型做进一步处理
}
} 处理JSON响应的封装策略
当API预期返回JSON格式的数据时，我们需要使用response.json()方法。与response.text()类似，response.json()也返回一个Promise，需要await等待其解析。
策略一：始终解决，返回结构化数据
此策略与文本响应的“始终解决”类似，但body字段将包含解析后的JSON对象。
/**
* 封装API调用，处理JSON响应。
* 总是解决Promise，通过返回对象中的属性指示成功或失败。
* @param {string} url - 请求URL
* @param {object} options - fetch请求选项
* @returns {Promise策略二：失败时拒绝Promise，抛出结构化错误
此策略在失败时拒绝Promise，并抛出一个包含status、body和error信息的结构化错误对象，以便调用者能更细致地处理不同类型的错误。
/**
* 封装API调用，处理JSON响应。
* 成功时解决Promise并返回JSON对象，失败时拒绝Promise并抛出结构化错误对象。
* @param {string} url - 请求URL
* @param {object} options - fetch请求选项
* @returns {Promise错误类型与信息构建
在上述封装中，我们处理了两种主要类型的错误：
- 网络错误或请求配置错误：这通常发生在fetch请求发送之前或传输过程中，例如断网、URL错误、CORS策略阻断等。这些错误会被try...catch块直接捕获。在这种情况下，response对象将不会被创建。
- HTTP非2xx状态码：fetch成功接收到服务器响应，但响应的HTTP状态码（如404 Not Found, 500 Internal Server Error）表示业务逻辑上的失败。这种情况下，response对象是存在的，我们需要检查response.ok属性（response.ok为true表示状态码在200-299之间）来判断。
在构建错误信息时，建议提供足够的信息，如HTTP状态码、服务器返回的错误体（无论是JSON对象还是文本），以及一个清晰的错误描述。对于需要拒绝Promise的策略，抛出结构化错误对象比抛出简单的字符串更有利于调用者进行精细的错误处理。
总结与最佳实践
- 避免冗余的new Promise：fetch本身就返回一个Promise。不应再用new Promise去包裹一个已经返回Promise的函数，这会增加不必要的复杂性。
- 充分利用async/await：它能极大地简化异步代码的编写，使错误处理更加直观。
- 正确处理response.text()和response.json()：它们都返回Promise，务必使用await等待其解析。
- 明确错误处理策略：根据项目需求选择“始终解决并返回状态对象”或“失败时拒绝Promise”。前者适用于需要统一处理所有结果的场景，后者更符合Promise的错误传播机制。
- 提供详细的错误信息：无论是通过返回对象还是拒绝Promise，都应包含足够的信息（如HTTP状态码、响应体、错误消息）以便于调试和用户反馈。
- 考虑自定义错误类：对于更复杂的应用，可以定义自定义错误类（例如HttpError, NetworkError），以便在catch块中通过instanceof进行类型判断，实现更精细的错误处理。
- 配置请求头和认证：在实际应用中，callApi函数还需要处理请求头（如Content-Type, Authorization）和认证逻辑。
通过上述封装，我们可以构建一个既健壮又易于使用的fetch API调用模块，从而提高整个应用的网络请求可靠性。
