部署Express应用至AWS Lambda时遭遇500内部服务器错误

我之前也踩过类似的坑，给你几个实用的排查方向，一步步来应该能揪出问题根源：

• 先拿CloudWatch日志当突破口：500错误最头疼的就是不知道具体错在哪，你得先确认Lambda的执行角色有没有CloudWatch日志权限（logs:CreateLogGroup、logs:CreateLogStream、logs:PutLogEvents这三个权限必须要有）。有了日志之后，直接去CloudWatch的日志组里找对应Lambda的日志流，里面会有具体的错误栈，比单纯的500/404提示有用多了。

• 核对API Gateway和Lambda的集成配置：

  • 先看集成请求是不是选了「Lambda函数」类型，区域和函数名称有没有完全匹配，别手滑选了别的函数或者写错了区域。
  • 一定要开启「使用Lambda代理集成」！aws-serverless-express完全依赖这个特性来正确转发请求的headers、路径、body这些参数，没开的话请求格式不对，Lambda里的Express根本没法正确处理，大概率会返回错误。

• 检查路径匹配是否一致：

  • 本地测试时你用的请求路径，和API Gateway里配置的资源路径是不是对齐了？比如本地你访问/api/users，但API Gateway的资源只配了/users，或者反过来，这样Express的路由匹配不到就会返回404，而API Gateway可能把这个转成500错误返回给你。
  • 看看你的Express代码里有没有加多余的路径前缀，比如app.use('/api', router)，但API Gateway的资源已经带了/api前缀，导致路径变成/api/api/users，自然匹配不到。

• 验证aws-serverless-express的初始化代码：

  • 确保你的handler代码是正确的，举个标准的例子：

    const awsServerlessExpress = require('aws-serverless-express');
    const app = require('./app');
    const server = awsServerlessExpress.createServer(app);
    
    exports.handler = (event, context) => {
      // 防止Lambda提前终止长连接（比如数据库连接）
      context.callbackWaitsForEmptyEventLoop = false;
      return awsServerlessExpress.proxy(server, event, context);
    };
    

  • 别漏了context.callbackWaitsForEmptyEventLoop = false，如果你的应用有数据库、Redis这类长连接，这个设置能避免Lambda在请求处理完之前就把连接断掉，导致后续请求出错。

• 排查依赖包的兼容性问题：

  • 本地用的Node.js版本和Lambda控制台里选的运行时版本必须一致！比如本地是18.x，Lambda选16.x，很多依赖会有兼容性问题，直接导致Lambda启动失败。
  • 确保打包的时候把所有生产依赖都包含进去了，用npm install --production安装依赖后再打包，别漏了node_modules文件夹。如果用Serverless Framework的话，确认它的打包配置里没有排除必要的依赖。
  • 要是用了需要编译的依赖（比如bcrypt、canvas这类），本地Windows/Mac编译的包在Lambda的Linux环境下跑不起来，得用Linux环境编译，或者找预编译好的兼容包。

• 直接测试Lambda函数：

  • 绕开API Gateway，直接在Lambda控制台里创建测试事件，模拟一个API Gateway的请求，比如：

    {
      "httpMethod": "GET",
      "path": "/your-test-path",
      "headers": {},
      "queryStringParameters": {}
    }
    

  • 执行测试后看返回结果，如果直接调用Lambda就报错，那问题肯定在Lambda的代码或配置上；如果直接调用正常，那就是API Gateway的集成配置哪里出了问题。

备注：内容来源于stack exchange，提问作者Arshdeep Singh