如果你正在用 Node.js 作为 BFF（Backend For Frontend）层，对接大模型 API 并转发 SSE（Server-Sent Events）流式响应，那么这篇文章就是为你准备的。你可能已经成功实现了基本的转发逻辑，但有没有遇到过这种情况：用户中途关闭了浏览器标签页，或者网络突然中断，你的 Node.js 服务端却还在傻傻地向一个已经不存在的连接发送数据？更糟糕的是，上游的大模型 API 调用可能仍在计费，服务器资源（如内存、Socket 连接）也未被释放。这种“幽灵连接”正是流式服务中一个隐蔽但危害巨大的资源泄漏点。
很多人以为 SSE 连接断开后，Node.js 会自动处理一切。但现实是，在 BFF 这种“中间人”角色中，你需要同时管理两个连接：一个是与客户端的 SSE 连接，另一个是与上游大模型服务（如 OpenAI、文心一言等）的 HTTP 长连接。客户端断开时，Node.js 的response对象可能不会立即触发close或finish事件，而上游的请求如果没有被正确终止，就会持续消耗资源和费用。
本文将深入剖析这个问题的根源，并提供一套从原理到实战的完整解决方案。你将不仅学会如何监听连接断开，更重要的是，掌握如何在 Node.js BFF 层中，系统性地管理上下游连接的生命周期，构建一个健壮、可观测且资源友好的流式转发服务。我们会从 Node.js 的http模块事件讲起，到 Express/Koa 框架中的最佳实践，再到如何优雅地中止fetch或axios发起的上游请求。读完本文，你将能彻底告别因客户端意外断开导致的资源泄漏问题。
1. 问题本质：为什么资源释放会成为 BFF 层的“阿喀琉斯之踵”？
在传统的请求-响应模式中，一次 HTTP 请求对应一次响应，请求结束，连接关闭，资源释放。但在 SSE 流式转发的场景下，游戏规则变了。整个过程可以拆解为三个角色和两个连接：
- 客户端：浏览器或 App，通过
EventSource或fetch发起 SSE 连接请求。 - BFF 层：你的 Node.js 服务，它同时扮演了两个角色：
- 服务器：对客户端，它需要建立一个持久的、单向的 SSE 连接，并持续写入数据流。
- 客户端：对上游大模型服务，它需要发起另一个 HTTP 请求（通常是 POST），并接收一个分块传输编码（chunked）的流式响应。
- 上游大模型服务：提供流式 SSE 响应的 API。
问题就出在连接生命周期的不同步上。当客户端因为刷新、关闭标签页、网络切换等原因断开连接时，BFF 层与客户端的 SSE 连接会进入异常状态。然而，Node.js 中，这个异常状态不会自动传递给 BFF 层与上游服务建立的那个请求。上游服务并不知道下游的“听众”已经离场，它依然会忠实地生成并发送后续的 token，直到请求自然结束或超时。
这会导致几个直接的后果：
- 资源浪费：上游服务的计算资源被白白消耗，如果按 token 计费，这些费用就成了“冤枉钱”。
- BFF 层资源泄漏：Node.js 进程需要维护一个已经无效的 Socket 连接，并持续处理上游传来的数据。这些数据无处可去，只能被丢弃，但相关的内存、缓冲区、事件监听器可能不会被及时回收。
- 服务稳定性风险：在并发量高时，大量此类“僵尸连接”会耗尽服务器的文件描述符、内存和 CPU，最终可能导致服务崩溃。
因此，BFF 层的核心职责之一，就是成为连接状态的“协调者”，确保下游断开时，能立即通知上游终止任务。
2. 核心原理：Node.js 中如何感知连接断开？
要解决问题，首先得能发现问题。在 Node.js 中，无论是原生的http模块还是 Express、Koa 等框架，底层都是通过http.ServerResponse对象来向客户端发送数据的。我们需要监听这个响应对象发出的特定事件，来感知连接状态的变化。
2.1 关键事件：close与finish
response.on('close', callback)：当底层的 TCP 连接异常终止时触发。例如客户端强制关闭浏览器、网络断开、超时等。这是监听客户端意外断开的最重要事件。response.on('finish', callback)：当响应数据的所有片段都已成功刷新到底层系统（操作系统内核的 TCP 缓冲区）时触发。这通常意味着正常结束，数据已全部发送给客户端（尽管客户端不一定完整接收）。在 SSE 场景中，当你调用response.end()或流自然结束时，会触发此事件。
对于 SSE 这种长连接，我们主要依赖close事件。但需要注意，在某些网络环境下（如某些代理服务器），close事件可能不会立即触发，或者触发时机不确定。
2.2 框架中的处理差异
在 Express 或 Koa 中，我们操作的是封装过的res对象。好消息是，它们通常都继承了原生的http.ServerResponse，因此res.on('close', ...)仍然是有效的。
Express 示例：
app.get('/stream', (req, res) => { // 设置SSE头部 res.writeHead(200, { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache', 'Connection': 'keep-alive' }); // 监听连接关闭事件 res.on('close', () => { console.log('客户端连接已关闭，需要清理上游请求。'); // 在这里执行清理逻辑，例如中止 fetch 请求 }); // ... 后续转发逻辑 });Koa 示例：Koa 的ctx.res就是原生的response对象。
router.get('/stream', async (ctx) => { ctx.set({ 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache', 'Connection': 'keep-alive' }); ctx.status = 200; // 监听原生 response 对象的 close 事件 ctx.res.on('close', () => { console.log('客户端连接已关闭，需要清理上游请求。'); // 清理逻辑 }); // 注意：Koa中，需要手动将body设置为流，并避免自动end ctx.respond = false; // 告诉Koa不要自动处理响应 // ... 后续转发逻辑 });2.3 心跳机制：弥补事件触发的不可靠性
单纯依赖close事件可能不够健壮。我们可以引入“心跳”机制：定期向客户端发送一个注释行（以:开头的行，SSE 规范中会被忽略）。如果连接正常，心跳能顺利发送；如果连接已断，尝试写入心跳时会触发错误或暴露出连接不可用的状态。
function setupHeartbeat(res) { const heartbeatInterval = setInterval(() => { try { // 发送一个SSE注释行作为心跳 res.write(': ping\n\n'); } catch (err) { // 写入失败，说明连接可能已断开 console.error('心跳发送失败，连接可能已断开:', err.message); clearInterval(heartbeatInterval); // 触发清理逻辑 cleanupUpstreamRequest(); } }, 30000); // 每30秒一次 // 当连接关闭时，清除定时器 res.on('close', () => { clearInterval(heartbeatInterval); }); }心跳机制有两个作用：1) 保持连接活跃，防止被中间代理或负载均衡器超时断开；2) 作为一种主动探测，辅助判断连接健康状态。
3. 环境准备与项目结构
在进入具体代码之前，我们先明确一下演示环境。你需要一个基本的 Node.js 项目。
- Node.js 环境：建议使用 Node.js 16 或更高版本（为了更好的 AbortController 支持）。你可以通过
node -v检查。 - 初始化项目：
mkdir node-bff-sse-demo cd node-bff-sse-demo npm init -y - 安装依赖：我们将使用 Express 作为 Web 框架，node-fetch 用于向上游发起请求（Node.js 18+ 内置了
fetch，如果你版本较低，需要安装）。# 如果使用 Node.js < 18 npm install express node-fetch # 如果使用 Node.js >= 18 npm install express - 项目结构：
node-bff-sse-demo/ ├── package.json ├── server.js # 主服务文件 ├── client.html # 用于测试的简单前端页面 └── .env (可选) # 用于存储API密钥等配置
4. 核心流程拆解：构建健壮的 SSE 转发中间件
我们的目标是创建一个可复用的中间件或函数，它负责：
- 建立与客户端的 SSE 连接。
- 监听该连接的关闭事件。
- 使用可中止的方式向上游服务发起请求。
- 将上游的流式响应实时转发给客户端。
- 一旦客户端断开，立即中止上游请求并进行所有必要的清理。
4.1 步骤一：创建 SSE 端点并设置响应头
首先，创建一个 Express 服务器和 SSE 端点。
// server.js const express = require('express'); const app = express(); const PORT = process.env.PORT || 3000; // 模拟上游大模型API的URL，实际项目中替换为真实地址 const UPSTREAM_API_URL = 'https://api.openai.com/v1/chat/completions'; const UPSTREAM_API_KEY = 'your-api-key-here'; // 请妥善保管，建议用环境变量 app.get('/api/chat/stream', async (req, res) => { // 1. 设置SSE响应头 res.writeHead(200, { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache, no-transform', 'Connection': 'keep-alive', 'X-Accel-Buffering': 'no', // 禁用Nginx等代理的缓冲 'Access-Control-Allow-Origin': '*', // 根据CORS需求调整 }); // 2. 立即发送一个初始消息或注释，让客户端知道连接已建立 res.write('event: connected\ndata: {"status": "ok"}\n\n'); // 3. 设置心跳（可选但推荐） const heartbeatInterval = setInterval(() => { try { res.write(': heartbeat\n\n'); } catch (err) { // 写入失败，连接可能已坏 clearInterval(heartbeatInterval); } }, 30000); // 4. 监听连接关闭 const handleClientClose = () => { console.log(`[${new Date().toISOString()}] 客户端连接关闭。`); clearInterval(heartbeatInterval); // 标记连接已关闭，后续清理逻辑会用到 res._clientClosed = true; // 注意：这里还不能 res.end()，因为可能还在向上游写数据 }; res.on('close', handleClientClose); // 5. 转发上游请求的逻辑（下一步实现） await forwardStreamToClient(req, res); }); app.listen(PORT, () => { console.log(`BFF 服务运行在 http://localhost:${PORT}`); });4.2 步骤二：实现可中止的上游请求转发
这是最核心的部分。我们需要使用AbortController来创建一个可以中断的fetch请求。
// server.js (续) const fetch = (...args) => import('node-fetch').then(({default: fetch}) => fetch(...args)); // Node.js < 18 需要 async function forwardStreamToClient(clientReq, clientRes) { const abortController = new AbortController(); const upstreamSignal = abortController.signal; // 将 abortController 绑定到 clientRes，以便在连接关闭时访问 clientRes._abortController = abortController; try { // 构造请求上游大模型API的选项 const upstreamOptions = { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${UPSTREAM_API_KEY}`, }, body: JSON.stringify({ model: 'gpt-3.5-turbo', messages: [{ role: 'user', content: 'Hello, tell me a story.' }], stream: true, // 关键：要求流式响应 }), signal: upstreamSignal, // 传入 signal，使请求可被中止 }; console.log('正在向上游发起请求...'); const upstreamResponse = await fetch(UPSTREAM_API_URL, upstreamOptions); if (!upstreamResponse.ok || !upstreamResponse.body) { const errorText = await upstreamResponse.text(); clientRes.write(`event: error\ndata: ${JSON.stringify({ msg: '上游请求失败', detail: errorText })}\n\n`); clientRes.end(); return; } // 获取上游的流式响应体 const upstreamReadableStream = upstreamResponse.body; // 监听客户端连接关闭，如果发生，则中止上游请求 clientRes.on('close', () => { console.log('检测到客户端断开，正在中止上游请求...'); abortController.abort(); // 关键操作！ }); // 管道：将上游的流，通过转换，写入客户端的响应 for await (const chunk of upstreamReadableStream) { // 检查客户端连接是否还健康 if (clientRes._clientClosed || clientRes.writableEnded || !clientRes.writable) { console.log('客户端响应不可写，停止转发并中止上游。'); abortController.abort(); break; } // 将上游的 chunk (Buffer) 转换为字符串，并转发给客户端 // 注意：上游API返回的通常是纯文本的SSE格式，我们可能需要直接转发或稍作包装 const chunkStr = chunk.toString(); // 简单转发（假设上游返回的就是标准SSE数据块） try { clientRes.write(chunkStr); } catch (writeErr) { console.error('向客户端写入数据失败:', writeErr.message); abortController.abort(); break; } } console.log('上游流式响应结束。'); // 正常结束，发送一个结束事件 if (!clientRes._clientClosed && clientRes.writable) { clientRes.write('event: done\ndata: {"finished": true}\n\n'); clientRes.end(); } } catch (error) { // 捕获错误，包括因 abort() 引起的 AbortError if (error.name === 'AbortError') { console.log('上游请求已被客户端中止。'); } else { console.error('转发流时发生错误:', error); // 尝试向客户端发送错误信息 if (!clientRes._clientClosed && clientRes.writable) { clientRes.write(`event: error\ndata: ${JSON.stringify({ msg: '流处理异常', error: error.message })}\n\n`); clientRes.end(); } } } finally { // 最终清理：移除监听器，确保无内存泄漏 clientRes.removeAllListeners('close'); delete clientRes._abortController; delete clientRes._clientClosed; console.log('请求处理完毕，资源清理完成。'); } }4.3 步骤三：创建测试客户端
创建一个简单的 HTML 页面来测试我们的 BFF 服务。
<!-- client.html --> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>SSE BFF 测试客户端</title> </head> <body> <h1>SSE 流式响应测试</h1> <button id="connectBtn">连接并开始流式请求</button> <button id="disconnectBtn" disabled>断开连接</button> <br><br> <div id="output" style="white-space: pre-wrap; border:1px solid #ccc; padding:10px; min-height:200px;"></div> <script> let eventSource = null; const outputDiv = document.getElementById('output'); document.getElementById('connectBtn').addEventListener('click', () => { outputDiv.innerHTML += '正在连接到 BFF SSE 端点...\n'; eventSource = new EventSource('http://localhost:3000/api/chat/stream'); eventSource.addEventListener('connected', (e) => { const data = JSON.parse(e.data); outputDiv.innerHTML += `连接成功: ${data.status}\n`; document.getElementById('disconnectBtn').disabled = false; }); eventSource.addEventListener('message', (e) => { // 这里处理上游返回的实际数据流 // 假设上游返回的是纯文本，直接显示 outputDiv.innerHTML += `数据块: ${e.data}\n`; outputDiv.scrollTop = outputDiv.scrollHeight; }); eventSource.addEventListener('done', (e) => { const data = JSON.parse(e.data); outputDiv.innerHTML += `流式响应结束: ${JSON.stringify(data)}\n`; disconnect(); }); eventSource.addEventListener('error', (e) => { outputDiv.innerHTML += `发生错误: ${e.data}\n`; disconnect(); }); eventSource.onerror = (err) => { console.error('EventSource 错误:', err); outputDiv.innerHTML += '连接发生错误或已关闭。\n'; disconnect(); }; }); document.getElementById('disconnectBtn').addEventListener('click', disconnect); function disconnect() { if (eventSource) { eventSource.close(); eventSource = null; outputDiv.innerHTML += '连接已手动关闭。\n'; document.getElementById('disconnectBtn').disabled = true; } } // 页面关闭前也断开连接 window.addEventListener('beforeunload', disconnect); </script> </body> </html>5. 运行与验证：观察资源释放过程
启动 BFF 服务：
node server.js控制台应输出：
BFF 服务运行在 http://localhost:3000打开测试页面：在浏览器中打开
client.html文件（可以通过file://协议或使用一个简单的静态文件服务）。发起连接：点击“连接并开始流式请求”按钮。观察浏览器开发者工具的“网络”选项卡，应该能看到一个类型为
eventsource的请求，状态为“待处理”（Pending）。同时，Node.js 服务端控制台会打印“正在向上游发起请求...”。模拟客户端意外断开：
- 方法一（手动）：在流式数据还在传输时，直接点击页面上的“断开连接”按钮。
- 方法二（模拟异常）：在流式传输过程中，直接关闭浏览器标签页。
- 方法三（网络中断）：使用开发者工具的“网络条件”面板，将网络设置为“离线”。
观察服务端日志：
- 如果资源释放逻辑生效，你应该会立即在 Node.js 控制台看到类似以下的日志：
检测到客户端断开，正在中止上游请求... 上游请求已被客户端中止。 请求处理完毕，资源清理完成。 - 这表明
close事件被触发，abortController.abort()被调用，上游fetch请求被成功中止，并且finally块中的清理逻辑也执行了。
- 如果资源释放逻辑生效，你应该会立即在 Node.js 控制台看到类似以下的日志：
验证资源释放：你可以通过一些系统命令来观察。在 Linux/macOS 上，可以使用
lsof -i :3000查看服务打开的连接数。在流式请求进行时，会有一个 ESTABLISHED 的连接。当客户端断开后，这个连接应该很快消失（被操作系统回收）。如果逻辑有误，你可能会看到连接处于 CLOSE_WAIT 状态，表示资源未完全释放。
6. 常见问题与排查思路
在实际部署中，你可能会遇到以下问题。这里提供一个排查表格：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
close事件未触发 | 1. 客户端连接未真正关闭（如浏览器最小化）。 2. 某些代理或负载均衡器（如 Nginx）缓冲了连接，未及时传递关闭信号。 3. Node.js 版本或框架的差异。 | 1. 在close事件处理函数中添加日志，确认是否执行。2. 检查 Nginx 配置中 proxy_buffering,proxy_read_timeout等参数。3. 增加心跳机制，通过写入错误来间接判断。 | 1. 结合心跳机制和res.writable状态判断。2. 在 Nginx 配置中针对 SSE 路径禁用缓冲： proxy_buffering off;。3. 使用 req.socket.on('close', ...)作为备选监听方式。 |
| 上游请求未被中止 | 1.AbortController.signal未正确传递给fetch。2. 上游服务不支持或未正确处理 SIGTERM或中断信号。3. abort()调用时机太晚，上游请求已近完成。 | 1. 检查fetch的options中是否包含signal。2. 查看上游 API 文档，确认是否支持流式中止。 3. 在 catch块中打印error.name，确认是否为AbortError。 | 1. 确保signal绑定正确。2. 对于不支持中止的上游，考虑设置更短的超时（ timeout选项）。3. 在 res.on('close')事件中第一时间调用abort()。 |
| 内存泄漏 | 1. 事件监听器未移除，导致res对象无法被垃圾回收。2. 上游响应流未被正确销毁。 3. 全局变量或闭包中保留了请求引用。 | 1. 使用 Node.js 的--inspect标志启动服务，用 Chrome DevTools 的 Memory 面板抓取堆快照。2. 检查 finally块中是否移除了监听器。 | 1. 在finally块或清理函数中，使用res.removeAllListeners('close')。2. 如果使用了 pipeline(upstreamStream, clientRes)，确保处理了管道错误和关闭。3. 避免在模块作用域缓存与请求相关的对象。 |
| 客户端收到不完整或乱码数据 | 1. 上游返回的数据格式不是纯 SSE 格式，BFF 直接转发导致格式错误。 2. 字符编码问题。 3. 写入客户端时发生背压（back pressure），数据积压。 | 1. 查看上游 API 返回的原始数据格式。 2. 检查响应头 Content-Type。3. 监听 res.write()的返回值（true表示缓冲区已清空，false表示内核缓冲区已满）。 | 1. 如果上游不是标准 SSE，需要在 BFF 层进行格式转换，包装成data: ...\n\n。2. 确保使用 utf-8编码。3. 使用 res.writable和res.writableHighWaterMark检查流状态，必要时暂停读取上游流。 |
| 高并发下性能下降或崩溃 | 1. 大量僵尸连接未释放，耗尽文件描述符。 2. 未设置合理的超时。 3. 日志输出过于频繁，阻塞事件循环。 | 1. 使用ulimit -n查看和调整系统文件描述符限制。2. 使用 process.memoryUsage()监控内存。3. 使用 APM 工具监控连接数和请求延迟。 | 1. 为 SSE 连接设置服务器端超时：req.socket.setTimeout(120000)。2. 使用连接池管理上游 HTTP 客户端（如 undici）。3. 对日志进行分级，生产环境减少 debug 日志。 |
7. 最佳实践与工程建议
将上述解决方案投入生产环境，还需要考虑更多工程化细节。
7.1 使用中间件封装
将 SSE 连接管理和资源释放逻辑抽象成一个可复用的中间件或高阶函数。
// middleware/sseWithCleanup.js const { AbortController } = require('node-abort-controller'); // Node.js < 15 需要 function createSSEStreamHandler(upstreamRequestFn) { return async function sseStreamHandler(req, res) { // 设置SSE头 res.writeHead(200, { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache, no-transform', 'Connection': 'keep-alive', 'X-Accel-Buffering': 'no', }); const abortController = new AbortController(); let upstreamStream = null; let isClientClosed = false; const cleanup = () => { if (!isClientClosed) { isClientClosed = true; abortController.abort(); if (upstreamStream && typeof upstreamStream.destroy === 'function') { upstreamStream.destroy(); } res.removeAllListeners('close'); res.removeAllListeners('error'); console.log(`[${req.id}] 连接清理完成。`); } }; res.on('close', cleanup); res.on('error', cleanup); // 发送连接确认 res.write('event: connected\ndata: {}\n\n'); try { // 调用传入的上游请求函数，并传入 abort signal upstreamStream = await upstreamRequestFn(req, abortController.signal); for await (const chunk of upstreamStream) { if (isClientClosed || !res.writable) { break; } // 这里可以加入数据转换逻辑 res.write(chunk); } if (!isClientClosed && res.writable) { res.write('event: done\ndata: {}\n\n'); res.end(); } } catch (error) { if (error.name !== 'AbortError' && !isClientClosed && res.writable) { res.write(`event: error\ndata: ${JSON.stringify({ error: error.message })}\n\n`); res.end(); } } finally { cleanup(); } }; } // 在路由中使用 app.get('/api/chat/stream', createSSEStreamHandler(async (req, signal) => { const response = await fetch(UPSTREAM_API_URL, { method: 'POST', headers: { /* ... */ }, body: JSON.stringify(/* ... */), signal, // 传入 signal }); if (!response.ok) throw new Error(`上游错误: ${response.status}`); return response.body; // 返回 ReadableStream }));7.2 超时控制
为 BFF 与上游的连接、以及 BFF 与客户端的连接设置双重超时。
// 服务器端超时 (针对客户端连接) req.socket.setTimeout(120000); // 2分钟无活动则超时 req.socket.on('timeout', () => { console.log('客户端连接超时'); res.end(); // 结束响应，会触发 'close' 事件 }); // 上游请求超时 (使用AbortController) const upstreamTimeoutMs = 60000; // 60秒 const timeoutId = setTimeout(() => { abortController.abort(); console.log('上游请求超时'); }, upstreamTimeoutMs); // 在清理函数中清除定时器 const cleanup = () => { clearTimeout(timeoutId); // ... 其他清理 };7.3 监控与日志
在生产环境中，详细的日志和监控至关重要。
- 连接生命周期日志：记录连接建立、数据传输、客户端断开、上游中止等关键事件，并关联唯一的请求 ID。
- 资源指标监控：监控 Node.js 进程的内存使用量、活跃的 SSE 连接数、文件描述符数量。
- 错误追踪：将
AbortError和其他错误上报到错误追踪系统（如 Sentry），并区分是正常的中止还是异常错误。
7.4 使用更高效的 HTTP 客户端
Node.js 内置的http/https模块或node-fetch在某些高并发流式场景下可能不是最优选择。可以考虑使用专为性能设计的客户端，如undici（Node.js 官方维护）。
const { request } = require('undici'); async function upstreamRequestWithUndici(signal) { const { body } = await request(UPSTREAM_API_URL, { method: 'POST', headers: { /* ... */ }, body: JSON.stringify(/* ... */), signal, // undici 也支持 AbortSignal }); return body; // 返回一个 Readable stream }undici提供了更好的连接池管理和更低的延迟。
7.5 考虑使用专门的流处理库
对于极其复杂的流转换、背压管理或错误处理，可以考虑使用rxjs或highland.js这样的流处理库，它们能提供更声明式和强大的操作符来处理数据流和生命周期。
8. 总结
在 Node.js BFF 层处理大模型 SSE 流式转发时，客户端意外断开连接是一个必须严肃对待的工程问题。它不仅仅是“断开连接”那么简单，而是涉及到双向连接生命周期管理、资源泄漏预防和成本控制的系统性挑战。
本文的核心解决思路可以概括为：“监听下游，控制上游”。通过监听客户端响应对象的close事件，并利用AbortController及时中止尚未完成的上游fetch请求，我们能够形成一个有效的资源回收闭环。同时，引入心跳机制、合理的超时设置、完善的错误处理和监控，可以构建出一个健壮的生产级流式转发服务。
关键要点回顾：
- 事件驱动：牢牢抓住
response.on('close')这个关键事件。 - 可中止请求：使用
AbortController和signal是现代 JavaScript 中中断fetch请求的标准方式。 - 状态同步：在
close事件处理函数中，必须同步更新一个标志位（如_clientClosed），并在数据转发循环中检查它，避免向已关闭的连接写入数据。 - 彻底清理：在
finally块中移除事件监听器、清除定时器、释放引用，这是防止内存泄漏的最后一道防线。 - 生产就绪：将核心逻辑封装成中间件，配置双重超时，并建立完善的监控和日志体系。
下次当你构建类似的流式服务时，不妨先问自己：如果一万个客户端同时断开，我的服务能平稳、无泄漏地处理吗？希望本文提供的方案，能让你对这个问题充满信心。建议将文中的核心代码片段收藏，在需要时作为参考模板。流式服务的世界很精彩，但细节决定成败，处理好资源释放，就是迈向稳定服务的第一步。
