通过API Gateway调用AWS Lambda失败，本地及手动调用正常

我之前也碰到过几乎一模一样的情况！本地调用和Lambda控制台测试都正常，一通过API Gateway就出问题，大概率是事件结构不匹配或者授权/集成配置没到位，咱们一步步捋：

1. 先搞清楚API Gateway传的事件和你测试的不一样 #

你本地serverless invoke local和控制台测试用的是：

{ "requestContext": { "identity": { "cognitoIdentityId": "468648..." } }

但API Gateway实际触发Lambda时的事件结构，跟你手动构造的完全不同：

• 如果是REST API：只有当你配置了Cognito授权器，并且请求带了有效令牌时，requestContext.identity.cognitoIdentityId才会存在；没开授权的话，这个字段要么是null，要么直接没有。
• 如果是HTTP API：Cognito的身份信息会在requestContext.authorizer.jwt.claims.sub这类路径下，根本不是requestContext.identity.cognitoIdentityId。

快速验证方法：
在Lambda代码里加一行日志，把整个事件打出来：

// 比如Node.js的handler开头加这个
console.log('Full event from API Gateway:', JSON.stringify(event, null, 2));

然后用API Gateway调用一次，去CloudWatch日志里看实际收到的事件结构，对比你测试用的，就能发现哪里不对了。

2. 检查Serverless的API集成配置 #

Serverless Framework默认的API Gateway集成有两种模式：lambda和lambda-proxy，这俩差别很大：

• 如果用的是lambda（非代理）：API Gateway会自动转换事件结构，你拿不到完整的requestContext。
• 必须用lambda-proxy：才能让API Gateway把完整的请求事件（包括上下文、头信息、请求体）原封不动传给Lambda。

看看你的serverless.yml里的函数配置是不是类似这样：

functions:
  listDynamoItems:
    handler: src/handler.listItems
    events:
      - http:
          path: items/{id} # 你的路径
          method: post # 或者GET，看你的需求
          integration: lambda-proxy # 这个必须有！
          authorizer: # 如果依赖Cognito授权，要配置这个
            name: myCognitoAuthorizer
            arn: arn:aws:cognito-idp:us-east-1:1234567890:userpool/us-east-1_XXXXXXX

3. 确认Cognito授权是否真的生效 #

如果你代码里依赖cognitoIdentityId，那必须确保：

• Serverless配置里的Authorizer ARN是正确的，API Gateway的阶段已经关联了这个授权器。
• 测试API Gateway时，必须在请求头里带有效令牌：Authorization: Bearer <你的Cognito用户令牌>。
  如果你只是在API Gateway控制台的测试界面手动输入负载，没带这个头，那requestContext.identity.cognitoIdentityId肯定是空的，Lambda逻辑自然跑不起来。

4. 检查Lambda执行角色的权限 #

虽然本地和控制台测试正常，但API Gateway触发时，Lambda的执行角色有没有足够权限？比如：

• 有没有dynamodb:Query/dynamodb:Scan权限（看你是查指定ID下的条目，应该是Query）？
• 有没有CloudWatch日志权限？如果连日志都打不出来，排查起来会非常麻烦。

5. 用真实请求测试，别只依赖控制台 #

API Gateway的测试界面有时候会忽略一些头信息，建议用Postman或者curl发真实请求：

curl -X POST https://abc123.execute-api.us-east-1.amazonaws.com/dev/items \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -H "Content-Type: application/json" \
  -d '{}'

然后看返回结果和CloudWatch日志，更容易定位问题。

我当时就是踩了HTTP API事件结构的坑，代码里硬找requestContext.identity.cognitoIdentityId，结果实际是在requestContext.authorizer.jwt.claims.sub里，打了日志才发现问题！

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