近期實習期間接手了乙個購物的電商管理系統的前端專案，在寫**的過程**現錯誤，而且在控制台列印了太多次不同錯誤狀態碼，一直不停的去搜尋，查詢解決辦法，今天將自己遇到的幾個常見的狀態碼，以及搜尋出來的總結一下。不對的地方希望大家多多提意見。分享
200請求已成功，請求所希望的響應頭或資料體將隨此響應返回。出現此狀態碼是表示正常狀態。
201請求已經被實現，而且有乙個新的資源已經依據請求的需要而建立，且其 uri 已經隨location 頭資訊返回。假如需要的資源無法及時建立的話，應當返回 '202 accepted'。
300被請求的資源有一系列可供選擇的回饋資訊，每個都有自己特定的位址和瀏覽器驅動的商議資訊。使用者或瀏覽器能夠自行選擇乙個首選的位址進行重定向。
除非這是乙個 head 請求，否則該響應應當包括乙個資源特性及位址的列表的實體，以便使用者或瀏覽器從中選擇最合適的重定向位址。這個實體的格式由 content-type 定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動作出最合適的選擇。當然，rfc 2616規範並沒有規定這樣的自動選擇該如何進行。
如果伺服器本身已經有了首選的回饋選擇，那麼在 location 中應當指明這個回饋的 uri；瀏覽器可能會將這個 location 值作為自動重定向的位址。此外，除非額外指定，否則這個響應也是可快取的。
301被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個 uri 之一。如果可能，擁有鏈結編輯功能的客戶端應當自動把請求的位址修改為從伺服器反饋回來的位址。除非額外指定，否則這個響應也是可快取的。
新的永久性的uri 應當在響應的 location 域中返回。除非這是乙個 head 請求，否則響應的實體中應當包含指向新的 uri 的超連結及簡短說明。
如果這不是乙個 get 或者 head 請求，因此瀏覽器禁止自動進行重定向，除非得到使用者的確認，因為請求的條件可能因此發生變化。
注意：對於某些使用 http/1.0 協議的瀏覽器，當它們傳送的 post 請求得到了乙個301響應的話，接下來的重定向請求將會變成 get 方式。
302請求的資源臨時從不同的 uri響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有位址傳送以後的請求。只有在cache-control或expires中進行了指定的情況下，這個響應才是可快取的。
上文有提及。
如果這不是乙個 get 或者 head 請求，那麼瀏覽器禁止自動進行重定向，除非得到使用者的確認，因為請求的條件可能因此發生變化。
注意：雖然rfc 1945和rfc 2068規範不允許客戶端在重定向時改變請求的方法，但是很多現存的瀏覽器將302響應視作為303響應，並且使用 get 方式訪問在 location 中規定的 uri，而無視原先請求的方法。狀態碼303和307被新增了進來，用以明確伺服器期待客戶端進行何種反應。
304如果客戶端傳送了乙個帶條件的 get 請求且該請求已被允許，而文件的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則伺服器應當返回這個狀態碼。304響應禁止包含訊息體，因此始終以訊息頭後的第乙個空行結尾。
該響應必須包含以下的頭資訊：
date，除非這個伺服器沒有時鐘。假如沒有時鐘的伺服器也遵守這些規則，那麼**伺服器以及客戶端可以自行將 date 字段新增到接收到的響應頭中去（正如rfc 2068中規定的一樣），快取機制將會正常工作。
etag 和/或 content-location，假如同樣的請求本應返回200響應。
expires, cache-control，和/或vary，假如其值可能與之前相同變數的其他響應對應的值不同的話。
假如本響應請求使用了強快取驗證，那麼本次響應不應該包含其他實體頭；否則（例如，某個帶條件的 get 請求使用了弱快取驗證），本次響應禁止包含其他實體頭；這避免了快取了的實體內容和更新了的實體頭資訊之間的不一致。
假如某個304響應指明了當前某個實體沒有快取，那麼快取系統必須忽視這個響應，並且重**送不包含限制條件的請求。
假如接收到乙個要求更新某個快取條目的304響應，那麼快取系統必須更新整個條目以反映所有在響應中被更新的字段的值。
4001、語義有誤，當前請求無法被伺服器理解。除非進行修改，否則客戶端不應該重複提交這個請求。
2、請求引數有誤。
401當前請求需要使用者驗證。該響應必須包含乙個適用於被請求資源的 www-authenticate 資訊頭用以詢問使用者資訊。客戶端可以重複提交乙個包含恰當的 authorization 頭資訊的請求。如果當前請求已經包含了 authorization 證書，那麼401響應代表著伺服器驗證已經拒絕了那些證書。如果401響應包含了與前乙個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向使用者展示響應中包含的實體資訊，因為這個實體資訊中可能包含了相關診斷資訊。參見rfc 2617。
403伺服器已經理解請求，但是拒絕執行它。與401響應不同的是，身份驗證並不能提供任何幫助，而且這個請求也不應該被重複提交。如果這不是乙個 head 請求，而且伺服器希望能夠講清楚為何請求不能被執行，那麼就應該在實體內描述拒絕的原因。當然伺服器也可以返回乙個404響應，假如它不希望讓客戶端獲得任何資訊。
404請求失敗，請求所希望得到的資源未被在伺服器上發現。沒有資訊能夠告訴使用者這個狀況到底是暫時的還是永久的。假如伺服器知道情況的話，應當使用410狀態碼來告知舊資源因為某些內部的配置機制問題，已經永久的不可用，而且沒有任何可以跳轉的位址。404這個狀態碼被廣泛應用於當伺服器不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下。出現這個錯誤的最有可能的原因是伺服器端沒有這個頁面
405請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回乙個allow 頭資訊用以表示出當前資源能夠接受的請求方法的列表。
鑑於 put，delete 方法會對伺服器上的資源進行寫操作，因而絕大部分的網頁伺服器都不支援或者在預設配置下不允許上述請求方法，對於此類請求均會返回405錯誤。
500伺服器遇到了乙個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在伺服器端的源**出現錯誤時出現。
501伺服器不支援當前請求所需要的某個功能。當伺服器無法識別請求的方法，並且無法支援其對任何資源的請求。
502作為閘道器或者**工作的伺服器嘗試執行請求時，從上游伺服器接收到無效的響應
503由於臨時的伺服器維護或者過載，伺服器當前無法處理請求。這個狀況是臨時的，並且將在一段時間以後恢復。如果能夠預計延遲時間，那麼響應中可以包含乙個 retry-after 頭用以標明這個延遲時間。如果沒有給出這個 retry-after 資訊，那麼客戶端應當以處理500響應的方式處理它。
注意：503狀態碼的存在並不意味著伺服器在過載的時候必須使用它。某些伺服器只不過是希望拒絕客戶端的連線。
504作為閘道器或者**工作的伺服器嘗試執行請求時，未能及時從上游伺服器（uri標識出的伺服器，例如http、ftp、ldap）或者輔助伺服器（例如dns）收到響應。
注意：某些**伺服器在dns查詢超時時會返回400或者500錯誤
505伺服器不支援，或者拒絕支援在請求中使用的 http 版本。這暗示著伺服器不能或不願使用與客戶端相同的版本。響應中應當包含乙個描述了為何版本不被支援以及伺服器支援哪些協議的實體。
JS控制台列印
今天在看jq的 時看到這樣乙個 console.warn nothing selected,can t validate,returning nothing 單獨執行，居然在控制台列印出了nothing selected,can t validate,returning nothing，豁然開朗，既...
nodejs之控制台列印
直接輸出引號中的資訊 onsole.log log資訊 依次輸出所有字串 console.log s first second 輸出結果 first second 將物件轉換為普通字串後執行 console.log s guoyansi 輸出結果 guoyansi 將字串作為數值進行轉換 conso...
IOS XCode 控制台列印中文方法
首先定義乙個列印方法 列印輸出 ifdef debug define ddlog format,printf class p s d method s n s n self,nsstring stringwithutf8string file lastpathcomponent utf8string...