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

前言

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

在这里插入图片描述

生产环境的代码一般都是关闭source map和经过混淆的,那么如何进行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 JavaScript source maps(启用 JavaScript 源代码映射)取消勾选后再重新点console最右边的文件名称即可。

在这里插入图片描述

这种方式很简单就可以找到源代码,但是有的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文件

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,
};

业务组件中这样调用

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

在这里插入图片描述

在这里插入图片描述

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

这时有的小伙伴又会问了,假如我们出现bug的地方没有接口请求怎么办呢?

这种情况也可以利用Initiator调用栈找到对应的源代码js文件,然后搜索你知道的属性和方法名字,因为属性和方法名称在混淆的过程中是不会被重写的。这样也可以找到源代码的位置。

总结

这篇文章主要介绍了两种在线上debug源码的方法。第一种方法是在控制台找到console输出,点击console右边的文件名称跳转到源码进行debug。第二种方式通过请求的Initiator调用栈,找到源代码中对应的方法,点击文件名称也可以跳转到源代码具体的位置。

关注公众号:前端欧阳,解锁我更多vue干货文章,并且可以免费向我咨询vue相关问题。

  • 33
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
在调试器中使用 gdb 跟踪内核代码的执行路径,需要进行以下步骤: 1. 编译内核:首先,您需要获取内核源代码并编译内核。确保在编译选项中启用了调试符号(debug symbols),这样才能在调试过程中正确地解析内核符号。 2. 启动内核调试:启动您的系统,并在启动参数中添加 "debug" 或 "kgdboc" 参数,以使内核进入调试模式。这可能涉及到修改引导加载器(如 GRUB)的配置文件。 3. 连接 GDB:在另一个终端窗口中,使用 gdb 命令连接到您的调试目标。例如,可以使用以下命令连接到正在运行的内核: ``` gdb vmlinux ``` 4. 设置调试选项:在 GDB 中,您可以设置一些调试选项,例如设置断点、打印变量值等。您可以使用 GDB 的命令和脚本语言来完成这些任务。 5. 开始调试:当您准备好开始调试时,可以使用 GDB 的命令来执行和跟踪内核代码。例如,您可以使用 "start" 命令开始执行内核,并使用 "next" 或 "step" 命令逐行执行代码。 6. 跟踪执行路径:在执行过程中,您可以使用 GDB 的 "next"、"step"、"continue" 等命令来跟踪代码的执行路径。您还可以使用 "break" 命令设置断点,以在特定位置停止执行并检查相关变量。 请注意,内核调试是一项高级任务,需要对内核源代码和调试工具有深入的理解。此外,内核调试可能会对系统的稳定性和性能产生影响,因此在生产环境中应谨慎使用。建议在测试环境中进行内核调试,并遵循相关文档和教程中的指导。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值