MSW.js 中 Headers 初始化与服务器启动顺序的陷阱解析

问题背景

在 Node.js 测试环境中使用 MSW.js 进行 API 模拟时，开发者可能会遇到一个隐蔽但影响重大的问题：在服务器启动前创建的 Headers 对象，在后续修改后无法正确保留所有头部信息。这个问题在 MSW.js 2.4.3 版本后出现，直到最新版本才得到修复。

技术细节分析

Headers 对象的行为变化

问题的核心在于 Headers 对象的初始化时机与 MSW 服务器启动顺序的交互。当开发者在测试代码中执行以下操作序列时：

1. 创建 Headers 实例并设置初始值
2. 调用 server.listen() 启动 MSW 服务器
3. 继续修改 Headers 实例

在 MSW.js 2.4.3 及之前版本中，这种操作序列能够正常工作，所有头部信息都会被保留。但在 2.4.4 及之后版本中，服务器启动前设置的头部信息会在实际请求中丢失，只有服务器启动后添加的头部才会生效。

底层机制

这种行为的改变源于 MSW.js 底层对请求拦截机制的改进。在较新版本中，MSW 会对 Headers 对象进行更严格的隔离处理，以确保模拟环境的纯净性。然而，这种隔离处理意外影响了在服务器启动前创建的 Headers 对象。

影响范围

这个问题主要影响以下场景：

1. 在测试代码中预先配置好公共头部信息
2. 在测试初始化阶段就准备好请求参数
3. 使用共享的 Headers 对象进行多次测试

解决方案

对于遇到此问题的开发者，有以下几种解决方案：

1. 升级到最新版本：MSW.js 的最新版本已经修复了这个问题
2. 调整测试代码顺序：将 Headers 的创建和修改都放在 server.listen() 之后
3. 使用替代初始化方式：通过 npm 命令预先加载 mock 配置，而不是在代码中直接初始化

最佳实践建议

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

1. 统一在测试的 beforeEach 或 setup 阶段初始化所有测试数据
2. 避免在测试文件顶层创建和修改 Headers 对象
3. 考虑使用工厂函数来创建测试用的请求参数
4. 保持 MSW.js 及其相关依赖的最新版本

总结

这个问题展示了测试工具与原生 API 交互时可能出现的微妙边界情况。理解这类问题的本质有助于开发者编写更健壮的测试代码，并在遇到类似问题时能够快速定位原因。随着 MSW.js 的持续更新，这类边界情况会得到更好的处理，但开发者仍需关注测试工具与原生 API 的交互行为。