线上出bug了?别怕,这么定位!

工作中,生产环境代码是编译后代码,搜集到报错信息的行和列无法在源码中对应,很多时候只能靠“经验”去猜,本文针对这种情况,开发了一个npm命令行小工具,帮助快速定位报错的源码位置,提升效率。

由于现在构建工具盛行,前端部署的代码都是经过编译,压缩后的,于是乎,SoueceMap就扮演了一个十分重要的角色,用来作为源代码和编译代码之间的映射,方便定位问题。

生产环境为什么要关闭SourceMap

虽然map文件提供了便利,但是在生产环境,为了安全,是建议关闭SourceMap的,因为通过.map文件和编译后代码可以很容易反编译出项目的源码,这样就相当于泄露了项目的代码。下面做个测试:
首先全局安装reverse-sourcemap

npm install --global reverse-sourcemap
复制代码

选择编译后的代码进行测试,下面是vue项目编译生成的代码。

在命令行执行命令,将main.js反编译回源码,并输出到sourcecode目录下。

reverse-sourcemap -v dist/main.a8ebc11c3f03786d8e3b.js.map  -o sourcecode
复制代码

上面是执行命令输出的sourcecode目录,生成的目录结构和源码目录一致,打开一个文件,和源码做下对比:

可以看出,反编译出的代码无论目录结构还是具体代码都和源码一致。

生产环境代码报错如何定位源码位置

生产环境的代码,经过压缩、编译,很不利于debug。由于生产环境没有配置SourceMap,所以代码报错时,或是通过Fundebug,Sentry等工具搜集到的报错信息,得到报错代码的行和列都是编译后的代码,这样很不易于定位问题。

针对这个问题,需要准备一份生产环境代码的map文件,为了方便,可以在项目的package.json增加debug命令用来生成map文件。这条命令除了开启sourcemap,其他的具体webpack配置和生产环境配置相同。

    "scripts": {
        "start": "vue-cli-service serve --mode dev",
        "stage": "vue-cli-service build --mode staging",
        "online": "vue-cli-service build",
        "debug": "vue-cli-service build --mode debug"
    },
复制代码

有了map文件,通过SourceMap提供的API就可以定位到源码的位置。下面是实现的核心代码。

// Get file content
const sourceMap = require('source-map');
const readFile = function (filePath) {
  return new Promise(function (resolve, reject) {
    fs.readFile(filePath, {encoding:'utf-8'}, function(error, data) {
      if (error) {
        console.log(error)
        return reject(error);
      }
      resolve(JSON.parse(data));
    });
  });
};

// Find the source location
async function searchSource(filePath, line, column) {
  const rawSourceMap = await readFile(filePath)
  const consumer = await new sourceMap.SourceMapConsumer(rawSourceMap);
  const res = consumer.originalPositionFor({
    'line' : line,
    'column' : column
   });
   consumer.destroy()
  return res
}
复制代码

最重要的就是使用SourceMap提供的 originalPositionFor API。 SourceMapConsumer.prototype.originalPositionFor(generatedPosition)

originalPositionFor API的参数为一个包含line和column属性的对象
line 编译生成代码的行号,从1开始
column 编译生成代码的列号,从0开始
这个方法会返回一个具有以下属性的对象

{ source: 'webpack:///src/pages/common/403.vue?c891', // 源代码文件的位置,如果无法获取,返回null。
  line: 4, // 源代码的行号,从1开始,如果无法获取,返回null。
  column: 24, // 源代码的列号,从0开始,如果无法获取,返回null。
  name: 'get' // 源代码的标识,如果无法获取,返回null。
  }
复制代码

源码定位工具

为了使用方便,我将这个功能做成了一个命令行小工具。全局安装后,不需要做任何配置就可以使用。

安装
npm install --global source-location
复制代码
参数介绍
Usage: sl [options]

Options:
  -v, --version           output the version number
  -p, --source-flie-path  The generated source file  编译后的map文件
  -l, --ine               The line number in the generated source  编译后代码行号
  -c, --column            The column number in the generated source  编译后代码列号
  -h, --help              output usage information
复制代码
使用案例

终端执行命令:

sl -p dist/1.f47efcb58028826c7c05.js.map -l 1 -c 34 
复制代码

命令行将会输出:源码的文件路径:path,源码行号:line,源码标识:name。

项目的github地址: github.com/front-end-y… 如有错误欢迎指出。

另外,推荐大家使用Fundebug,一款很好用的BUG监控工具~

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 在线遗漏bug率在不同行业和项目中会有所不同,难以简单地给一个业内一般的具体数字。这是因为线上遗漏bug率受到多种因素的影响。 首先,项目规模与复杂度会直接影响线上遗漏bug率。大型复杂项目通常会有更多的代码,更多的功能模块和更多的潜在问题,因此其线上遗漏bug率可能相对较高。 其次,开发团队的技术水平和经验也是一个重要因素。经验丰富的开发团队通常能够更好地识别和解决潜在问题,从而降低线上遗漏bug的概率。 另外,项目的测试与审查过程对于降低线上遗漏bug率也至关重要。严格的测试策略、完善的代码审查流程和有效的Bug跟踪系统都可以帮助发现和解决潜在问题,减少线上遗漏bug的发生。 总的来说,业内对于线上遗漏bug率没有一个具体的标准。每个项目都有其独特性和复杂性,线上遗漏bug率的大小取决于多种因素。因此,提高团队的技术水平,加强测试和代码审查流程,优化Bug跟踪和修复机制等都是降低线上遗漏bug率的有效方法。 ### 回答2: 在线上遗漏bug率在软件行业内是一个常见的问题。由于各种原因,完全消除bug是不太可能的。在实际开发过程中,我们会尽量减少bug的数量并提高软件质量,但无法做到百分之百的无bug。 在线上遗漏bug率的多少因公司、项目、开发团队等不同而异。在业内,一般认为每千行代码遗漏的bug数量为1~5个是比较常见的情况。当然,这只是一个粗略的估计,实际情况可能会有所差异。 影响在线上遗漏bug率的因素很多。首先是项目的复杂程度。复杂的项目通常容易产生更多的bug。其次是开发团队的水平和经验。经验丰富的开发人员通常能够更好地避免和解决bug。另外,开发过程中使用的工具、测试流程和质量控制机制也会影响bug率。 为了降低在线上遗漏bug率,我们可以采取一些措施。首先是重视代码质量,编写高质量的代码是减少bug的关键。其次是加强测试环节,包括单元测试、集成测试和系统测试,以尽早发现和解决bug。此外,定期进行代码审查、持续集成和自动化测试也可以提高软件质量并减少bug的数量。 总之,在线上遗漏bug率在软件行业内是一个普遍存在的问题。尽管我们会采取各种措施来降低bug率,但无法完全消除。我们需要努力提高开发质量和测试流程,以确保软件的稳定性和可靠性。 ### 回答3: 线上遗漏bug率在软件开发行业中是一个普遍存在的问题,无法给一个固定的准确数字来表示。其多少直接取决于项目的复杂度、开发团队的技术水平、代码测试与质量保证的程度等因素。 一般来说,在软件开发过程中,开发团队会通过需求分析、设计、编码、测试等多个环节来尽可能减少和排查bug。然而,由于时间和资源的限制,无法完全避免bug现。部分bug可能在开发过程中没有被发现,进而在线上环境中才被用户或者运维人员发现。 对于一些复杂度较高的软件项目,由于涉及的逻辑和功能较多,线上遗漏bug率可能会相对较高。例如,大型互联网平台、金融系统等,其对安全性和稳定性的要求较高,线上遗漏bug率往往会受到更加重视。 为了降低线上遗漏bug率,开发团队通常会采取一系列的措施,如增加代码测试覆盖率、引入自动化测试工具、进行持续集成与部署等。这些措施可以帮助开发团队在开发过程中及时发现和修复bug,减少线上遗漏bug的可能性。 总之,线上遗漏bug率的具体多少无法简单确定,它取决于各种因素的综合影响。但在软件开发行业中,开发团队通常会努力采取措施,尽可能减少线上遗漏bug的发生。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值