在「no-cors」模式下使用 Fetch
Fetch API 提供了一種向伺服器發出請求的便利方法。但是，跨網域存取資源時，可能會遇到「請求的資源上不存在『Access-Control-Allow-Origin』標頭」的錯誤。此錯誤表示同源策略施加的安全限制。
要在 Fetch 停用 CORS，很容易使用 { mode: 'no-cors' } 選項。然而，這種方法是不正確且不可取的。
'no-cors'模式：一個錯誤
'no-cors'模式本質上阻止了瀏覽器存取回應正文和標題。這意味著您的程式碼將無法處理或使用所獲取的資料。重要的是要了解停用 CORS 不會覆蓋同源策略。它只會影響瀏覽器處理回應的方式。
解決方案：CORS 代理
您應該使用 CORS 代理，而不是停用 CORS。代理充當前端程式碼和目標伺服器之間的中介。當您透過代理程式傳送請求時，它會將請求轉送到伺服器，接收回應，並在將其傳回程式碼之前新增必要的 Access-Control-Allow-Origin 標頭。這允許您的程式碼跨來源存取回應。
要設定 CORS 代理，您可以使用現有服務或使用 Heroku 等平台部署自己的代理。
了解跨域請求
需要注意的是，即使你可以在Postman中跨域存取資源，瀏覽器也會強制對Web 應用程式中運行的前端程式碼的限制。為了確保跨來源資源訪問，回應必須包含 Access-Control-Allow-Origin 標頭。
不透明回應：警告
雖然 'no-cors'模式停用 CORS，它也會建立不透明的回應。不透明回應有一定的限制，包括：
因此，僅在特定情況下才應考慮使用“no-cors”，例如在某些HTML 元素中快取和嵌入資源。
結論
以「no-cors」模式停用 CORS 並不是跨域資源存取的解決方案。相反，使用 CORS 代理是首選方法。透過彌合前端和目標伺服器之間的差距，代理程式添加了必要的標頭，使您的程式碼能夠跨來源無縫運作。
以上是為什麼使用 Fetch 的'no-cors”模式不是處理跨來源請求的解決方案？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
