開發者有時會面臨上線的生產環境包出現了異常 ，在長期生產bug並修復bug的迴圈中總結出一下幾個痛點：

無法快速定位到發生錯誤的程式碼位置，因為腳手架構建時會用webapck自動幫我們壓縮程式碼，而上線版本又通常不會保留 source map（開源貢獻者除外）

無法第一時間通知開發人員異常發生

不知道使用者OS與瀏覽器版本、請求引數（如頁面ID）；而對於頁面邏輯是否錯誤問題，通常除了使用者OS與瀏覽器版本外，需要的是報錯的堆疊資訊及具體報錯位置。

錯誤埋點追蹤系統的出現就是為了應對上述問題的解決方案，筆者正好最近接觸了不少前端埋點與錯誤處理的部落格內容，按例階段性產出部落格總結一下。

在ES3之前js程式碼執行的過程中，一旦出現錯誤，整個js程式碼都會停止執行，這樣就顯的程式碼非常的不健壯。

從ES3開始，js也提供了類似的異常處理機制，從而讓js程式碼變的更健壯，程式執行的過程中出現了異常，也可以讓程式具有了一部分的異常恢復能力。js異常的特點是，出現不會導致JS引擎崩潰，最多隻會終止當前執行的任務。

埋點型別

根據埋點方式，可以區分為：

手動埋點

半自動埋點

全自動埋點

秉承“任何事物都有兩面性”的道理：自動程度高的，能解決通用統計，便於統一化管理，但個性化定製需求難滿足，成本較低；偏手動的，能滿足個性化需求，但容易出錯和疏漏，成本較高。

1.統計口徑定義不一致，導致資料和後臺差異大。例如登入，究竟是指指紋登入還是不含指紋驗證登入。

2.埋點定義不一樣，導致資料不準確。例如提交訂單，究竟是參照前端埋點，點選提交按鈕就觸發，還是採取後端上報，訂單成功後才觸發上報。

3.採集方式帶來的誤差。前端採集一般會有一部分資料丟失，丟失率在5%左右屬於正常範圍。

埋點是個系統性的工作，以訂單支付埋點為例，最後分析一下前後端埋點的優缺點。

一、埋點資料在網路傳輸環節丟失

網路環境差，如果一些埋點沒有資料暫存機制的話，或資料量超出了快取上限而導致資料丟失。在網路高峰期，使用者行為集中，給後臺伺服器帶來較大壓力，導致一些請求丟失

二、統計口徑不同

客戶端的情況很多，組織內部對指標的統計口徑可能存在不統一，例如為了應對網路異常，會採取重傳、間隔上傳等策略，而這些策略可能存在標準不統一而導致統計結果有問題。

三、客戶端的執行環境多樣：手機有不同的型號，手機系統又分ios與安卓，而安卓還有大量定製，再加上部分刷機、越獄、同一系統不同版本，埋點程式碼可能無法相容一部分執行環境，導致SDK在某些情況下不能有效呼叫，或者重複傳送

四、髒資料

理想狀態，使用我們app的都是一個個自然人，但現實環境要複雜得多，最常見的就是可能會有爬蟲，甚至競爭對手的惡意攻擊（比如DDoS）。

埋藏異常

omaly）：發現埋藏異常是比較困難的。但有時可以透過其上方運積物中的水成異常來探索。出露在基岩表面的原生異常被運積物掩埋時，也可稱為埋藏異常。

正文

埋藏異常（buried anomaly）：發現埋藏異常是比較困難的。但有時可以透過其上方運積物中的水成異常來探索。如果水成異常不存在，就必須使用深部取樣方法，或者使用一些新技術如氣體測量方法等。出露在基岩表面的原生異常被運積物掩埋時，也可稱為埋藏異常。

能捕捉到的異常，必須是執行緒執行已經進入 try catch 但 try catch 未執行完的時候丟擲來的,以下都是無法被捕獲到的情形。

非同步任務丟擲的異常（執行時try catch已經從執行完了）

promise（異常內部捕獲到了，並未往上拋異常，使用catch處理）

語法錯誤（程式碼執行前，在編譯時就檢查出來了的錯誤）

優點：能夠較好地進行異常捕獲，不至於使得頁面由於一處錯誤掛掉

缺點：顯得過於臃腫，大多程式碼使用try ... catch包裹，影響程式碼可讀性。

所謂“埋點”，是資料採集領域（尤其是使用者行為資料採集領域）的術語，指的是針對特定使用者行為或事件進行捕獲、處理和傳送的相關技術及其實施過程。比如使用者某個icon點選次數、觀看某個影片的時長等等。

埋點的技術實質，是先監聽軟體應用執行過程中的事件，當需要關注的事件發生時進行判斷和捕獲。

特別注意需要明確事件發生時間點、判別條件，這裡如果遇到不清楚的，需要和開發溝通清楚，避免採集資料與理想存在差異。例如：期望採集某個app的某個廣告的有效曝光數，有效曝光的判別條件是停留時長超過1秒且有效加載出廣告內容。