AWS API Gateway与Lambda应用CORS配置后跨域请求400错误求助

我碰到过好几个开发者遇到和你一模一样的问题，别着急，咱们一步步拆解排查：

先抓准核心：400状态码才是关键 #

浏览器抛出的CORS错误很容易误导人，实际上400状态码说明你的请求在到达Lambda之前就被API Gateway拒绝了，这时候即使你配置了CORS，错误的响应也没法正确返回CORS头，导致浏览器报跨域错误。

先跳过浏览器，用Postman或者curl直接调用你的API，看看返回的具体错误信息——比如是不是请求体格式不符合API Gateway的配置（比如你没设置POST的请求模板，或者参数校验失败），先把400的根因解决掉。

检查CORS配置的细节 #

即使你点了"Enable CORS"按钮，也可能有配置遗漏：

• 确认你是在POST方法上启用的CORS，而不是只在API根资源或者其他方法上配置。很多人会犯这个错，根资源的CORS不会自动继承给子方法。
• 核对Access-Control-Allow-Origin：要么设为*（开发环境可以用），要么明确添加http://localhost:8888，别打错域名或者端口。
• 检查Access-Control-Allow-Headers：如果你的POST请求带了自定义头（比如Content-Type、Authorization），必须把这些头都加到这个列表里，少一个都不行。

别忘了Lambda的响应头（代理集成必看） #

如果你用的是Lambda代理集成，API Gateway不会自动帮你添加CORS头，必须让Lambda自己返回这些头！比如你的Lambda响应结构得是这样：

{
  "statusCode": 200,
  "headers": {
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Headers": "Content-Type, Authorization"
  },
  "body": "Success response"
}

要是非代理集成，那API Gateway的CORS配置应该会自动注入头，但也要确认集成响应里有没有正确映射这些头。

最重要的一步：重新部署API #

很多人配置完CORS就直接刷新浏览器测试，这是大忌！API Gateway的所有配置变更，必须部署到对应的阶段（比如dev、prod）才会生效。你点完"Enable CORS"按钮后，一定要去API的"Actions"菜单里选"Deploy API"，选好你的部署阶段，确认部署完成再测试。

最后排查浏览器缓存 #

有时候浏览器会缓存旧的CORS响应，导致新配置不生效。试试用无痕模式打开页面，或者清除浏览器缓存后再测试，排除缓存干扰。

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