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