Express.js中间件修改res.end响应块导致响应时间升10倍问题咨询

• 核心原因是响应头Content-Length不匹配：你通过res.status(...).json(...)返回原始响应时，Express会自动根据原始响应体的大小设置Content-Length头。开启alterBody后你替换了更小的响应体，但没有更新该响应头，客户端收到的实际字节数远小于预期值，会持续等待剩余数据直到连接超时，直接导致响应时间暴涨到超时阈值。
• 额外问题：如果你当前的自定义中间件挂载顺序早于express-winston，会导致express-winston记录的也是修改后的响应内容，无法满足日志保留完整信息的需求。

可以通过调整中间件顺序、补充响应头更新逻辑解决，全程不会额外增加明显耗时，可保持原有响应速度：

1. 调整中间件挂载顺序：先挂载express-winston日志中间件，再挂载自定义的响应修改中间件。这样express-winston会先捕获完整的原始响应内容记录日志，再执行你的响应修改逻辑，返回删减后的内容给用户。
2. 更新自定义中间件逻辑：修改响应体的同时同步更新Content-Length头，同时完整传递res.end的所有参数（包括回调函数），保证Express内部逻辑正常执行。
   修改后的中间件参考代码：

module.exports.responseMiddleware = (req, res, next) => {
  const originalEnd = res.end;
  res.end = function(chunk, encoding, callback) {
    // 立即恢复原始end方法，避免重复劫持
    res.end = originalEnd;
    let resultChunk = chunk;
    if (req.body.alterBody === 'yes') {
      resultChunk = Buffer.from(JSON.stringify({}));
      // 同步更新响应长度头，避免客户端等待超时
      res.setHeader('Content-Length', resultChunk.length);
    }
    // 传递所有参数，包括回调，保证链路正常
    return res.end(resultChunk, encoding, callback);
  };
  next();
};

如果你的服务开启了gzip等响应压缩，需要先解压原始响应块、修改后再重新压缩，同时同步更新Content-Encoding等相关响应头即可。

内容的提问来源于stack exchange，提问作者Sharang