MSW拦截fetch请求与openapi-fetch的兼容性问题分析

问题背景

在使用MSW(Mock Service Worker)进行API请求拦截测试时，开发者发现了一个有趣的现象：当使用原生fetch时，请求能够被正常拦截；但使用openapi-fetch库时，请求却绕过了MSW的拦截机制，直接发送到了真实服务器。

技术原理分析

这个问题的根源在于JavaScript的模块加载顺序和全局变量绑定机制。openapi-fetch库在初始化时会缓存全局的fetch函数：

fetch: baseFetch = globalThis.fetch

而MSW的工作原理是通过在server.listen()调用时覆盖全局的fetch方法来实现请求拦截。这就产生了一个关键的时间顺序问题：

1. 如果openapi-fetch在MSW初始化之前加载并缓存了原生fetch
2. 那么后续MSW对fetch的覆盖将不会影响到已经缓存的fetch引用

解决方案

针对这个问题，目前有以下几种解决方案：

1. 调整初始化顺序：确保在所有测试用例之前先调用server.listen()，然后再创建openapi-fetch客户端实例

2. 显式传递fetch参数：在创建openapi-fetch客户端时，显式传入当前环境的fetch方法

const client = createClient({
  baseUrl: 'https://example.com',
  fetch: window.fetch // 显式传递当前fetch
});

3. 使用MSW v1版本：有开发者反馈在MSW v1中不存在此问题，但这可能只是特定环境下的表现，不是通用解决方案

最佳实践建议

1. 在测试文件中，应该将MSW的初始化放在最前面
2. 考虑创建一个测试专用的openapi-fetch客户端工厂函数，确保正确的初始化顺序
3. 对于复杂项目，可以考虑编写一个测试工具函数来统一管理这些依赖关系

总结

这个问题很好地展示了JavaScript中全局变量和模块加载顺序的重要性。在实际开发中，特别是测试场景下，我们需要特别注意这类隐式的依赖关系。通过理解底层原理，我们可以更好地组织代码结构，避免类似的陷阱。

对于使用MSW和openapi-fetch的开发者来说，关键是要确保拦截器在客户端缓存fetch引用之前就已经安装完成。这既可以通过代码组织来实现，也可以通过显式依赖注入来保证。