我正在阅读关于 CORS 请求的 spec，我发现这是关于预检请求的：
这些是对具有 HTTP 请求的非同源 URL 的请求 GET 以外的方法，首先需要使用 预检结果缓存条目或预检请求。
我认为预检请求的目的是在发出请求之前检查是否允许请求，以防它（非法）更改服务器状态。
但 HEAD 和 OPTIONS 不会修改服务器状态。我一定误解了预检的原因。
对 HEAD 和 OPTIONS 而不是 GET 进行预检的目的（也称为原因、动机或原理）是什么？ GET 有什么特别之处？
【问题讨论】：
标签： cross-domain cors http-method preflight
预检的主要目的是确保服务器不会突然发送基于浏览器的跨域请求，而这些请求在 CORS 规范实施之前是不可能收到的。
在 CORS 规范之前，除了 GET 或 POST 之外，不可能发送任何基于浏览器的跨域请求。浏览器根本不允许您启动 XHR 实例，将方法设置为 PUT（例如）并将其发送到不同来源的端点。您也无法通过 XHR 发送 GET 或 POST 跨域请求，但您可以通过表单提交发送跨域 GET 或 POST，或通过 <img> 或 <script> 标签发送跨域 GET，例如示例（这使得 JSONP 成为 CORS 之前的唯一选项）。一旦浏览器实现了 CORS 规范，情况就发生了变化。如果服务器选择加入，现在可以发送任何跨域 ajax 请求。
CORS 规范定义了“简单”方法（GET 和 POST）以及“简单”请求标头。这些对应于您已经可以从浏览器 pre-CORS 规范发送的跨域请求类型。不能从浏览器 pre-CORS 规范发送非简单的跨域请求，例如带有 X 标头的 PUT 或 POST/GET 请求（例如）。因此，对于这些类型的请求，预检的概念被写入规范中，以确保服务器在没有明确选择加入的情况下不会接收这些类型的非简单跨域基于浏览器的请求。换句话说，如果你不要允许这些类型的请求，您根本不必更改服务器。预检将失败，浏览器将永远不会发送底层请求。
直接解决您的问题：HEAD 请求通常不会导致预检。根据 CORS 规范，HEAD 被认为是一种简单的请求方法。如您所知，HEAD 请求只是没有响应负载的 GET。这是 HEAD 和 GET 请求被视为相同的最可能原因，即使您无法从浏览器发送跨域 HEAD 请求 pre-CORS。如果您的 HEAD 包含非简单的标头，它将被预检，就像 GET 一样。
【讨论】：