调用不同的域时，在实际POST、UPDATE、PUT或DELETE请求之前发送OPTION请求的原因是什么？（以此类推，在 CORS 请求上）我知道它应该检查服务器是否可以处理真正的请求，但为什么不立即发送真正的请求呢？
我想过的一些原因：
- 查看该方法是否受支持
- 发送真实请求将返回相同的状态代码，因此无需先发送
OPTION请求。
- 发送真实请求将返回相同的状态代码，因此无需先发送
- 检查用户是否允许发送请求
- 没有意义，因为没有身份验证标头与
OPTION请求一起发送
- 没有意义，因为没有身份验证标头与
- 防止服务器上的负载过重
- 没有意义，因为检查身份验证规则是在处理数据之前。
- 检查是否允许请求的标头和源
- 这就是它现在的工作方式，但同样为什么不直接发送请求，我们可以从真实请求中读取错误。
- 阻止发送帖子数据（如果它不会被处理）
- 这是唯一有效的原因。使用选项请求将防止不必要地将帖子数据发送到服务器。但是，我认为这在99%的时间内都不是问题，因为只发送了一小部分数据。
有人可以阐明浏览器供应商在调用不同域时实现OPTION请求的原因吗？
CORS 基本上是一个浏览器安全功能，而不是服务器端。
默认情况下，浏览器不允许某些跨源请求。您正在与之交谈的服务器可以发布使用跨源请求是否安全，但理解和使用这些信息并因此提供保护的是客户端，而不是服务器。
因此，对于 GET 请求，您可以获取资源，检查 CORS 标头，然后根据标头决定是否处理它。很好，很简单。
对于 POST（或其他不断变化的）事件来说，事情就不是那么简单了。您发出 POST 请求，服务器处理它（请记住，服务器不关心 CORS，只关心浏览器）并发回响应。浏览器看到 CORS 未启用并忽略响应，但此时为时已晚 - POST 请求已在服务器端处理，阻止的只是显示已处理的结果。因此，例如，对于网上银行应用程序，恶意转移资金的请求意味着资金将被转移，但您的浏览器将忽略"资金转移成功"响应 - 大不了，当钱消失时，损害已经造成，恶意请求可能会忽略响应无论如何！
因此，在知道响应上的 CORS 标头是什么之前，您无法发送请求 - 这需要发送请求！先有鸡还是先有蛋的情况。
因此，浏览器将 OPTIONS 请求发送到同一地址，该地址不会像 POST 请求那样更改任何内容，但会返回 CORS 标头。之后，浏览器知道发送真实请求是否安全。
顺便说一句，服务器不实现 CORS 安全性的原因是更改 Referrer 标头非常容易，因此无论如何它都不会提供任何保护。服务器将具有其他安全功能（例如，检查会话是否有效并有权发出请求），但CORS旨在防止的攻击是这些无济于事的攻击（例如，用户在另一个选项卡上登录其网上银行）。