Node.js Lambda微服务（Serverless Express.js）启用Compression后出现“无法访问站点”错误

开发者阿泽

2026-5-26

嘿，我来帮你理清楚Node.js的compression库在AWS Lambda + aws-serverless-express场景下的工作逻辑，以及为什么它会给你添乱——毕竟你用的还是Node.js 6.10这种比较老的版本，环境特殊性确实容易踩坑。

Compression库的核心工作机制

本质上，compression是一个Express中间件，它基于Node.js内置的zlib模块实现，核心逻辑很直接：

首先检查请求头里的Accept-Encoding字段，如果客户端支持gzip或deflate压缩，就开启压缩流程
它会自动过滤响应内容：只对文本类资源（比如JSON、HTML、CSS）进行压缩，默认会跳过小于1KB的响应（可以通过threshold配置调整）
采用流式压缩：响应数据从你的路由流出时，会被逐块压缩，不用把整个响应体加载到内存里，这在常规服务器环境下很高效

为什么在你的场景下容易出问题？

结合Node.js 6.10的特性和AWS Lambda的环境限制，常见的坑有这几个：

Lambda响应大小限制与压缩时机冲突
Lambda对返回的payload有6MB的上限（指原始未压缩的数据），但compression是在响应发送阶段才进行压缩。如果你的接口返回的原始数据接近或超过6MB，哪怕压缩后能控制在阈值内，Lambda可能已经因为原始数据过大抛出错误了。另外，aws-serverless-express在把Express响应转换成Lambda响应的过程中，如果对流式压缩的处理不当，还可能导致数据截断。
Node.js 6.10的zlib兼容性问题
Node.js 6.10的zlib模块版本比较老旧，而较新的compression库版本可能依赖了高版本Node.js的zlib特性（比如动态压缩级别调整、更稳定的流式处理），这会导致在Node.js 6环境下出现奇怪的报错，比如压缩时内存泄漏、无法正确终结压缩流等。
aws-serverless-express的代理逻辑冲突
aws-serverless-express需要把Lambda的event转换成Express的request对象，再把Express的response转换成Lambda的response返回。如果compression已经给响应设置了Content-Encoding头，但aws-serverless-express在转换时没有正确保留这个头，或者把压缩后的二进制数据当成字符串处理，客户端收到的就会是乱码。
冷启动时的性能损耗
Lambda冷启动时，compression需要初始化zlib的压缩上下文，这在Node.js 6.10这种启动速度较慢的版本上，会进一步增加冷启动时间，甚至导致请求超时。

结合你的代码来看排查方向

你的index.js是标准的aws-serverless-express配置：

'use strict'; 
const awsServerlessExpress = require('aws-serverless-express') 
const app = require('./app') 
const server = awsServerlessExpress.createServer(app) 
exports.handler = (event, context) => awsServerlessExpress.proxy(server, event, context);

问题大概率出在./app.js里的compression中间件配置上，给你几个排查建议：

明确压缩过滤规则：避免误压缩二进制文件，比如图片、视频，你可以手动指定只压缩文本类型：

const compression = require('compression');
app.use(compression({
  filter: (req, res) => {
    // 允许通过请求头跳过压缩
    if (req.headers['x-no-compression']) {
      return false;
    }
    // 只压缩文本类响应
    const contentType = res.getHeader('Content-Type');
    return contentType && /text|json|javascript/.test(contentType);
  },
  threshold: 1024 // 只处理大于1KB的响应
}));

锁定兼容的compression版本：Node.js 6.10建议使用compression@1.7.4，这是兼容该Node版本的最后几个稳定版本之一，避免用太新的版本导致依赖冲突。
检查响应头与编码格式：在Lambda日志里查看返回的响应头是否包含正确的Content-Encoding，同时确认Lambda的响应是否设置了isBase64Encoded: true（aws-serverless-express应该自动处理，但老版本可能有bug）。
查看Lambda报错日志：重点找zlib相关的错误信息，比如zlib binding closed或内存溢出类的报错，这些能直接定位压缩过程中的问题。

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