5分钟教会你如何在生产环境debug代码.docx

第

5分钟教会你如何在生产环境debug代码

有时出现的线上bug在测试环境死活都不能复现，靠review代码猜测bug出现的原因，然后盲改代码直接在线上测试明显不靠谱。这时我们就需要在生产环境中debug代码，快速找到bug的原因，然后将锅丢出去。

生产环境的代码一般都是关闭sourcemap和经过混淆的，那么如何进行debug代码呢？我一般都是使用这两种方式debug线上代码：通过console找到源代码打断点和通过network面板的Initiator找到源代码打断点。

通过console找到源代码打断点

打开浏览器控制台的console面板，在上面找到由bug导致抛出的报错信息或者在代码里面通过console.log打的日志。然后点击最右边的文件名称跳转到具体的源码位置，直接在代码中打上断点就可以debug代码了。

如果点击右边的文件名后出现这种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)

只需要点击控制台右边倒数第三个图标setting（设置），将preferences（偏好设置）中的Enable

这种方式很简单就可以找到源代码，但是有的bug是没有报错信息的，而且我们也不可能到处都给代码加上console.log，所以这种方式有一定的局限性。

通过network面板的Initiator找到源代码打断点

将鼠标放到请求的Initiator（启动器）后，就会显示当前请求完整的调用链中的方法和函数。假如请求是由A函数中发起的，B函数调用了A函数，C函数又调用了B函数。那么这种情况中Initiator就会按照顺序依次将A、B、C函数都列出来。

了解了Initiator的作用思路就清晰了，我们只需要找到离bug最近的一个接口请求，然后从调用链中找到我们需要的方法或者函数就可以了。

这时有的小伙伴又会说了，线上的代码都是经过混淆的，原本代码中的函数和变量经过混淆后已经都不是原本的名字了，那么我们怎么知道调用栈中哪个是我们想要找的函数呢？

确实函数和变量名称经过混淆后已经变得面目全非了，但是对象中的方法和属性名称是不会被修改的，还是会保留原本的名字。比如我们有一个对象名字叫user，user中有个名叫dance的方法。经过混淆后user对象的名字可能已经变成了U，但是dance方法还是叫原本的名字，不会被修改。利用这一点我们可以在调用栈中找到我们熟悉的对象方法名称就可以很快的定位到源代码。

举个例子，我们当前有个service/common.js文件

importaxiosfromaxios

consturls={

messageList::3000/api/getMessageList,

constmethods={

getMessageList(){

returnaxios({

method:get,

url:urls.messageList,

exportdefault{

urls,

methods,

业务组件中这样调用

importCommonServicefrom@/service/common.js

asyncfunctioninitData(){

constres=awaitCommonService.methods.getMessageList();

constformatData:ArrayMessage=handleFormatData(res.data.list);

messageList.value=formatData;

在Initiator调用栈中就可以很容易的找到getMessageList方法，并且我们知道getMessageList方法是我们的initData调用的。那么在调用栈中getMessageList的上一个就是我们想要找的源代码位置，点击文件名称就可以跳转到目标源代码具体的位置。

如果跳转到源代码后代码是被压缩的状态，点左下角的花括号将代码格式化。找到具体的定位后，经过比对其实混淆后的代码和源代码其实差别不是特别大，debug代码还是很容易的。

这时有的小伙伴又会问了，假如我们出现