MSW.js 浏览器测试中请求拦截失效问题分析与解决方案

问题背景

在使用 MSW.js 进行浏览器端测试时，开发者遇到了一个棘手的问题：当测试代码中包含 vi.mock 语句时，MSW 的请求拦截功能会失效。这个问题主要出现在 Vitest 的浏览器测试模式下，导致原本应该被拦截的请求仍然发送到了真实服务器，从而引发测试失败。

问题现象

开发者们报告了以下典型现象：

1. 请求虽然匹配到了 MSW 的 handler，但最终没有被正确拦截
2. 控制台出现警告信息："intercepted a request without a matching request handler"
3. 测试过程中出现网络错误或 CORS 错误
4. 当移除 vi.mock 语句后，拦截功能恢复正常

根本原因

经过深入分析，发现问题的根源在于 Vitest 和 MSW 的交互机制：

1. Vitest 在浏览器模式下使用 MSW 作为底层实现来处理 vi.mock 功能
2. 当测试代码中包含 vi.mock 时，Vitest 会初始化自己的 MSW worker 实例
3. 这个内部 worker 会优先处理请求，导致开发者自定义的 handler 被跳过
4. Vitest 的 worker 会为未匹配的请求创建 passthrough Response，导致请求继续发送到真实服务器

解决方案

临时解决方案

在 Vitest 修复此问题前，开发者可以采用以下临时方案：

1. 使用模块别名替代 mock：通过 Vitest 配置中的 alias 功能来替换需要 mock 的模块

// vite.config.js
export default defineConfig({
  test: {
    alias: [
      {
        find: "$src/my/module",
        replacement: resolve(import.meta.dirname, "test/mocks/my/module"),
      },
    ],
  },
});

2. 避免在浏览器测试中使用 vi.mock：考虑重构测试代码，使用其他 mock 方式

3. 确保 worker 正确初始化：在测试 setup 中显式等待 worker 启动

beforeAll(async () => {
  await worker.start();
});

永久解决方案

此问题已在 Vitest 3.1.0 版本中修复。升级到最新版本 Vitest 可以彻底解决这个问题。

最佳实践

为了避免类似问题，建议开发者：

1. 始终检查 MSW worker 是否已正确启动
2. 在测试中打印 worker.handlersController.currentHandlers() 来验证 handler 是否注册成功
3. 对于复杂的测试场景，考虑将浏览器测试和 Node 测试分开
4. 保持 MSW 和测试框架(Vitest)的版本更新

技术深度解析

这个问题揭示了前端测试工具链中一个重要的设计考量：工具间的协作机制。当两个工具都使用相同的底层技术(如 MSW)时，需要明确的协作协议来避免冲突。Vitest 的修复正是通过改进这种协作机制来实现的。

对于前端开发者而言，理解测试工具的工作原理非常重要。MSW 作为请求拦截层，其工作方式类似于中间件服务，而 Vitest 的模块 mock 功能也需要类似的机制。当两者同时存在时，必须有明确的优先级和协作规则。