注：本文不講cors原理，且預設你已了解cors，但對其中一些細節抱有同樣的懷疑首先可以肯定的是，同源策略的限制是合理的。因為，服務端後台介面就部署在那，任何人只要構造了乙個正確的http請求，都能得到伺服器的應答。但很顯然，我們不希望我們的介面任何人都能訪問(事實上，因為大家採用的都是同一套http標準，所以你永遠也無法杜絕這件事的發生)。還有乙個更直接的理由，越多人知道你的介面，你的介面就越危險。
但是既然存在跨域的普遍呼聲，那麼這個需求也是合理的。所以乙個新的跨域規範誕生了，再也不需要醜陋的jsonp，更不需要域內**浪費資源。這個規範叫，cors(cross-origin-resource-sharing)-跨域資源共享。cors需要服務端與客戶端同時支援，客戶端就是指瀏覽器，目前所有瀏覽器最新版本都已支援，如下圖所示：
服務端的支援，常規做法是，在**中用全域性***做處理。
在講伺服器的支援邏輯之前，先講個擴充套件話題。瀏覽器限制跨域請求，實際上有兩種方式：
---請求正常發起，攔截返回資料
---在請求發起前攔截住
事實上，絕大多數瀏覽器都是採用第一種方式。看到這裡我倒吸一口涼氣，那也就是說，你的請求成功了，資料庫也產生了修改，但是瀏覽器卻告訴你，你的請求被禁止了。這就好比，張三**了隔壁老王的女朋友，有乙個警察也在現場，但是他卻等張三**完了才告訴他，他的行為是違法犯罪。
天吶，這是多麼愚蠢的乙個設計，而且竟然幾乎所有瀏覽器都是這麼幹的，一幹就是十幾年。我不否認他們這麼做可能出於一些不得已的苦衷。所以這次的cors規範就是為了填補這個漏洞，主要手段是使用預檢請求。這就好比，在張三脫褲子之前，警察先問了女方是否願意。
我們知道，所謂預檢請求，都是通過options請求方法發出的。需要注意的是，預檢請求不會攜帶任何的請求引數，所以你不需要擔心資料庫會被修改兩次。伺服器需要做的就是，在全域性***中，設定access-control-allow系列跨域頭。
問題就出在這個跨域頭這裡。需要設定的跨域頭主要有三個：
access-control-allow-origin: 允許訪問的網域名稱
access-control-allow-methods: 允許使用的請求方法
access-control-allow-headers: 允許使用的請求頭
第乙個，沒問題，很合理。因為我確實要限制非法**過來的請求
第二個，也沒毛病。因為確實存在，某些controller只支援特定的http方法。restful介面中這種限制體現得尤為明顯。
問題出在第三個
第三個，就特麼非常皮了。這個是用來告訴前端，我允許你接下來的請求附帶哪些請求頭。或許換個說法更容易暴露它的不合理，就是，我伺服器支援哪些請求頭。需要注意的是，這裡必須把所有支援的請求頭都填上。天吶，要知道，所有的http請求頭，基本的，常見的，不常見的，加起來有幾十個呢。如果伺服器要全部支援，就要把所有的請求頭都填進去。這將是非常枯燥，而且不必要的工作。
增加了**量是一方面，還有另乙個更充分的理由來反駁它。讓我們用伺服器解析請求頭的偽**來說明一下。
if(支援這個請求頭的解析)else
}elseelse
}
js的設計缺陷
原文請搜阮一峰 一 js為什麼有缺陷 1。設計階段過於倉促 設計者只用十天時間完成js的設計，而且設計初衷只是為了完成簡單的網頁互動，並沒有考慮複雜應用的需要 2。設計借鑑太雜 設計者本身擅長函式式程式設計，但由於某些原因又需要將js往物件導向上靠。又因為只想做一種簡單的指令碼語言就放棄了 類 的想...
類的設計缺陷
這是乙個很無意識的錯誤。class example 需求是這樣的。我有乙個輸入，我需要對其進行合法性的檢測，然後給出處理結果。我之前的認知都是，乙個function實現乙個功能，所以自然而然的，我設計出了這樣的乙個class。師傅看了一眼就指出了我其中的問題，如下所示 問題這樣的乙個class，會增...
UI設計中的過度釋放
昨天在做相簿的時候遇到了乙個問題,系統沒有報錯,但在執行後總是crash,來回找錯好幾次也沒有發現錯誤,後來才發現是記憶體管理出了問題.在viewcontroller中,我宣告了乙個 uipagecontrol page 的屬性,但是在實現的時候,一時粗心大意我將 self page uipagec...