如何将多版本AWS Lambda关联至API Gateway的dev/prod环境？

我来帮你一步步梳理可能的问题点，这类配置失效通常都逃不开这几个常见环节：

1. 确认阶段变量的配置完全正确 #

首先要抠细节检查阶段变量：

• 进入API Gateway的dev和prod阶段设置页面，确认fname变量的名称完全匹配你在集成请求里写的${stageVariables.fname}——阶段变量是大小写敏感的，别把fname写成FName或者fname_这类拼写错误。
• 确认dev阶段的fname值是dev，prod阶段是prod，没有多余空格或者拼写错误。

2. 检查API Gateway调用Lambda的权限是否覆盖别名 #

这是最容易踩坑的点：API Gateway的执行角色需要有调用Lambda别名的权限，而不仅仅是函数本身。

• 打开IAM控制台，找到API Gateway对应的执行角色，查看其权限策略。
• 确保策略中的Resource字段包含Lambda别名的ARN，比如：

  {
      "Effect": "Allow",
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:你的区域:你的账号ID:function:stageTester:*"
  }
  

  用*通配符可以覆盖所有版本和别名，如果你想更严格，也可以明确写两个别名的ARN：arn:aws:lambda:...:stageTester:dev和arn:aws:lambda:...:stageTester:prod。
• 如果之前只给了调用函数本身的权限（比如arn:aws:lambda:...:stageTester），那API Gateway是无法调用别名的，必须更新权限策略。

3. 验证集成请求的配置细节 #

回到API Gateway的资源集成请求页面，确认以下几点：

• 集成类型确实选择的是Lambda函数，不是HTTP或其他类型。
• Lambda函数名称的格式完全正确：stageTester:${stageVariables.fname}，没有漏写${}，也没有把冒号写成其他符号。
• 如果你不确定变量解析是否有问题，可以先写死别名测试：比如在dev阶段的集成请求里直接写stageTester:dev，部署后测试是否能正常调用。如果能调用，说明是变量配置的问题；如果不能，说明是权限或Lambda本身的问题。

4. 确认API Gateway已经部署了最新更改 #

很多人配置完后忘记重新部署，导致更改没生效：

• 每次修改集成请求或阶段变量后，都要点击API Gateway控制台的部署按钮，选择对应的dev或prod阶段进行部署。
• 部署完成后，再测试调用，确保最新配置已经生效。

5. 检查Lambda别名与版本的关联是否正确 #

别光顾着API Gateway，也要确认Lambda端的配置：

• 进入Lambda控制台，找到stageTester函数，查看别名标签页。
• 确认dev别名确实指向你想要的开发版本，prod别名指向生产版本，没有把版本号搞混。
• 可以直接在Lambda控制台测试调用别名，确认别名本身能正常触发对应的版本，排除Lambda端的问题。

6. 查看日志定位具体错误 #

如果以上步骤都没问题，就需要通过日志找线索：

• 开启API Gateway的CloudWatch日志，在阶段设置里打开"启用CloudWatch日志"，设置日志级别为INFO或DEBUG。
• 调用API后，查看CloudWatch日志，里面会显示API Gateway尝试调用的Lambda函数ARN，你可以看这个ARN是不是正确的别名ARN（比如arn:aws:lambda:...:stageTester:dev）。
• 同时查看Lambda的CloudWatch日志，确认是否有请求到达，或者是否有权限错误等信息。

如果还是不行，你可以尝试用完整的ARN格式来配置集成请求，比如：

arn:aws:lambda:你的区域:你的账号ID:function:stageTester:${stageVariables.fname}

这种方式有时候能避免API Gateway对函数名的解析问题。

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