MSW.js 中请求体不可用问题的分析与解决

问题背景

在使用 MSW.js (Mock Service Worker) 进行前端测试时，开发人员经常会遇到需要验证请求体内容的情况。特别是在从 MSW v1.3.4 迁移到 v2.4.11 的过程中，一个常见的问题是在异步请求处理器中尝试检查请求体内容时会遇到 TypeError: Body is unusable 错误。

问题现象

当开发人员尝试通过生命周期事件监听器来检查请求体内容时，如果请求处理器是异步的，就会出现请求体不可用的错误。而在同步处理器中，相同的检查却能正常工作。这种不一致的行为让开发者感到困惑。

技术原理

这个问题的根源在于 Fetch API 的 Request 对象设计。根据 Fetch 规范，Request 对象的 body 是一个可读流(ReadableStream)，而流的特点是只能被消费一次。一旦 body 被读取(例如通过 .json() 方法)，流就会被标记为"已消费"，后续任何尝试再次读取的操作都会抛出"Body is unusable"错误。

在 MSW 的上下文中，当请求处理器是异步的，MSW 内部会先尝试读取请求体，然后才将控制权交给开发者的事件监听器。这时开发者再次尝试读取已经被消费过的请求体，自然就会遇到错误。

解决方案

方法一：使用 clone() 方法

最直接的解决方案是在需要读取请求体的地方，先对 Request 对象进行克隆：

const payload = await request.clone().json()

clone() 方法会创建一个新的 Request 实例，包含原始请求的所有数据，包括未被消费的 body 流。这样就可以安全地多次读取请求体内容。

方法二：在请求处理器中直接验证

更推荐的做法是将请求体验证逻辑直接放在请求处理器内部，而不是通过事件监听器：

rest.post('/api/deploy', async (req, res, ctx) => {
  const payload = await req.json()
  // 直接在这里验证 payload
  return res(ctx.json({ success: true }))
})

这种方法更加直观，也避免了请求体被多次读取的问题。

最佳实践

1. 避免多次读取请求体：在测试中，如果需要多次访问请求体内容，应该使用 clone() 方法或缓存第一次读取的结果。

2. 优先在处理器内验证：将验证逻辑放在请求处理器内部通常更清晰，也更容易维护。

3. 注意异步处理器的特殊性：了解异步处理器与同步处理器的行为差异，特别是在请求体处理方面。

4. 考虑使用辅助函数：可以创建封装好的测试辅助函数来处理请求体验证，确保每次都正确使用 clone()。

总结

理解 Fetch API 中 Request 对象的设计原理是解决这类问题的关键。通过正确使用 clone() 方法或调整测试逻辑的组织方式，可以有效地避免"Body is unusable"错误。在 MSW 测试中，合理设计请求体验证的策略，既能保证测试的准确性，又能提高代码的可维护性。