AWS CDK部署S3静态站+CloudFront+API网关架构下接口调用报CORS错误

报错本质是多层配置叠加产生的规则冲突，并非单一配置缺失，以下是对应配置的错误/遗漏点 #

核心错误点排查 #

• 凭证与通配符来源的浏览器兼容性冲突
  你当前的CORS配置同时设置了AllowOrigins = Cors.ALL_ORIGINS和AllowCredentials = true，这是浏览器侧明确禁止的组合：只要请求开启了凭证模式（携带Cookie、自定义Authorization头等），Access-Control-Allow-Origin响应头绝对不能返回通配符*，必须为精确的来源域名（即你的CloudFront站点地址https://abcdefg.cloudfront.net），否则浏览器会直接拦截响应，不管其他头是否配置正确。
• 业务请求的响应头缺失
  你的配置仅给OPTIONS预检请求配置了CORS头，但实际触发报错的是POST业务请求本身。这个POST请求的响应（也就是你Lambda处理POST分支返回的结果）里没有附带Access-Control-Allow-Origin头，预检流程通过后，真正的业务响应因为缺失CORS头被浏览器拦截。
• CDK v1.87.1版本AddCorsPreflight的行为误解
  该版本的AddCorsPreflight方法仅负责在API Gateway层面创建独立的OPTIONS方法响应，完全不会影响其他业务方法的返回头。很多使用者误以为加了这个方法就全局生效，实际上业务方法的CORS头必须单独配置。
• 重复配置冲突
  你既在CDK层面给资源挂载了CORS预检（由API Gateway直接返回OPTIONS响应，不会透传到Lambda），又在Lambda代码里写了OPTIONS请求的处理逻辑。实际运行时Lambda里的OPTIONS分支根本不会被执行，两套配置同时存在会导致路由冲突，返回的CORS头参数和你预期的不一致。
• CloudFront配置的冗余副作用
  你在CloudFront行为配置里把Access-Control-Allow-Origin加入了请求转发列表，这个头是API Gateway返回给浏览器的响应头，而非浏览器发给源站的请求头，根本不需要被转发到S3源站，这类冗余的转发规则可能会意外过滤掉正常的响应头。
• 预检缓存配置不合理
  你设置MaxAge = Duration.Days(0)相当于完全禁用了预检结果缓存，每次业务请求前都会强制发一次OPTIONS请求，排查过程中容易混淆预检和业务请求的响应差异。

修复步骤 #

• 调整CORS配置的兼容组合：如果业务请求不需要携带凭证（Cookie、自定义授权头），直接把AllowCredentials设为false，此时使用Cors.ALL_ORIGINS是符合浏览器规范的；如果需要携带凭证，必须把AllowOrigins改为精确的来源列表（如仅允许你的CloudFront站点域名），不能搭配通配符使用。
• 为所有业务方法的Lambda返回值统一加上CORS响应头：不要只在OPTIONS分支加，所有GET/POST/PUT/DELETE的返回结构里，都要在headers字段带上正确的Access-Control-Allow-Origin值，确保业务请求的响应本身携带合规的CORS头。
• 清理重复的OPTIONS处理逻辑：二选一即可，推荐使用CDK的AddCorsPreflight在API Gateway层面处理预检（减少Lambda冷启动开销），此时可以完全删除Lambda里的OPTIONS分支代码；如果坚持用Lambda处理预检，就去掉资源上挂载的AddCorsPreflight配置，避免路由冲突。
• 移除CloudFront配置里冗余的Access-Control-Allow-Origin转发规则：仅保留业务需要的请求头转发（如Authorization），不要转发响应侧的头字段。
• 调整MaxAge为合理值（如10分钟），减少不必要的OPTIONS请求频次。

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