通用的跨域處理方案
如果你是一枚前端工程師术吝，我想應該或多或少對瀏覽器跨域請求有一些了解转捕。
跨域的詳細知識园细，就不再這篇文章里贅述了。
不太了解或者有興趣了解一下的童鞋可以參考下 mdn 上的這篇文章：Cross-Origin Resource Sharing (CORS) - HTTP | MDN昔馋。
文章內(nèi)容寫的很詳盡筹吐，相信你看完以后，一定會有種恍然大悟的感覺秘遏。
既然這篇文章丘薛，是想要記錄下踩坑的歷程，接下來肯定得詳細記錄下邦危，坑出現(xiàn)在哪兒了洋侨。
一般情況下，出現(xiàn)需要跨域請求之時倦蚪，對于要求不高的地方希坚，直接改下 web 服務器的配置，允許所有的跨域請求即可陵且，這也是最隨意的做法裁僧。
簡而言之，也就是直接朝響應頭里添加 Access-Control-Allow-Origin: * 參數(shù)，代表能正常響應所有的跨域請求聊疲。
不過就像我前面所說的那樣茬底，之所以說隨意，是因為获洲，允許所有的跨域請求阱表，是一種不太安全的行為，任何網(wǎng)站都可以隨意的使用你提供的 web 服務贡珊。
甚至于最爬，會讓自己網(wǎng)站陷入跨域攻擊的危險之中。
當然飞崖，如果你本身就想要提供公開的數(shù)據(jù)烂叔、業(yè)務接口，那么就可以直接采用上面那種簡單粗暴的方式固歪。
但是，如果不是出于上述目的的話京痢，那么則不建議直接采用上面省事兒的方式拱撵。
一般我們可以采用增加白名單的方式参咙，也就是只允許目標網(wǎng)站的請求，能夠正常的響應：Access-Control-Allow-Origin: https://foo.example
復雜請求導致之前的跨域配置失效
而我們在實際應用的過程中蒲讯，出于安全性考慮，一般都是由后端童鞋直接在 nginx 上統(tǒng)一進行跨域的配置灰署，當然判帮，肯定是采用第二種方式。
之前的項目采用這種配置方式溉箕，沒有任何的問題晦墙。
但是最近做的一個項目，對于用戶權限這一塊肴茄，我們采用 token 的方式來處理晌畅，為了方便起見，直接將 Authorization 字段配置在請求頭里了寡痰，方便對 api 請求進行權限控制抗楔。
但是在本地調(diào)試的時候，發(fā)現(xiàn)出現(xiàn)了跨域問題拦坠，接口死活調(diào)不通连躏。
這個時候，可能有童鞋就要問了贞滨，現(xiàn)在不一般用 webpack 打包入热，在 webpack 的 devserver 里配置一下 proxy 模式不就行了。
起初碰到這個問題的時候，我也打算采用這個方式來解決才顿，因為按照以往的經(jīng)驗來說莫湘，webpack devserver 相當于是起了一個 express 服務器，用它直接代理下我們的請求郑气，就能避免前端跨域問題了幅垮。
但是不知道后端童鞋提供的 web 服務做了什么限制，走 express 代理的話尾组，請求死活要過一分鐘才會姍姍來遲的響應忙芒，與后端童鞋溝通過，無果讳侨，沒找到解決方案呵萨，遂放棄了這種方式。
既然 express 代理的方式不可行跨跨，那就只能硬著頭皮研究一下潮峦，為何明明配置了跨域，還是會提示跨域勇婴，死活調(diào)不通接口呢忱嘹。
在找問題的過程中，我一度陷入了自我懷疑了耕渴。
為了確認不是前端代碼層面的問題拘悦，確實是跨域?qū)е碌膯栴}。我將項目打包以后朝服務器部署了一份橱脸，在非跨域的時候訪問础米，果然一切正常，接口能正常請求到數(shù)據(jù)了添诉。
這說明屁桑，確實是跨域引起的問題，正如 chrome 的 devtools 提示的那樣吻商。
這時候掏颊，我靈機一動，為啥我不換個瀏覽器試試呢艾帐？
于是我用 firefox 測試乌叶，嘗試重新調(diào)用后臺接口請求數(shù)據(jù)，才終于發(fā)現(xiàn)問題所在柒爸。
原來是因為預檢請求（option）沒有配置允許跨域准浴，導致請求后臺接口的時候一直失敗，并且剛好還提示是跨域的問題捎稚。
為啥 chrome 的 devtools 沒有清楚的顯示出來乐横，是因為預檢請求導致跨域調(diào)用接口失敗了呢求橄？
帶著這樣的疑問，我 google 了一下葡公，原來是因為從 Chrome 79 版本開始罐农，preflight cors request 相關信息就被隱藏掉了，變成了隱藏功能催什，并且從 2020.01.06 開始涵亏，這個功能將被徹底隱藏掉，不再提供相關功能了蒲凶。
詳細情況气筋，可以閱讀下相關頁面：OOR-CORS: Out of Renderer CORS
說實話，說這個消息令我震驚也不為過了旋圆。
因為以前我用 chrome 的時候宠默，確實發(fā)現(xiàn)他支持顯示 cors 相關的信息，后來我潛意識里一直就以為灵巧，這個功能一直是存在的搀矫。
我壓根就不會想到，這個功能會在 chrome 里被砍掉孩等。
可怕的是艾君，用了這么久，我居然一直沒有發(fā)現(xiàn)肄方，居然存在這樣的問題。
只能說以前之所以沒發(fā)現(xiàn)問題蹬癌，是因為恰好沒碰到過這樣的問題权她，在多種因素的作用下，導致最近這個問題才浮出水面逝薪，終于被我發(fā)現(xiàn)了隅要。
我稍微回想了一下，之所以現(xiàn)在才意識到這個問題董济，有幾個方面的原因：
- 有些情況下步清，直接配置了
Access-Control-Allow-Origin: *，導致根本不會遇到會有跨域的問題出現(xiàn) - 有些情況下虏肾，都是簡單請求廓啊，不會觸發(fā)預檢請求
- 有些情況下，即使出現(xiàn)需要預檢請求封豪，可能也針對所有的請求進行過配置谴轮，不像這位同事的做法，只是針對 get吹埠、post第步、put 等請求進行了跨域配置
所以我更加深刻的理解了疮装，有時候，項目的代碼能正常跑起來粘都，確實是無數(shù)個巧合拼湊在一起的結(jié)果廓推，要是沒有深刻的理清各種技術的細枝末節(jié)，一旦出了點 bug翩隧，就會困擾很久樊展，才能發(fā)現(xiàn)問題所在。
而且鸽心，這個問題滚局，在越大、越復雜的項目中顽频，更容易顯現(xiàn)藤肢。
水落石出
閑話不多說，拉回到我們的正題糯景。
既然我們現(xiàn)在已經(jīng)發(fā)現(xiàn)問題所在了嘁圈，聊聊解決方案吧。
如果你也用 nginx 的話蟀淮，可以像這樣配置一下最住，針對所有的預檢請求，允許其跨域怠惶，并返回 204涨缚，就能解決 option 跨域的問題了。
當然如果你不想允許所有的域名都能跨域發(fā)送預檢請求策治，并被服務器正常響應脓魏，把 * 改成允許的域名的列表就好了。
碰到了這個問題后通惫，也讓我開始思考之前大家一直討論過的問題茂翔，chrome 開始壟斷桌面端服務器的市場，讓 google 都快成為 web 標準協(xié)議的制定者了履腋，這其實并不是一種好現(xiàn)象珊燎。
屠龍勇士最終也終于變成了惡龍。
這個故事遵湖，應用在 chrome 和 ie 身上悔政，同樣適用。
所以為了反對壟斷奄侠，我們更應該多支持下卓箫，用起來不是那么順手的一些軟件。
這放在任何領域都是適用的垄潮，有了競爭才有差異化烹卒，才會想著提升產(chǎn)品闷盔、提升服務，一家獨大旅急、壟斷逢勾，無論是對于科技的進步還是普通用戶的利益來說，都是有害的藐吮。
