响应结束后执行收尾逻辑应使用 res.on('finish') 事件，它在响应头和体全部写入 socket 后触发且仅一次；需在 write/end 前注册，避免重复监听和 headers_sent 错误。
响应结束处理时如何执行收尾逻辑
HTTP 响应一旦写出（write 或 end），连接就可能关闭，后续代码大概率不会执行。想在响应结束后做清理、日志、资源释放？不能靠“写完响应再执行”，得换思路。
Node.js 中 res.on('finish') 是最可靠钩子
Express /原生 http.ServerResponse 都支持 finish 事件，它在响应头+体全部刷入 socket 后触发，且保证只触发一次。比 close 更准确（后者可能因客户端断连提前触发）。
常见错误现象：res.end(); console.log('done'); 看似执行了，但若中间件抛错或 socket 被复用，done 可能根本没打出来；更糟的是，你试图在这里关数据库连接，结果连接被提前释放，后续请求出错。
实操建议：
-
res.on('finish', () => { /* 清理逻辑 */ })必须在res.write()或res.end()之前注册，否则会错过事件 - 避免在回调里调用
res.write()或res.end()—— 此时响应已结束，会抛Error [ERR_HTTP_HEADERS_SENT] - 如果用了
res.json()或res.send()，它们内部会调用end()，所以finish仍有效
res.on('finish', () => {
console.log('响应已发出，开始清理');
clearTimeout(timeoutId);
db.releaseConnection(req.connId);
});
async/await 场景下别用 try-finally 模拟 finish
有人写 try { await sendResponse(); } finally { cleanup(); }，这看似合理，但只要响应还没真正发出（比如流式传输中、gzip 压缩未完成、代理缓冲未 flush），finally 就可能提前运行 —— 它只管 JS 执行流，不管底层 socket 状态。
使用场景：你在用 pipeline 把文件流写给客户端，或用 fetch + ReadableStream 做转发。此时 JS 层的 await 返回不等于客户端收到字节。
参数差异：res.finished 是布尔值，表示是否已调用过 end()；res.writableEnded 表示可写端是否关闭；两者都为 true 也不代表数据已送达客户端 —— 这正是为什么必须依赖 finish 事件。
中间件里注册 finish 钩子要注意 req/res 生命周期
Express 中，每个请求对应唯一 req/res，但中间件可能被多次调用（比如路由匹配失败后走 next()）。如果在中间件里反复 res.on('finish', ...)，会叠加多个监听器，导致收尾逻辑重复执行。
实操建议：
- 用
res.finished初步判断是否已结束，但别依赖它做逻辑分支（它可能为false却已无法监听） - 更稳妥的方式是加个标记：
if (!res._cleanupRegistered) { res._cleanupRegistered = true; res.on('finish', ...) } - 不要在
app.use()全局中间件里无条件注册 —— 静态文件、404、错误处理等路径可能不走你的逻辑，却仍触发钩子
性能影响很小，finish 是原生事件，但监听器太多会轻微增加 GC 压力；兼容性没问题，Node.js 8+ 全支持。
最容易被忽略的是：代理层（Nginx、Cloudflare）可能缓存响应或改写 Connection 头，导致 finish 触发时机和真实网络送达不一致 —— 如果业务强依赖“客户端确实收到了”，得加客户端回执或埋点验证，光靠服务端钩子不够。
