Angular 11 如何通过API Gateway向AWS Lambda POST application/json

你遇到的请求失败属于浏览器跨域预检（CORS Preflight）拦截，请求未到达Lambda后端、无CloudWatch日志完全符合该问题的特征。

不同场景结果差异的逻辑解释 #

之前测试出现的「部分请求正常、部分请求被拦截」的表现，可通过跨域规则完全对应：

• 浏览器将满足以下条件的跨域请求判定为「简单请求」，直接发送真实请求，不触发预检：无自定义请求头、Content-Type仅为application/x-www-form-urlencoded/multipart/form-data/text/plain。这就是你从Angular发送form-urlencoded格式POST请求可正常运行的原因。
• 只要请求携带Content-Type: application/json这类非简单请求要求的头，浏览器会自动先发一个OPTIONS方法的预检请求，向服务端确认是否允许跨域调用；预检不通过会直接终止真实请求发送。
• curl工具不执行浏览器的CORS安全限制，因此手动用curl发送JSON POST可以正常访问接口。
• 本地SAM、NestJs服务默认开启完整CORS配置，对OPTIONS预检请求有正确响应，因此本地环境所有请求均可正常运行。

根因定位 #

你的AWS托管API Gateway配置存在缺失：

• 仅为POST方法配置了CORS响应规则，没有为OPTIONS预检请求配置独立的路由与响应逻辑。
• 配置CORS规则时，漏配了Access-Control-Allow-Headers字段对Content-Type头的放行。
• API Gateway收到未配置路由的OPTIONS请求时，会直接返回403拦截，不会将请求转发到Lambda触发业务逻辑，因此请求全程不会被CloudWatch记录。

修复操作清单 #

• 为API Gateway对应的业务路由单独添加OPTIONS方法配置，使用Mock集成即可（预检请求不需要走到Lambda业务逻辑），返回必需的CORS响应头：
  • Access-Control-Allow-Origin：填写你的Angular Amplify应用的实际域名
  • Access-Control-Allow-Methods：配置为POST, OPTIONS
  • Access-Control-Allow-Headers：明确加入Content-Type
• 如果你使用SAM通过template.yaml部署API，检查CORS配置块的AllowHeaders字段，确保显式声明放行Content-Type
• 验证修复效果：打开浏览器开发者工具的网络面板，观察对应接口的OPTIONS请求状态，只要该请求返回200且携带完整CORS响应头，后续的JSON POST真实请求就可以正常发送到Lambda。

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