僅當瀏覽器認為請求可能導致服務器端變異時，跨源請求才會進行預檢。如果您進行跨源的 XMLHttpRequest /fetch 請求，它會被分類為兩種類別之一：“簡單請求” 或 “預檢請求”。
簡單請求是指那些（按照慣例）可以安全地依賴實際請求來確定 CORS 策略的請求。我說 “按照慣例” 是因為 REST / HTTP 並不強制要求僅在 GET 請求上進行讀取，或者 PUT 將創建或替換，這只是慣例。
無論如何，如果您的請求使用 HEAD / GET 方法，瀏覽器可以假設在處理此請求時，源服務器不會進行任何變異，因此它只會在實際請求的響應中尋找 Access-Control-Allow-Origin 標頭，也就是從實際請求中推斷 CORS 策略。這被認為是安全的，並且可以節省一個往返。
但是，對於 PUT / DELETE，發送實際請求可能會觸發服務器端變異（例如在數據庫中創建或刪除行），因此瀏覽器需要確保在發送實際請求之前，允許進行此請求的源。它無法依賴實際請求來推斷 CORS 策略，因為這樣做會達到 CORS 的目的 - 源能夠在沒有明確許可的情況下變異主機。當然，源可能無法看到主機的響應，但損害已經造成。這就是為什麼瀏覽器必須 “預檢” 實際請求，也就是發送一個單獨的（OPTIONS）請求，明確詢問主機是否允許發送意圖發送的請求。這個（預檢）OPTIONS 請求具有 Access-Control-Request-Method 標頭，描述實際請求的方法，以及 Access-Control-Request-Headers，列出實際請求將具有的標頭。只有當主機服務器表示允許源使用 Access-Control-Request-Method 中的方法和 Access-Control-Request-Headers 中的標頭發送請求時，實際請求才會發送出去。
是否預檢請求的決定完全由客戶端（在大多數情況下是 Web 瀏覽器）決定。它在 CORS 協議的範圍內盡力避免發送額外的請求。不幸的是，這個決定不僅僅基於請求方法，還有可能導致甚至對 GET 請求進行預檢的邊緣情況。
MDN 的 CORS 文檔實際上是一個很好的閱讀材料，並且詳細介紹了瀏覽器如何決定是否需要預檢請求。