頁面上線的時候，偶爾會有些特殊或者比較極端的情況，導緻頁面報錯。
小的錯誤可能隻是console控制台上的一個error提示，大的錯誤可能會導緻頁面無法正常使用，更嚴重的可能是頁面都沒法正常展示。
這邊聊聊如何可以有效的避免一些錯誤，或者如何在錯誤的時候做相容，讓代碼或者頁面更有健壯性。
通常一個場景是，函數接受一個參數，或者從接口中傳回資料，要對這些資料做處理。使用接口的人或者說背景是不會告訴你參數到底會不會有異常（難道告訴你了你就可以放心的不管了？）。
這樣如果入參是undefined或者null的話，那麼這句就直接報錯。通常做法是
這裡有一個做法是使用es6的預設值，但如果傳的參數是null，這邊會怎樣？ function a(opts={}) { var v = opts.v; }
還有一種異常是發生在異步請求或者代碼運作過程中的異常，異常一般是在error回調或者trycatch裡處理，也是比較常見的方式了
以上兩種處理方式比較常見，一般異步頁面裡用的比較多，點雖然小，但比較有用。
接下來說是頁面級别的降級或者說錯誤相容。
對于外部請求不存在的資源，通常我們是傳回一個定制的404頁面。而對于通路了伺服器直出的頁面，直出頁面不可用時，簡單粗暴的404就不那麼适用了。
這個時候，我們需要的是能夠提供和重要頁面體驗一樣的異步頁面給到使用者，讓使用者感覺不到這裡的問題。
這裡就提出了一個新的要求，降級的異步頁面哪裡來。
手動寫一個
同構
ps：這裡主要講降級，是以這塊具體實作不再擴充。
降級可以由直出服務來處理，比如在error的時候重定向（重定向的url和目前url是不一樣的，一樣的話就跪了），或者在error的時候傳回一個标志位，業務代碼依據标志位執行異步請求以及資料渲染的邏輯。
直出服務處理會有個問題，直出服務挂了該怎麼辦。
這個時候該接入層（nginx）上場了，在目前location中配置降級政策。
目前我們采用的做法在上面，但其實也面臨一個問題是，nginx規則經常變，如果nginx挂了，咋辦？
這個時候可以做的是，利用多層nginx代理，上層代理對重要頁面做降級處理，下層代理就是正常的業務nginx配置。
cgi是需要部署在不同的地區不同的機房中，但萬一真的cgi也挂了，頁面降級再多也是徒勞。是以擺在我們面前的就是cgi挂了怎麼辦。 同樣，我們可以在接入層（nginx）來做這件事情。
問題總是層出不窮，而我們要做的就是守好自己那一片土地。
一方面我們需要提升代碼的健壯性，review代碼，降低可能出問題的風險。另一方面，凡是想到萬一，如果問題發生之後，我們該如何處理。
願皮神保佑，代碼無bug。