在AWS API Gateway与Lambda中发起POST请求时为何出现CORS错误？

API 探路者

2026-6-30

解决AWS API Gateway + Lambda的POST/PUT CORS错误方案

以下是几个实用的排查和修复要点：

确认OPTIONS集成已部署到对应阶段
即使你创建了OPTIONS的mock集成，也要确保配置已经重新部署到目标API阶段。API Gateway的配置变更必须部署后才会生效，不少情况预检看似返回200，但实际调用的还是旧配置。

精简Access-Control-Allow-Headers字段
当前你在OPTIONS和Lambda返回头中包含了Access-Control-Allow-Methods、Access-Control-Allow-Origin这类属于响应头的字段，这会触发浏览器的CORS校验失败。只保留前端实际发送的请求头即可，示例调整如下：

const response = {
    statusCode: 200,
    headers: {
        "Access-Control-Allow-Headers": "Content-Type,X-Amz-Date,X-Amz-Security-Token,Authorization,X-Api-Key,X-Requested-With,Accept",
        "Access-Control-Allow-Origin": "*",
        "Access-Control-Allow-Methods": "*"
    },
    body: JSON.stringify(''),
};

统一响应头的大小写格式
浏览器对CORS头的大小写敏感，建议将API Gateway配置和Lambda返回头的字段名统一格式（比如全小写或首字母大写），避免因大小写不一致导致校验不通过。
避免自动CORS配置与自定义OPTIONS集成冲突
如果你手动创建了OPTIONS的mock集成，就不要再使用API Gateway的「Enable CORS」按钮自动生成配置，两者可能产生冲突。建议删除自动生成的OPTIONS方法，仅保留自定义的mock集成。
检查POST/PUT请求的实际响应头
通过浏览器网络面板查看POST/PUT请求的响应头，确认Access-Control-Allow-Origin确实存在且值正确（*或指定域名）。如果Lambda函数抛出异常，API Gateway可能返回默认错误头，而非你定义的CORS头。
清除缓存影响
若API配置了缓存或前端使用CDN，可能缓存了旧的CORS配置。尝试清除浏览器缓存，或在API Gateway阶段设置中临时禁用缓存，验证问题是否解决。