Node-Nock库在模拟Fetch响应流时遇到的控制器状态问题解析

Node-Nock作为Node.js生态中广泛使用的HTTP模拟库，在最新14.0.0-beta.6版本中出现了一个关于Fetch API响应流处理的边界情况问题。本文将深入分析该问题的技术背景、产生原因及解决方案。

问题本质

当使用Node-Nock模拟Fetch请求时，如果应用程序代码主动取消了响应体的ReadableStream，而Nock内部仍尝试关闭该流的控制器(ReadableStreamController)，就会抛出"Invalid state: Controller is already closed"的类型错误。

技术背景

现代Node.js的Fetch实现(如undici)要求开发者必须处理响应体流，否则可能导致内存泄漏。这是因为：

1. Fetch响应体本质上是ReadableStream
2. 根据流处理规范，未消费的流会持续占用内存
3. undici明确建议开发者主动取消未使用的响应体

问题复现条件

该问题会在以下场景触发：

1. 使用Node.js 22.2.0环境
2. 安装nock@14.0.0-beta.6
3. 测试代码中主动调用response.body.cancel()
4. Nock在测试完成后仍尝试关闭流控制器

底层原理分析

问题的核心在于Nock对Fetch响应生命周期的管理不够完善。当开发者取消流时：

1. 流控制器会进入"closed"状态
2. 此时任何对控制器的操作都会抛出状态错误
3. Nock的清理逻辑没有检测这种前置状态变化
4. 导致在测试清理阶段尝试操作已关闭的控制器

解决方案

Node-Nock团队在14.0.0-beta.7版本中修复了该问题，主要改进包括：

1. 增加流控制器状态检测
2. 在清理前判断控制器是否已关闭
3. 避免对已关闭控制器执行操作

最佳实践建议

对于使用Nock进行Fetch测试的开发者，建议：

1. 始终处理Fetch响应体，即使测试中不需要其内容
2. 对于不需要的响应体，显式调用cancel()
3. 升级到最新beta版本以获得稳定体验
4. 在测试中注意流的生命周期管理

该问题的修复体现了Node-Nock对现代Node.js特性的持续适配，确保了在Fetch API场景下的稳定性和可靠性。