在複雜的網絡環境和浏覽器環境下，自測、QA測試以及 Code Review 都是不夠的，如果對頁面穩定性和準确性要求較高，就必須有一套完善的代碼異常監控體系，本文從前端代碼異常監控的方法和問題着手，盡量全面地闡述錯誤日志收集各個階段中可能遇到的阻礙和處理方案。
平時收集日志的手段，可以歸類為兩個方面，一個是邏輯中的錯誤判斷，為主動判斷；一個是利用語言給我們提供的捷徑，暴力式擷取錯誤資訊，如 <code>try..catch</code> 和<code>window.onerror</code>。
1. 主動判斷
我們在一些運算之後，得到一個期望的結果，然而結果不是我們想要的
這種屬于邏輯錯誤/狀态錯誤的回報，在接口 <code>status</code> 判斷中用的比較多。
2. <code>try..catch</code> 捕獲
判斷一個代碼段中存在的錯誤：
以 <code>init</code> 為程式的入口，代碼中所有同步執行出現的錯誤都會被捕獲，這種方式也可以很好的避免程式剛跑起來就挂。
3. <code>window.onerror</code>
捕獲全局錯誤：
在上面的函數中傳回 <code>return true</code>，錯誤便不會暴露到控制台中。下面是它的參數資訊：
<code>window.onerror</code> 算是一種特别暴力的容錯手段，<code>try..catch</code> 也是如此，他們底層的實作就是利用 C/C++ 中的 <code>goto</code> 語句實作，一旦發現錯誤，不管目前的堆棧有多深，不管代碼運作到了何處，直接跑到頂層或者 <code>try..catch</code> 捕獲的那一層，這種一腳踢開錯誤的處理方式并不是很好。
收集日志的目的是為了及時發現問題，最好日志能夠告訴我們，錯誤在哪裡，更優秀的做法是，不僅告訴錯誤在哪裡，還告訴我們，如何處理這個錯誤。終極目标是，發現錯誤，自動容錯，這一步是最難的。
先看下面的例子，test.html
test.js
我們期望收集到的日志是下面這樣具體的資訊：
為了對資源進行更好的配置和管理，我們通常将靜态資源放到異域上
而拿到的結果卻是：
跨域情況下，傳回的結果是 <code>Script error.</code>。
在本地測試了下：
可見在 <code>file://</code> 協定下，<code>securityOrigin()->canRequest(targetURL)</code> 也是<code>false</code>。
為何<code>Script error.</code>?
簡單報錯： <code>Script error</code>，目的是避免資料洩露到不安全的域中，一個簡單的例子：
上面我們并沒有引入一個 js 檔案，而是一個 html，這個 html 是銀行的登入頁面，如果你已經登入了 <code>bank.com</code>，那 login 頁面就會自動跳轉到 <code>Welcome xxx...</code>，如果未登入則跳轉到 <code>Please Login...</code>，那麼 JS 報錯也會是 <code>Welcome xxx... is not defined</code>，<code>Please Login... is not defined</code>，通過這些資訊可以判斷一個使用者是否登入他的銀行帳号，給 hacker 提供了十分便利的判斷管道，這是相當不安全的。
<code>crossOrigin</code>參數跳過跨域限制
image 和 script 标簽都有 crossorigin 參數，它的作用就是告訴浏覽器，我要加載一個外域的資源，并且我信任這個資源。
然而，卻報錯了：
這是意料之中的錯誤，跨域資源共享政策要求，伺服器也設定 <code>Access-Control-Allow-Origin</code> 的響應頭：
回頭看看我們 CDN 的資源，
Javascript/CSS/Image/Font/SWF 等這些靜态資源其實都已經早早地加上了 CORS 響應頭。
線上的代碼幾乎都是經過打包壓縮的，幾十上百的檔案壓縮後打包成一個，而且隻有一行。當我們收到 <code>a is not defined</code> 的時候，如果隻在特定場景下才報錯，我們根本無法定位到這個被壓縮的 <code>a</code> 是個什麼東西，那麼此時的錯誤日志就是無效的。
第一個想到的辦法是利用 sourceMap，利用它可以定位到壓縮代碼某一點在未壓縮代碼的具體位置。下面是 sourceMap 引入的格式，在代碼的最後一行加入：
以前使用的是 ‘//@’ 作為開頭，現在使用 ‘//#’，然而對于錯誤上報，這玩意兒沒啥用。JS 不能拿到他真實的行數，隻能通過 Chrome DevTools 這樣的工具輔助定位，而且并不是每個線上資源都會添加 sourceMap 檔案。sourceMap 的用途目前還隻能展現在開發階段。
當然，如果了解了 sourceMap 的 VLQ編碼和位置對應關系，也可以将拿到的日志進行二次解析，映射到真實路徑位置，這個成本比較高，貌似暫時也沒人嘗試過。
那麼，有什麼辦法，可以定位錯誤的具體位置，或者說有什麼辦法可以縮小我們定位問題的難度呢？
可以這樣考慮：打包的時候，在每兩個合并的檔案之間加上 1000 個空行，最後上線的檔案就會變成
如果報錯在第 3001 行，
可以計算出，錯誤出現在第三個檔案中，範圍就縮小了很多。
多次注冊 error 事件，不會重複執行多個回調：
觸發錯誤之後，上面代碼的結果為：
<code>window.onerror</code> 和 <code>addEventListener</code> 都執行了，并隻執行了一次。
沒有必要将所有的錯誤資訊全部送到 Log 中，這個量太大了。如果網頁 PV 有 1kw，那麼一個必現錯誤發送的 log 資訊将有 1kw 條，大約一個 G 的日志。我們可以給 <code>Reporter</code> 函數添加一個采樣率：
這個采樣率可以按需求來處理，可以同上，使用一個随機數，也可以使用 cookie 中的某個字段（如 nickname）的最後一個字母/數字來判定，也可以将使用者的 nickname 進行 hash 計算，再通過最後一位的字母/數字來判斷，總之，方法是很多的。
為了更加精準的拿到錯誤資訊，有效地統計錯誤日志，我們應該更多地采用主動式埋點，比如在一個接口的請求中：
上面我們精準地布下了三個點，描述十厘清晰，這三個點會對我們後續排查線上問題提供十分有利的資訊。
關于 <code>try..catch</code> 的使用
對于 <code>try..catch</code> 的使用，我的建議是：能不用，盡量不要用。JS代碼都是自己寫出來的，哪裡會出現問題，會出現什麼問題，心中應該都有個譜，平時用到 <code>try..catch</code> 的一般隻有兩個地方：
關于 <code>window.onerror</code> 的使用
可以嘗試如下代碼：
什麼時候該警報？不能有錯就報。上面也說了，因為網絡環境和浏覽器環境因素，複雜頁面我們允許千分之一的錯誤率。日志處理後的資料圖：
圖中有兩根線，橙色線是今日的資料，淺藍色線是往日平均資料，每隔 10 分鐘産生一條記錄，橫坐标是 0-24 點的時間軸，縱坐标是錯誤量。可以很明顯的看出，在淩晨一兩點左右，服務出現了異常，錯誤資訊是平均值的十幾倍，那麼這個時候就改報警了。
報警的條件可以設定得嚴苛一點，因為誤報是件很煩人的事情，短信、郵件、軟體等資訊轟炸，有的時候還是大半夜。那麼，一般滿足如下條件可以報警：
錯誤超過門檻值，比如 10分鐘最多允許 100 個錯誤，結果超過了 100
錯誤超過平均值的 10 倍，超過平均值就報警，這個邏輯顯然不正确，但是超過了平均值的 10 倍，基本可以認定服務出問題了
在納入對比之前，要過濾同 IP 出現的錯誤，比如一個錯誤出現在 for 循環或者 while 循環中，再比如一個使用者在蹲點搶購，不停的重新整理
友好的錯誤提示
對比下面兩條日志，catch 的錯誤日志：
Uncaught ReferenceError: vd is not defined
自定義的錯誤日志：
“生日子產品中擷取後端接口資訊時，eval 解析出錯，錯誤内容為：vd is not defined.” 該錯誤在最近 10 分鐘内出現 1000 次，這個錯誤往日的平均出錯量是 50 次 / 10 分鐘
W3C Web Performance工作組釋出了網絡錯誤日志工作草案。該文檔定義了一個機制，允許Web站點聲明一個網絡錯誤彙報政策，浏覽器等使用者代理可以利用這一機制，彙報影響資源正确加載的網絡錯誤。該文檔還定義了一個錯誤報告的标準格式及其在浏覽器和Web伺服器之間的傳輸機制。
功能、測試和監控是程式開發的三闆斧，很多工程師可以将功能做的盡善盡美，也了解一些測試方面的知識，可是在監控這個方向上基本處于大腦空白。錯誤日志的收集、整理算是監控的一個小部分，但是它對我們了解網站穩定性至關重要。文中有忽略的地方希望讀者可以補充，錯誤的地方還望斧正。
<a href="http://www.w3.org/TR/2010/WD-html5-20100624/webappapis.html#handler-window-onerror">HTML5标準-window.onerror</a>
<a href="http://msdn.microsoft.com/en-us/library/cc197053%28VS.85%29.aspx">MSDN-window.onerror</a>
<a href="https://developer.mozilla.org/en/DOM/window.onerror">MDN-window.onerror</a>
<a href="http://www.w3.org/TR/2015/WD-network-error-logging-20150305/">網絡錯誤日志</a>
本文轉自Barret Lee部落格園部落格，原文連結：http://www.cnblogs.com/hustskyking/p/fe-monitor.html，如需轉載請自行聯系原作者