这就是CORS的工作原理。这基本上是一次握手，说是的，欢迎你和我交谈。除非联系第三方，否则你不知道这是否可能。
我想更好地理解这一点。我目前使用的心理模型是这样的：
- 在foo.com托管的JS希望访问bar.com托管的资源。这不是浏览器喜欢向用户公开的事情，除非可以表明bar.com欢迎这个请求
- 因此，foo.comJS本质上将请求分成两半。首先，我们通过XMLHttpRequest对象发送一个适当类型的无数据请求(GET、POST等)。bar.com上的服务器返回它通常会响应的基本上任何请求，这些请求可能包括也可能不包括Access Control Allow Origin标头。(编辑：这是一个误解-请参阅下面apsillers的精彩评论)
- 如果浏览器确实得到了这样的头，它会扫描它以寻找Origin(在本例中为foo.com)。如果存在，它会继续发送被要求发送的实际请求。如果没有，它会拒绝。(编辑：这也不太正确)
如果这个模型是正确的，我很困惑为什么浏览器会发送带有这个初步请求的Origin标头。不是在客户端进行匹配检查吗？发送此标头的目的是什么？
以下是MDN文章Preflighted_requests部分的部分内容：
与简单的请求(如上所述)不同，"预先点燃"的请求优先将HTTP OPTIONS请求标头发送到另一个域，以便确定实际请求是否安全邮寄跨站点请求是这样预处理的，因为它们可能对用户数据有影响。特别是，请求预燃条件：
它使用GET或POST以外的方法。此外，如果POST用于发送请求内容类型不是application/x-www-form-urlencoded、multipart/form-data或text/plain，例如，如果POST请求使用application/xml或text/xml，则该请求将被预先触发。它设置请求中的自定义标头(例如，请求使用诸如X-pinghother)