为何OPTIONS预检请求晚于实际GET请求？（AWS API Gateway场景）

核心原因 #

浏览器触发OPTIONS预检的逻辑完全依赖服务器返回的CORS响应头，你遇到的顺序颠倒问题主要由以下几点导致：

• 旧CORS缓存干扰：之前配置Access-Control-Allow-Origin: *时，浏览器缓存了允许跨域的规则，后续切换到具体源后，浏览器首次请求仍按缓存逻辑跳过预检直接发GET；但服务器返回的新头不匹配缓存，浏览器才补发OPTIONS请求做二次校验。
• API Gateway CORS配置不统一：仅在根节点配置CORS可能覆盖不全，尤其是Lambda代理集成场景，必须保证API Gateway的OPTIONS响应头和Lambda函数返回的头完全一致，否则浏览器会出现校验逻辑混乱。
• Amplify请求预处理逻辑：Amplify API模块会根据历史请求的CORS结果做预判断，当检测到过*的允许记录时，会跳过预检直接发送请求，后续因头不匹配触发补检流程。

解决步骤 #

• 清空浏览器缓存：直接清除当前域名的存储缓存（Chrome：F12→Application→Clear storage），彻底清除旧的CORS规则缓存。
• 统一CORS配置：
  • 在API Gateway中，为所有需要跨域的资源（包括根节点）配置OPTIONS方法，确保返回以下响应头：
    • Access-Control-Allow-Origin：设置为你的前端精确域名（不要模糊匹配）
    • Access-Control-Allow-Methods：包含GET,OPTIONS及你业务需要的其他方法
    • Access-Control-Allow-Headers：列出Amplify请求携带的所有自定义头（比如Authorization、Content-Type等）
  • 若使用Lambda代理集成，Lambda函数返回的响应头必须和API Gateway配置的CORS头完全一致，禁止出现冲突（比如API Gateway设具体源，Lambda返回*）。
• 调整Amplify请求配置：在调用API时，显式设置withCredentials: false（如果不需要携带Cookie），同时确保请求携带的所有头都在CORS允许列表内，避免浏览器因未知头触发异常校验。

补充说明 #

浏览器的预检逻辑规则：

• 简单请求（GET/POST，仅含Accept、Content-Type等标准头）无需预检，直接发送实际请求，服务器返回CORS头做校验；
• 非简单请求（带自定义头、PUT/DELETE等方法）才会先发送OPTIONS预检。

你遇到的顺序异常本质是缓存的旧规则与新配置冲突，导致先发送GET后触发补检；而设置*时，浏览器缓存策略更宽松，不会触发后续补检，所以顺序看起来正常。

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