fetch-mock：声明式HTTP请求模拟库，前端测试与开发的终极利器

1. 项目概述：为什么我们需要一个“终极”的HTTP请求模拟工具？

在前后端分离、微服务架构大行其道的今天，前端开发、后端测试、接口联调，几乎每一个环节都离不开HTTP请求。但现实往往是骨感的：你正兴致勃勃地开发一个前端功能，后端接口还没开发完；或者你正在编写一个后端服务的单元测试，它依赖的另一个服务却极不稳定，动不动就给你来个“502 Bad Gateway”。这时候，一个可靠的HTTP请求模拟工具，就成了开发流程中的“定海神针”。

你可能用过 Postman 来手动模拟请求，或者在 Node.js 里用node-fetch配合jest的jest.mock来笨拙地模拟。但这些方法要么是手动操作，无法集成到自动化流程中；要么就是配置繁琐，难以模拟复杂的请求-响应场景，比如网络延迟、特定状态码、甚至是请求失败的重试逻辑。而fetch-mock，正是为了解决这些痛点而生的。它不是一个简单的“假接口”，而是一个功能强大、配置灵活、能与现代前端测试框架（如 Jest、Mocha）无缝集成的声明式HTTP请求模拟库。它的核心思想是：在测试环境中，完全接管全局的fetch函数，让你可以精确地定义当某个URL被请求时，应该返回什么响应，从而将测试环境与真实网络环境彻底解耦。

简单来说，fetch-mock让你能像搭积木一样，构建出一个完全可控的“虚拟网络”，在这个网络里，你可以为所欲为：让某个接口瞬间成功、立刻失败、延迟响应，或者返回任何你想要的JSON、文本甚至二进制数据。这对于编写健壮的单元测试、集成测试，以及前端在没有后端支持下的独立开发，价值巨大。接下来，我们就从零开始，彻底掌握这个“终极工具”。

2. 核心概念与设计哲学：不仅仅是“模拟”

在深入代码之前，理解fetch-mock的设计哲学至关重要。这能帮助你在遇到复杂场景时，知道该如何思考，而不是机械地复制代码。

2.1 全局接管与沙盒模式

fetch-mock最核心的能力是全局接管fetch。在引入并配置后，你代码中所有通过fetch发起的请求，都会被fetch-mock拦截，并根据你预先定义的规则（我们称之为“模拟”或“mock”）返回响应，而不会真正地发送网络请求。

注意：这种全局接管是“侵入式”的。这意味着在你的测试文件或模拟环境中，fetch已经不是浏览器原生的那个fetch了。因此，务必在每次测试结束后清理模拟规则，否则模拟规则会污染后续测试，导致难以调试的诡异错误。fetch-mock提供了fetchMock.reset()和fetchMock.restore()等方法来确保测试的隔离性。

2.2 声明式配置：匹配器（Matcher）与响应器（Response）

fetch-mock的配置是声明式的，主要由两部分组成：

1. 匹配器（Matcher）：定义“什么样的请求”会被拦截。这可以是一个简单的字符串（精确匹配URL），一个正则表达式（匹配一类URL），或者一个函数（进行更复杂的逻辑判断，比如检查请求头或请求体）。
2. 响应器（Response）：定义被拦截的请求应该“返回什么样的响应”。这可以是一个状态码（如200, 404, 502）、一个JSON对象、一段文本、一个Response对象，甚至是一个抛出错误的Promise（用于模拟网络异常）。

这种“请求-响应”的映射关系，使得模拟逻辑非常清晰。例如，你可以声明：“所有向/api/users发起的GET请求，都返回一个200状态码和用户列表JSON；而向同一个地址的POST请求，则返回201状态码和新创建的用户数据。”

2.3 为什么是“终极”？对比其他方案

让我们快速对比一下常见的HTTP模拟方案，你就能明白fetch-mock的优势所在：

实操心得：在我的项目中，fetch-mock主要用于Vue/React 组件测试和Node.js 服务层单元测试。在组件测试中，我可以确保组件发出的每个API请求都在掌控之中，从而专注于测试组件自身的渲染逻辑和交互行为，测试用例运行速度极快且100%稳定。在Node.js服务测试中，当我的服务需要调用外部API时，用fetch-mock模拟外部API的各种响应（包括5xx错误），能完美测试我服务的错误处理和重试逻辑。

3. 从零开始：安装与基础配置

理论说再多，不如动手试。我们从一个最简单的例子开始。

3.1 安装

假设你正在一个基于 Jest 的现代前端项目（比如使用 Create React App 或 Vite）中工作。首先，通过 npm 或 yarn 安装fetch-mock：

# 使用 npm npm install --save-dev fetch-mock # 使用 yarn yarn add --dev fetch-mock

3.2 第一个模拟：模拟一个成功的GET请求

假设我们有一个getUser函数，它使用fetch获取用户信息。

// api.js export async function getUser(userId) { const response = await fetch(`/api/users/${userId}`); if (!response.ok) { throw new Error(`HTTP error! status: ${response.status}`); } return await response.json(); }

现在，我们要为这个函数写一个测试，并且不希望测试真的去请求网络。

// api.test.js import fetchMock from 'fetch-mock'; import { getUser } from './api.js'; describe('getUser', () => { // 在每个测试用例运行后，重置fetchMock的状态，防止模拟规则交叉影响 afterEach(() => { fetchMock.reset(); }); it('should fetch user data successfully', async () => { // 1. 定义模拟规则：匹配URL，并返回模拟响应 const mockUserId = 123; const mockUser = { id: mockUserId, name: 'John Doe', email: 'john@example.com' }; fetchMock.get(`/api/users/${mockUserId}`, { status: 200, body: mockUser, }); // 2. 执行被测试的函数 const userData = await getUser(mockUserId); // 3. 断言函数返回了正确的数据 expect(userData).toEqual(mockUser); // 4. (可选) 断言fetch确实以预期的参数被调用了一次 expect(fetchMock.called(`/api/users/${mockUserId}`)).toBe(true); // 也可以检查调用详情 const lastCall = fetchMock.lastCall(`/api/users/${mockUserId}`); expect(lastCall?.[0]).toBe(`/api/users/${mockUserId}`); // 请求URL expect(lastCall?.[1]?.method).toBe('GET'); // 请求方法 }); it('should throw an error when the response is not ok', async () => { const mockUserId = 999; // 模拟一个404 Not Found响应 fetchMock.get(`/api/users/${mockUserId}`, 404); // 断言函数抛出了错误 await expect(getUser(mockUserId)).rejects.toThrow('HTTP error! status: 404'); }); });

代码解读与注意事项：

• fetchMock.get(matcher, response)：这是一个快捷方法，专门用于模拟GET请求。同理还有.post(),.put(),.delete(),.patch()等。
• 匹配器（Matcher）：这里我们用了字符串精确匹配。fetch-mock会检查请求的URL是否完全等于这个字符串。
• 响应器（Response）：我们传递了一个对象{status: 200, body: mockUser}。status对应HTTP状态码，body是响应体，fetch-mock会自动将其序列化为JSON字符串（因为我们在body里放了对象）。
• fetchMock.reset()：这是生命线！它会在每个测试后清除所有已注册的模拟规则和调用记录。忘记调用它，是导致测试间相互干扰的最常见原因。
• fetchMock.called()和fetchMock.lastCall()：这些是间谍（Spy）功能。它们让你能验证fetch是否被调用、调用了多少次、以及调用时的参数是什么。这对于测试函数的行为（比如“是否发送了请求”）至关重要。

3.3 配置响应头与响应延迟

真实的网络请求往往带有响应头，并且可能有延迟。fetch-mock可以轻松模拟这些场景。

it('should handle response headers and delay', async () => { fetchMock.get('/api/slow-data', { status: 200, body: { data: 'some content' }, headers: { 'Content-Type': 'application/json', 'X-Custom-Header': 'MyValue', }, // 延迟2秒后返回响应，模拟网络延迟 delay: 2000, }); const startTime = Date.now(); const response = await fetch('/api/slow-data'); const endTime = Date.now(); const data = await response.json(); expect(data.data).toBe('some content'); expect(response.headers.get('X-Custom-Header')).toBe('MyValue'); // 验证延迟大致在2秒左右（允许一定误差） expect(endTime - startTime).toBeGreaterThanOrEqual(1900); });

实操心得：模拟延迟在测试UI交互时特别有用。比如，你可以测试一个“加载中”的旋转图标是否在请求发出时显示，并在收到响应后消失。这能确保你的加载状态管理逻辑是正确的。

4. 进阶匹配器：如何精准拦截你想要的请求

基础的字符串匹配往往不够用。fetch-mock提供了强大的匹配器系统，让你能进行模糊匹配、正则匹配甚至函数匹配。

4.1 正则表达式匹配

当你需要匹配一组具有共同模式的URL时，正则表达式是利器。

// 匹配所有以 `/api/posts/` 开头，后跟数字的URL fetchMock.get(/^\/api\/posts\/\d+$/, { body: { title: 'A Post' } }); // 这将匹配 await fetch('/api/posts/123'); await fetch('/api/posts/456'); // 这不会匹配 await fetch('/api/posts/abc'); // 不是数字 await fetch('/api/posts/'); // 缺少ID

4.2 函数匹配器：终极灵活性

当字符串和正则都无法满足你的需求时，你可以使用函数作为匹配器。这个函数接收两个参数：url（请求URL）和options（请求配置对象，如method,headers,body等）。函数需要返回true或false。

fetchMock.mock((url, options) => { // 只拦截POST请求，并且请求体包含特定字段的请求 return ( options.method === 'POST' && url === '/api/login' && options.body && JSON.parse(options.body).username === 'admin' ); }, { status: 200, body: { token: 'fake-jwt-token' } }); // 这个请求会被拦截 await fetch('/api/login', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ username: 'admin', password: '123' }) }); // 这个请求不会被拦截（用户名不对） await fetch('/api/login', { method: 'POST', body: JSON.stringify({ username: 'user', password: '123' }) });

4.3 基于方法的匹配

除了使用.get()、.post()这些快捷方法，你也可以在匹配器对象或函数中检查options.method。但更常见的做法是使用fetchMock.mock这个通用方法，并配合一个对象作为匹配器。

// 使用对象匹配器，可以同时匹配URL和方法 fetchMock.mock({ url: '/api/resource', method: 'PUT', // 甚至可以匹配请求头 headers: { 'Authorization': /^Bearer/ } }, { status: 204 // No Content });

避坑技巧：当你同时定义了多条模拟规则时，fetch-mock会按照定义的先后顺序进行匹配，并使用第一条匹配的规则。这意味着，你应该把最具体的规则放在前面，把最通用的规则（如兜底的“捕获所有”规则）放在最后。否则，通用规则可能会意外地拦截掉本该由特定规则处理的请求。

5. 模拟复杂场景与边缘情况

一个健壮的测试套件需要覆盖各种边缘情况，而不仅仅是“快乐路径”。fetch-mock让模拟这些场景变得简单。

5.1 模拟网络错误与异常状态码

模拟服务器错误（5xx）或客户端错误（4xx）是测试错误处理逻辑的关键。

// 模拟服务器内部错误 (500) fetchMock.get('/api/broken', 500); // 或提供更详细的错误响应 fetchMock.get('/api/broken', { status: 500, body: { error: 'Internal Server Error', message: 'Something went wrong.' } }); // 模拟未找到 (404) fetchMock.get('/api/not-found', 404); // 模拟认证失败 (401) fetchMock.get('/api/protected', { status: 401, headers: { 'WWW-Authenticate': 'Bearer realm="Access to protected resource"' } }); // 模拟网关错误 (502) - 这在微服务调用中很常见 fetchMock.get('/api/gateway', { status: 502, body: 'Bad Gateway' });

5.2 模拟超时与网络连接失败

有时你需要模拟fetch请求本身失败（例如网络断开），而不是服务器返回错误。这可以通过让模拟响应返回一个rejected Promise来实现。

import { RequestError } from 'fetch-mock'; // fetch-mock v9+ 可能需要 it('should handle network failure', async () => { // 模拟一个因网络原因失败的请求 fetchMock.get('/api/unreachable', { throws: new TypeError('Failed to fetch') // 浏览器原生fetch在网络错误时会抛出此类型错误 }); // 或者使用Promise.reject // fetchMock.get('/api/unreachable', Promise.reject(new Error('Network Error'))); await expect(fetch('/api/unreachable')).rejects.toThrow('Failed to fetch'); });

5.3 模拟动态响应与请求依赖

响应并不总是静态的。有时你需要根据请求的细节来动态生成响应。这可以通过将响应器定义为一个函数来实现。

// 模拟一个创建资源的POST请求，响应体应包含请求发送的数据和生成的ID fetchMock.post('/api/items', (url, options) => { // 解析请求体 const requestBody = JSON.parse(options.body); // 动态生成响应 return { status: 201, body: { id: Date.now(), // 模拟一个生成的ID ...requestBody, createdAt: new Date().toISOString() }, headers: { 'Location': `/api/items/${Date.now()}` // 模拟RESTful API创建后的Location头 } }; }); // 测试 const newItem = { name: 'New Item', price: 100 }; const response = await fetch('/api/items', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(newItem) }); const createdItem = await response.json(); expect(createdItem).toHaveProperty('id'); expect(createdItem.name).toBe(newItem.name); expect(response.status).toBe(201); expect(response.headers.get('Location')).toMatch(/\/api\/items\/\d+/);

实操心得：动态响应函数非常强大，可以用于模拟分页查询（根据page参数返回不同数据）、搜索接口（根据keyword过滤返回结果）等复杂场景。这能让你的测试更贴近真实接口的行为。

6. 集成到现代前端测试框架

fetch-mock本身是环境无关的，但要发挥最大威力，需要与你的测试框架（Jest, Vitest, Mocha等）和测试运行环境（Node.js, JSDOM）良好集成。

6.1 与 Jest / Vitest 集成

Jest 是目前最流行的测试框架。集成fetch-mock的关键在于正确设置和清理全局的fetch。

方案一：在每个测试文件中手动管理（推荐用于灵活性）这就是我们前面例子中的做法：在beforeEach/afterEach钩子中调用fetchMock.reset()和fetchMock.restore()。这是最清晰、最可控的方式。

import fetchMock from 'fetch-mock'; describe('My API tests', () => { beforeEach(() => { // 如果需要，可以在这里进行一些全局的模拟配置 }); afterEach(() => { // 清理！这是必须的。 fetchMock.reset(); fetchMock.restore(); }); // ... 你的测试用例 });

方案二：使用 Jest 的全局安装文件（Setup Files）如果你在大多数测试中都需要fetch-mock，可以将其配置为全局可用，并自动清理。

1. 在jest.config.js中设置setupFilesAfterEnv：

   // jest.config.js module.exports = { setupFilesAfterEnv: ['<rootDir>/jest.setup.js'], // ... 其他配置 };

2. 创建jest.setup.js文件：

   // jest.setup.js import fetchMock from 'fetch-mock'; // 确保在每个测试套件之前，fetch是干净的 beforeEach(() => { if (typeof global.fetch === 'undefined') { global.fetch = require('node-fetch'); // 在Node环境下，可能需要polyfill } fetchMock.reset(); fetchMock.restore(); }); afterEach(() => { fetchMock.reset(); fetchMock.restore(); }); // 将fetchMock挂载到全局，方便在测试中直接使用（可选） global.fetchMock = fetchMock;

   然后在测试文件中，你可以直接使用global.fetchMock或者仍然导入fetchMock。

重要提示：在 Node.js 环境中运行测试时，全局对象global上没有原生的fetch函数。你需要安装一个 polyfill，比如node-fetch，并在测试入口处将其赋值给global.fetch。Jest 27+ 版本在某些配置下可能自带了fetch，但为了保险起见，显式设置是个好习惯。

6.2 在组件测试中的应用（以React为例）

假设你有一个UserComponent，它在挂载时会调用getUserAPI。

// UserComponent.jsx import React, { useState, useEffect } from 'react'; import { getUser } from './api'; function UserComponent({ userId }) { const [user, setUser] = useState(null); const [loading, setLoading] = useState(true); const [error, setError] = useState(null); useEffect(() => { const fetchUser = async () => { setLoading(true); try { const data = await getUser(userId); setUser(data); setError(null); } catch (err) { setError(err.message); setUser(null); } finally { setLoading(false); } }; fetchUser(); }, [userId]); if (loading) return <div>Loading...</div>; if (error) return <div>Error: {error}</div>; return <div>Hello, {user.name}!</div>; }

使用@testing-library/react和fetch-mock来测试这个组件：

// UserComponent.test.jsx import React from 'react'; import { render, screen, waitFor } from '@testing-library/react'; import fetchMock from 'fetch-mock'; import UserComponent from './UserComponent'; describe('UserComponent', () => { afterEach(() => { fetchMock.reset(); }); it('renders user name after successful fetch', async () => { const mockUser = { id: 1, name: 'Alice' }; fetchMock.get('/api/users/1', { status: 200, body: mockUser }); render(<UserComponent userId={1} />); // 初始应该显示 Loading expect(screen.getByText('Loading...')).toBeInTheDocument(); // 等待异步操作完成，并断言最终渲染了用户名 await waitFor(() => { expect(screen.getByText(`Hello, ${mockUser.name}!`)).toBeInTheDocument(); }); // 确保Loading文本消失 expect(screen.queryByText('Loading...')).not.toBeInTheDocument(); }); it('renders error message on fetch failure', async () => { fetchMock.get('/api/users/2', 404); render(<UserComponent userId={2} />); await waitFor(() => { expect(screen.getByText(/Error:/)).toBeInTheDocument(); // 检查错误信息是否包含状态码 expect(screen.getByText('404')).toBeInTheDocument(); }); }); });

避坑技巧：在组件测试中，务必使用waitFor或findBy*查询来等待异步状态更新。直接断言会导致测试在组件完成渲染前就断言失败。@testing-library/react的findBy*查询内置了等待逻辑，用起来更简洁。

7. 高级特性与最佳实践

掌握了基础之后，我们来看看fetch-mock的一些高级特性和能让你事半功倍的最佳实践。

7.1 模拟连续调用与响应序列

有时，一个函数可能会多次调用同一个接口（比如重试逻辑），或者调用不同的接口。fetch-mock允许你为同一个匹配器定义一系列响应，它会按顺序返回。

// 模拟一个不稳定的接口：第一次失败，第二次成功 fetchMock.get('/api/unstable', [ { throws: new Error('Network Error') }, // 第一次调用返回错误 { status: 200, body: { data: 'success' } } // 第二次调用成功 ], { repeat: 2 } // 这个规则最多使用2次（即匹配列表中的两个响应） ); // 测试重试逻辑 async function fetchWithRetry(url, retries = 3) { for (let i = 0; i < retries; i++) { try { const response = await fetch(url); if (response.ok) return await response.json(); } catch (err) { if (i === retries - 1) throw err; // 等待片刻后重试 await new Promise(r => setTimeout(r, 100 * (i + 1))); } } throw new Error('Max retries reached'); } await expect(fetchWithRetry('/api/unstable', 2)).resolves.toEqual({ data: 'success' }); // 第一次调用会失败（模拟网络错误），函数会重试，第二次调用成功。

7.2 使用“Spy”模式进行行为验证

除了模拟响应，fetch-mock还是一个强大的间谍工具。你可以用它来验证函数是否按预期发起了请求。

it('should send correct authentication header', async () => { // 使用 `.spy()` 方法。它会放行请求到真正的网络（或你配置的底层实现），但同时记录调用信息。 // 更常见的做法是结合 `.mock()` 使用，因为我们需要控制响应。 // 这里我们用 `.mock` 并配合 `.called()` 等方法来验证。 fetchMock.mock('*', { status: 200 }); // 匹配所有请求，返回200 await fetch('/api/secure', { headers: { 'Authorization': 'Bearer my-token-123' } }); // 验证请求被调用 expect(fetchMock.called()).toBe(true); // 验证特定的URL被调用 expect(fetchMock.called('/api/secure')).toBe(true); // 获取最后一次调用的详细信息 const lastCallArgs = fetchMock.lastCall(); expect(lastCallArgs[0]).toBe('/api/secure'); // URL expect(lastCallArgs[1].headers.Authorization).toBe('Bearer my-token-123'); // 请求头 });

7.3 最佳实践总结

1. 隔离测试，及时清理：永远在afterEach（或afterAll）中调用fetchMock.reset()和fetchMock.restore()。这是保证测试独立性的第一原则。
2. 模拟要尽可能真实：模拟的响应状态码、头部、数据格式应尽量与真实API保持一致。这能发现更多集成问题。
3. 为错误场景编写测试：不要只测试成功路径。确保你的测试覆盖了4xx、5xx状态码、网络超时、JSON解析失败等异常情况。
4. 避免过度模拟：不要模拟那些与你当前测试单元无关的依赖。如果你的函数内部调用了另一个你完全控制的工具函数，也许应该直接测试那个工具函数，而不是通过fetch来模拟它。
5. 给模拟起个名字（在复杂场景下）：fetch-mock允许你为模拟规则命名（通过name属性），这在调试多条复杂规则时非常有用。
6. 谨慎使用通配符：fetchMock.mock('*', ...)会匹配所有请求，非常强大但也危险。确保它不会意外拦截你不想拦截的请求（比如测试框架内部发起的请求）。通常把它放在规则列表的最后作为兜底，或者仅在特定测试中使用。

8. 常见问题排查与调试技巧

即使掌握了所有功能，在实际使用中还是会遇到一些坑。这里记录了一些常见问题和解决方法。

8.1 问题：模拟没有生效，请求仍然发送到了网络

可能原因与解决方案：

1. fetch未被正确接管：确保你在调用被测试代码之前就已经调用了fetchMock.mock()等方法设置了模拟。检查你的测试代码顺序。
2. 引入了多个fetch实现：如果你的项目或测试环境中有多个fetch的 polyfill 或包装库，fetch-mock可能没有覆盖到实际使用的那个。确保fetch-mock是最后被引入并配置的。在 Jest 的setupFiles中尽早配置global.fetch = fetchMock.sandbox()有时能解决此问题。
3. 使用了fetchMock.restore()过早：restore()会恢复原生的fetch。确保它在测试结束后才被调用，而不是在测试中间。
4. 匹配器不匹配：仔细检查你的URL字符串、正则表达式或函数匹配器逻辑。一个多余的斜杠/或大小写问题都可能导致匹配失败。使用fetchMock.calls()打印出所有被拦截的请求记录，看看你的请求是否在其中。

// 调试：打印所有捕获到的请求 console.log(fetchMock.calls()); // 或者打印未匹配的请求 console.log(fetchMock.calls(false));

8.2 问题：测试因“Network Error”或“CORS Error”失败

可能原因：你的模拟规则没有覆盖到某个请求，导致请求“漏网”并真的尝试发送到网络。在测试环境中（如Jest的Node环境），没有真实的网络和域名，这会导致请求立即失败。

解决方案：添加一个兜底的、匹配所有请求的模拟规则，并让它返回一个明确的错误或警告，这样你就能立刻发现是哪个请求没有被正确模拟。

// 在测试文件的开头或setup文件中 beforeEach(() => { // 捕获所有未匹配的请求，并抛出清晰错误 fetchMock.catch((url, options) => { console.error(`Unmatched fetch request: ${options.method} ${url}`); // 返回一个错误响应，或者直接抛出错误 return { status: 500, body: `No mock defined for: ${url}` }; // 或者：throw new Error(`No mock defined for: ${url}`); }); });

8.3 问题：模拟的响应体格式不对，导致代码解析出错

可能原因：fetch-mock的body参数可以是多种类型。如果你传递一个对象，它会默认被序列化为JSON字符串，并自动设置Content-Type: application/json响应头。但如果你需要返回纯文本、FormData或ArrayBuffer，就需要手动处理。

解决方案：明确设置body和headers。

// 返回纯文本 fetchMock.get('/api/text', { status: 200, body: 'Plain text response', headers: { 'Content-Type': 'text/plain' } }); // 返回二进制数据 (如图片) fetchMock.get('/api/image', { status: 200, body: new ArrayBuffer(8), // 模拟一个小的二进制数据 headers: { 'Content-Type': 'image/png' } }); // 如果你的代码期望得到JSON，但模拟返回了字符串，就会解析失败。 // 错误示例： // fetchMock.get('/api/data', 'This is not JSON'); // 这会导致 response.json() 报错 // 正确示例： // fetchMock.get('/api/data', { body: { message: 'This is JSON' } });

8.4 与 TypeScript 一起使用

如果你使用 TypeScript，为了获得更好的类型提示，可以安装@types/fetch-mock。但请注意，fetch-mockv9 之后可能自带了类型定义。

npm install --save-dev @types/fetch-mock

在测试文件中，你可以获得完整的类型支持。一个常见的技巧是，将fetchMock的类型与你项目中使用的fetch类型对齐。

我个人在使用中，更喜欢在全局测试设置文件中创建一个类型安全的包装器或使用fetchMock.sandbox()，它能提供一个类型与原生fetch完全一致的模拟实例，集成起来更顺畅。

最后，记住fetch-mock的核心价值在于让测试变得确定、快速和独立。它把不可控的网络因素从你的测试方程式中移除，让你能专注于测试代码本身的逻辑。花时间设计好你的模拟，就像为你的代码搭建一个稳固的测试舞台，最终的回报是更快的测试运行速度、更少的脆弱测试用例以及面对复杂异步逻辑时那满满的信心。