AWS API Gateway配置CORS遇问题：OPTIONS生效GET无响应头求助

我之前也踩过一模一样的坑，折腾了好一会儿才找到根源，给你几个实用的排查方向：

• 先确认API是否重新部署了
  这是最容易忽略的关键步骤！在API Gateway控制台配置完CORS后，一定要点击「Deploy API」并选择对应的部署阶段（比如prod）。很多时候配置改了但没部署，导致新的CORS规则根本没生效。

• 检查CORS配置是否覆盖了GET方法
  如果你只是手动给OPTIONS方法加了CORS头，GET方法不会自动继承规则。正确的做法是在对应的资源节点上点击「Enable CORS」，在弹出的配置框里：

  • 确保Access-Control-Allow-Methods里包含GET（比如填OPTIONS,GET）
  • 正确设置Access-Control-Allow-Origin（比如*或者你的前端域名）
  • 填写需要允许的Access-Control-Allow-Headers
    保存后再重新部署一次API，这样所有关联的方法都会应用这个CORS配置。

• 检查集成响应和方法响应的头配置
  如果你的API用了非代理集成（Lambda Proxy Integration关闭的情况）：

  1. 进入GET方法的「Method Response」，确认已经添加了Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers这几个响应头
  2. 再到「Integration Response」里，把这些头映射到对应的值（比如Access-Control-Allow-Origin的值设为'*'或者你的域名）
     如果是代理集成，API Gateway会直接返回Lambda的响应头，这时候要么保持你现在的临时方案（Lambda返回头），要么在「Method Response」里添加这些头，确保Lambda返回的头和配置不冲突。

• 排除缓存或CDN干扰
  浏览器可能缓存了旧的响应，导致新的CORS头没显示出来。试试用无痕模式测试，或者清除浏览器缓存。如果你的API前面挂了CloudFront之类的CDN，也要在CDN的缓存策略里配置允许传递这些CORS头，否则CDN会把旧的响应缓存下来。

• 验证调用的API阶段是否正确
  有时候你把配置部署到了测试阶段，但实际调用的是生产阶段的API URL，自然看不到新的CORS头。确认一下你调用的URL里的阶段名称（比如https://xxx.execute-api.us-east-1.amazonaws.com/prod里的prod）和你部署的阶段一致。

一般按照这个顺序排查，就能找到问题所在了，不用一直依赖Lambda硬编码头的临时方案。

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