前言

有時出現(xiàn)的線上bug在測試環(huán)境死活都不能復(fù)現(xiàn)，靠review代碼猜測bug出現(xiàn)的原因，然后盲改代碼直接在線上測試明顯不靠譜。這時我們就需要在生產(chǎn)環(huán)境中debug代碼，快速找到bug的原因，然后將鍋丟出去。

生產(chǎn)環(huán)境的代碼一般都是關(guān)閉source map和經(jīng)過混淆的，那么如何進行debug代碼呢？我一般都是使用這兩種方式debug線上代碼：“通過console找到源代碼打斷點”和“通過network面板的Initiator找到源代碼打斷點”。

通過console找到源代碼打斷點

打開瀏覽器控制臺的console面板，在上面找到由bug導(dǎo)致拋出的報錯信息或者在代碼里面通過console.log打的日志。然后點擊最右邊的文件名稱跳轉(zhuǎn)到具體的源碼位置，直接在代碼中打上斷點就可以debug代碼了。

如果點擊右邊的文件名后出現(xiàn)這種404報錯的情況。
could-not-load-content-for-webpack://***-(fetch-through-target-failed:-unsupported-url-scheme;-fallback:-http-error:-status-code-404,-net:: ERR_UNKNOWN_URL_SCHEME)

只需要點擊控制臺右邊倒數(shù)第三個圖標(biāo)setting（設(shè)置），將preferences（偏好設(shè)置）中的Enable JavaScript source maps（啟用 JavaScript 源代碼映射）取消勾選后再重新點console最右邊的文件名稱即可。

這種方式很簡單就可以找到源代碼，但是有的bug是沒有報錯信息的，而且我們也不可能到處都給代碼加上console.log，所以這種方式有一定的局限性。

通過network面板的Initiator找到源代碼打斷點

將鼠標(biāo)放到請求的Initiator（啟動器）后，就會顯示當(dāng)前請求完整的調(diào)用鏈中的方法和函數(shù)。假如請求是由A函數(shù)中發(fā)起的，B函數(shù)調(diào)用了A函數(shù)，C函數(shù)又調(diào)用了B函數(shù)。那么這種情況中Initiator就會按照順序依次將A、B、C函數(shù)都列出來。

了解了Initiator的作用思路就清晰了，我們只需要找到離bug最近的一個接口請求，然后從調(diào)用鏈中找到我們需要的方法或者函數(shù)就可以了。

這時有的小伙伴又會說了，線上的代碼都是經(jīng)過混淆的，原本代碼中的函數(shù)和變量經(jīng)過混淆后已經(jīng)都不是原本的名字了，那么我們怎么知道調(diào)用棧中哪個是我們想要找的函數(shù)呢？

確實函數(shù)和變量名稱經(jīng)過混淆后已經(jīng)變得面目全非了，但是對象中的方法和屬性名稱是不會被修改的，還是會保留原本的名字。比如我們有一個對象名字叫user，user中有個名叫dance的方法。經(jīng)過混淆后user對象的名字可能已經(jīng)變成了U，但是dance方法還是叫原本的名字，不會被修改。利用這一點我們可以在調(diào)用棧中找到我們熟悉的對象方法名稱就可以很快的定位到源代碼。

舉個例子，我們當(dāng)前有個service/common.js文件

import axios from "axios";

const urls = {
  messageList: "http://127.0.0.1:3000/api/getMessageList",
};

const methods = {
  getMessageList() {
    return axios({
      method: "get",
      url: urls.messageList,
    });
  },
};

export default {
  urls,
  methods,
};

業(yè)務(wù)組件中這樣調(diào)用

import CommonService from "@/service/common.js";

async function initData() {
  const res = await CommonService.methods.getMessageList();
  const formatData: Array<Message> = handleFormatData(res.data.list);
  messageList.value = formatData;
}

在Initiator調(diào)用棧中就可以很容易的找到getMessageList方法，并且我們知道getMessageList方法是我們的initData調(diào)用的。那么在調(diào)用棧中getMessageList的上一個就是我們想要找的源代碼位置，點擊文件名稱就可以跳轉(zhuǎn)到目標(biāo)源代碼具體的位置。

如果跳轉(zhuǎn)到源代碼后代碼是被壓縮的狀態(tài)，點左下角的花括號將代碼格式化。找到具體的定位后，經(jīng)過比對其實混淆后的代碼和源代碼其實差別不是特別大，debug代碼還是很容易的。

這時有的小伙伴又會問了，假如我們出現(xiàn)bug的地方?jīng)]有接口請求怎么辦呢？

這種情況也可以利用Initiator調(diào)用棧找到對應(yīng)的源代碼js文件，然后搜索你知道的屬性和方法名字，因為屬性和方法名稱在混淆的過程中是不會被重寫的。這樣也可以找到源代碼的位置。

總結(jié)

這篇文章主要介紹了兩種在線上debug源碼的方法。第一種方法是在控制臺找到console輸出，點擊console右邊的文件名稱跳轉(zhuǎn)到源碼進行debug。第二種方式通過請求的Initiator調(diào)用棧，找到源代碼中對應(yīng)的方法，點擊文件名稱也可以跳轉(zhuǎn)到源代碼具體的位置。

如果我的文章對你有點幫助，歡迎關(guān)注公眾號：【歐陽碼農(nóng)】，文章在公眾號首發(fā)。你的支持就是我創(chuàng)作的最大動力，感謝感謝！文章來源地址http://www.zghlxwxcb.cn/news/detail-804897.html

到了這里，關(guān)于5分鐘教會你如何在生產(chǎn)環(huán)境debug代碼的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！