原文位址
在前端開發工作中，除了項目開發保質保量上線以外，項目的資料監控也應該配套起來，確定線上的正常運轉。如上報 pv 監控項目是否正常運轉；測速上報反應項目品質；腳本錯誤監控作為監控中重要一環，當頁面發生報錯的時候，通過上報錯誤資訊，能及時發現存在問題，修複優化、減少損失。
本文基于在手 Q 家校群前端腳本錯誤量優化的方案，緻力于打造極緻的腳本錯誤優化。
腳本錯誤主要有兩類：文法錯誤、運作時錯誤。
監控的方式主要有兩種：try-catch、window.onerror。
通過給代碼塊進行 try-catch 包裝，當代碼塊出錯時 catch 将能捕獲到錯誤資訊，頁面也将繼續執行。
當發生文法錯誤或異步錯誤時，則無法正常捕捉。
無法捕捉錯誤
文法錯誤無法在 try-catch 中進行捕抓、而異步報錯則可以通過為異步函數塊再包裝一層 try-catch，增加辨別資訊來配合定位，可以用工具來進行處理，這裡不展開。
window.onerror 能捕捉到目前頁面的文法錯誤或運作時報錯，是十分強大的。
那麼 try-catch 是否不再需要呢？其實并不是。
在使用過程中的體會：onerror 主要用來捕獲預料之外的錯誤，而 try-catch 則可以用在預知情況下監控特定錯誤，兩種形式結合使用更加高效。
監控錯誤拿到了報錯資訊，接下來則是将捕抓的錯誤資訊發送到資訊收集平台上，發送的形式主要有兩種：
通過 Ajax 發送資料
動态建立 img 标簽的形式
監控報錯，并将捕捉到的錯誤資訊上報給資料收集平台，如下圖
有了監控了後，就可以在收集平台上進行檢視腳本錯誤量的日志統計。
發現占據榜首的錯誤資訊 “Script error.” 具有非常高的比例，沒有無具體的錯誤資訊，無法定位問題，而這是怎麼産生的呢？
翻看在 webkit 的源碼可以看到 “Script error.” 是浏覽器在同源政策限制下所産生的。浏覽器出于安全上的考慮，當頁面引用的非同域的外部腳本中抛出了異常，此時本頁面無權限獲得這個異常詳情， 将輸出 Script error 的錯誤資訊。
Script error 來自同源政策的影響，那麼解決的方案之一是進行資源的同源化，另外也可以利用跨源資源共享機制( CORS )。
将 js 代碼内聯到 html 檔案中
将 js 檔案與 html 檔案放到同一域名下
以上兩種方式能夠簡單直接地解決問題，但也可能帶來其他影響，如内聯資源不好利用檔案緩存，同域無法充分利用 cdn 優勢等等。
跨源資源共享 ( CORS ) 機制讓 Web 應用伺服器能支援跨站通路控制，進而能夠安全地跨站資料傳輸。主要是通過給請求帶上特定頭資訊，伺服器實作了 CORS 接口，就可以跨源通信，進而能夠看到具體報錯資訊。
1. 為頁面上 script 标簽添加 crossorigin 屬性。
增加 crossorigin 屬性後，浏覽器将自動在請求頭中添加一個 Origin 字段，發起一個 跨來源資源共享 請求。Origin 向服務端表明了請求來源，服務端将根據來源判斷是否正常響應。
2. 響應頭中增加 Access-Control-Allow-Origin 來支援跨域資源共享。
Access-Control-Allow-Origin: * 表示通過該跨域請求，且該資源可以被任意站點跨站通路。而當該資源僅允許來自 http://127.0.0.1:8066 的跨站請求，其它站點都不能跨站通路時，将可以傳回：
3. 指定域名的 Access-Control-Allow-Origin 的響應頭中需帶上 Vary:Origin。
Vary 字段的作用在于為緩存伺服器提供緩存規則及緩存篩選的依據。當增加 Vary:Origin 響應頭後，緩存伺服器将會按照 Origin 字段的内容，緩存不同版本，在請求響應時根據請求頭中的 Origin 決定是否能夠使用緩存響應。
舉例 · 不加 Vary 将存在錯誤命中緩存的問題
上圖中，第一個請求（Origin: 127.0.0.1:8066）響應被浏覽器緩存了，當第二個請求（Origin: 127.0.0.1:8888）發起，被錯誤命中了前一個請求的緩存，收到了 Access-Control-Allow-Origin:http://127.0.0.1:8066 的響應時，将導緻資源加載失敗。
是以當 Access-Control-Allow-Origin 不是傳回為 * 時，需要加上 Vary 傳回頭來避免引緩存導緻的權限問題。
跨域腳本報錯産生 Script error. 通過以上方式進行處理後将能夠捕獲到具體的報錯資訊了。在 NodeJS 的實作中主要通過添加以下代碼：
以上為本文所有内容，兄弟篇：腳本錯誤量極緻優化-讓腳本錯誤一目了然
檢視更多文章： https://github.com/joeyguo/blog