当Content-Length超过1024时Postman无法获取Node.js响应

问题场景 #

使用Node.js搭建简易API，返回包含长token的JSON响应，代码如下：

router.get("", (req: Request, res: Response, next: NextFunction) => {
  // res.removeHeader("Content-Length");
  return res.status(200).send({
    message: "HelloWorld",
    token: "{long text}",
  });
});

遇到的问题：Postman持续报错「Parse Error: The server returned a malformed response」，且仅当响应的Content-Length超过1024时触发；但使用curl工具无论内容长度多少都能正常获取响应。移除compression()中间件后，问题消失。

原因分析 #

compression中间件会自动对响应进行gzip/deflate压缩，问题出在Postman与该中间件的兼容性上：

• 当响应内容长度达到临界值（如1024）时，compression可能会切换到分块传输编码（chunked），而Postman对这种编码的解析逻辑存在bug，无法正确处理压缩后的分块响应。
• 另一种可能是压缩后的实际响应长度与Content-Length头不匹配，Postman严格校验头信息与实际内容，导致触发解析错误；而curl对这类不匹配的容忍度更高，或能自动修正解析逻辑。

解决方案 #

方案1：移除compression中间件（快速解决） #

如果API不需要响应压缩，直接删除app.use(compression());即可，此时服务器会返回未压缩的完整响应，Postman能正常解析。

方案2：配置compression参数（保留压缩的前提下修复） #

调整compression的阈值，让短内容不触发压缩，仅对更大的响应启用压缩：

// 设置阈值为2048字节，只有内容超过该大小才压缩
app.use(compression({ threshold: 2048 }));

也可以指定压缩算法，避免Postman不兼容的编码方式：

app.use(compression({ encoding: ['gzip'] }));

方案3：手动控制响应头（精准匹配长度） #

先将响应数据序列化为字符串，计算其字节长度后手动设置Content-Length，确保头信息与实际内容一致：

router.get("", (req: Request, res: Response, next: NextFunction) => {
  const responseData = {
    message: "HelloWorld",
    token: "{long text}"
  };
  const jsonStr = JSON.stringify(responseData);
  // 设置正确的Content-Length和Content-Type
  res.setHeader("Content-Length", Buffer.byteLength(jsonStr, 'utf8'));
  res.setHeader("Content-Type", "application/json; charset=utf-8");
  return res.status(200).send(jsonStr);
});

这种方式能避免compression自动修改响应头导致的不匹配问题，Postman可正确解析响应。

内容的提问来源于stack exchange，提问作者Thuận Phạm