異常定位(1)--生產環境經過SourceMap還原壓縮後JavaScript錯誤，快速定位異常

（若是你對 source-map有了解，可是不知道具體怎麼實現，操做，能夠跳過前面的，直接看底部列列舉的參考文章）

最近在處理上報的異常，寫個系列，這個是開篇

你們都知道通常咱們前端的JavaScript代碼上線前都會壓縮，混淆處理，減少代碼體積的同時還相對安全些，線上代碼通常是這樣的

舉一個具體例子 源代碼是這樣的

.......
function buyVip(){
    
   let { auto_renew } = this.vipData.vip;
   if( !this.isIOS == auto_renew.expire_type){
    console.log("you are ios vip")
   }    
}
.....
   
複製代碼

壓縮後是這個樣子

this.buyVip(this.selectInfo)},buyVip:function(t){var e=this;localStorage.setItem("vip_buy_goods",(0,l.default)(t)),this.timer=setTimeout(function(){if(!e.loginState)return e.loginActiveRouter="payVipOrder",u.default.openViewByRouter("bridge://user/login"),!1;var i=e.vipData.vip.auto_renew;if(!e.isIOS&&e.isSelect&&i&&1==i.auto_renew&&t.expire_type==i.expire_type&&t.expire_val==i.expire_val){var n=1==i.platform?
複製代碼

結果因爲 auto_renew 是個null，代碼報錯了，報錯信息以下

{
 message: "Cannot read property 'auto_renew' of undefined",
 url: "http://xxx.com/vip.024973a2.js",
 row:1,
 col:876
}
複製代碼

這樣你根據錯誤信息來定位具體的代碼很不容易，這個例子還有 auto_renew 這個關鍵字，能根據關鍵字查，有的是 Cannot read property [0] of undefined" 只看錯誤行數，開發小哥哥想哭，肉眼很難定位的具體問題的

哪怎麼樣才能定位到具體錯誤啊？

要不不壓縮代碼，直接源碼上，這是不可能的，代碼體積太大，安全也是個大問題，那咱們在本地開發的時候，默認也是打包後的文件，用Chrome 咋就能看到源碼，其實就是利用的 SourceMap 技術來調試，SourceMap簡單的講，就是維護一個源代碼和壓縮後代碼一一對應的文件，經過壓縮後的錯誤信息反向推出源代碼錯誤具體行號，剛纔上面那段代碼，map文件以下

{
    "version": 3,
    "sources": ["vip.024973a2.js"],
    "names": ["buyVip",],
    "mappings": "AAAA,QAASA,KAEL,GACIC,GAAW,UAAYC,IAC3BC,SAAQC,IAAIH,GAGhBD",
    "file": "hello.min.js",
    "sourceRoot": "",
    "sourcesContent": ["function buyVip()\n{\n let { auto_renew } = this.vipData.vip\n ...."]
}
複製代碼

這裏面的主要點是 mapings，是一個很長的字符串，它分紅三層，記錄了壓縮先後代碼對行關係，具體map怎麼記錄的能夠參考文章末尾的參考文章

那如今前端打包工具（webpack，gulp，rollup）都支持這個SourceMap功能，打包後相似這樣

咱們須要作的是把 打包後的 SourceMap 文件保存起來，而後根據上報的錯誤信息來反推具體行號了，強調下 SourceMap 文件是不要跟着打包後的js一塊兒部署的，這樣你線上的代碼人家是很容易拿到的，至關於裸奔，因此須要在打包腳本作文章，把 .js 和 .map 文件獨立出來，看個圖(圖是從網上找到，參見參考文檔)

這樣在錯誤平臺就能展現錯誤了

錯誤的展現平臺，咱們用的 Node.js 實現的，Firefox 開源一個 source-map 的包，很是好用，具體能夠看github， 實際上 source-map 是一套成熟的技術，網上資料不少，能夠搜來看看 那這裏僅僅是完成了一個最小的代碼錯誤復現的閉環， 如何在gitlab ci 裏統一剝離 source-map 文件和壓縮後 js 文件，如何對多項目source-map 文件存儲，如何對單項目多版本制定存儲規則，都是須要考慮的 第一個 統一剝離，由於咱們公司的前端部署是統一的部署腳本的，因此在公共的腳本里作了處理，這也說明了，前端有統一的部署是多重要，否則單獨項目接，會把人煩死，項目多了，必定要，工程化，流程化，統一化 版本存儲規則，目前是 項目名/gittag/

還有一個問題是 source-map 文件其實挺大的，並且是不變的，在Node.js 最好用Redis緩存，咱們初期項目接入很少，我先在內存裏作了緩存

這個最小的閉環已經能很好的協助解決JavaScript 錯誤問題，可是還不能作到頁面的監控，

• 頁面錯誤的歸類
• 比方某天客服反應 ，武漢這個區域，大面積用戶報錯，或者是頁面直接打不開
• 根據手機平牌，時間點，地域，來篩選錯誤
• 某個用戶出現錯誤的前10秒，用戶都有哪些操做行爲
• 網絡請求大面積報錯
• CDN加載失敗

這些都是須要解決的問題，出現了問題，怎麼樣預警，通知到開發，是否是能作到智能的處理，都是後面須要考慮的，因此還有不少任務要作，有了新的進展，我會同步記錄下來。

插一句哈，Vue 拋出的異常是沒有具體行號的，須要通過處理才能上報上去，能夠在github搜下 github.com/occ/TraceKit,專門格式化異常的(吐槽下中文搜索到 處理 source-map 的文章，都是同樣的還互相抄，說到Vue錯誤處理都是直接跳過，要處理Vue異常的必定記得看下這個庫，幫助很大)

這周九天班，趕忙睡覺去了。

這是開篇，下篇我會講講上報SDK的設計，處理哪些異常，能夠關注我，坐等更新

參考文章：

• 阮一峯老師的 source-map 介紹

• 腳本錯誤量極致優化-讓腳本錯誤一目瞭然

• sentry.io

• raven-js

• 異常格式化,處理vue文件用的上