关于javascript:前端异常解析Source-Map

引子

在前端异样解析中介绍了异样的解析，这些异样信息上报后，个别也难以间接的看出什么谬误源，因为正式的线上环境中，代码往往都通过了压缩混同，异样的一些信息都是指向压缩文件。这时候能够依据 Source Map 文件追溯源文件的地位。

• Origin
• My GitHub

简介

最后的源映射格局是由 Joseph Schorr 创立，在 Closure Inspector（谷歌的公共工具）中用来开启 JavaScript 源码级别的调试优化。随着应用了源映射的我的项目规模扩充，格局冗余开始成为一个问题。v2 版本为了减小源映射整体大小，就义了一些简略性和灵活性。目前最新的版本是 v3。更多信息见 Source Map Revision 3。

格局

依照约定，源映射文件跟源文件领有雷同的名称，只是后缀为 .map。比方 page.js 的产生的源映射名称是 page.js.map。这个约定并不是强制性的。

源映射整个文件是一个 JSON 对象：

{
  "version" : 3,
  "file": "out.js",
  "sourceRoot": "","sources": ["foo.js","bar.js"],"sourcesContent": [null, null],"names": ["src","maps","are","fun"],"mappings":"A,AAAB;;ABCDE;"
}

• version：source map 标准版本，必须是一个正整数。
• file：可选项，转换后产生的源映射文件名。
• sourceRoot：可选项，资源更门路，在服务器上从新定位源文件和移除 sources 中反复的值有用途。这个值会事后增加到 sources 字段中每一个值。如果是跟源文件雷同的门路，则为空。
• sources：寄存 mappings 中应用的源文件。
• sourcesContent：可选性，寄存源内容。列表的程序跟 sources 字段中程序统一。如果一些源要依照名称检索，可能会应用 null。
• names：mappings 中应用的一些标识名。
• mappings：记录了映射信息的字符串。

联合示例看含意就更清晰了:

更多信息见 Source Map Revision 3。

应用

从 Chrome 39 开始，开发者工具中 Source Maps 设置项默认是开启的，更加具体的阐明见这里。

本地开发的时候，相似 Webpack 构建工具都反对生成 Source Map 文件，调试的时候在 Chrome 中就能够在开发者工具 Sources 栏中看到对应源代码地位。

在正式线上环境中，需不需要生成并部署 Source Map 文件，就看各自的思考，能够参考一下这篇文章 Should I Use Source Maps in Production?。要阐明一下，浏览器默认不会申请这类文件，不必放心带来额定的申请。如果想要不便排查线上的问题，又不想他人查看源码，服务器能够对 Source Map 文件的拜访进行限度。

在正式线上环境中，没方法随时可能操作用户的电脑排查问题，出现异常的时候，假如有 Source Map 文件，该如何进行解决？由此有了上面的疑难：

1. 如何检测是否有对应 Source Map 文件？
2. 如何获取到 Source Map 文件？
3. 如何解析 Source Map 文件？

上面针对这三个问题，顺次进行解答。

如何检测是否有 Source Map 文件？

如果压缩后同时生成了 Source Map 文件，那么在压缩后代码的最初一行会是这样：

// js 文件最初一行
//# sourceMappingURL=<url>

// css 文件最初一行
/*# sourceMappingURL=<url> */

所以在出现异常时，失去异样所处的文件之后，判断该文件内容中是否有下面的标记，就能够判断是否有 Source Map 文件。source-map-support 中就是这样进行判断。

如何获取到 Source Map 文件？

在第一个问题外面，晓得了有 Source Map 文件，同时也就获取了文件所在位置，间接去申请就能够了。在标准中，举荐在响应头部返回 SourceMap 指向关联的 Source Map 文件，在最新 Chrome 中试了下，并不会默认带上的，可能须要本人手动设置。这个是示例页面。

如何解析 Source Map 文件？

了解标准外面编码的形式，就能够反向的进行解析。现有 source-map 库提供了解析的性能。这个是示例页面。

什么时候

在下面曾经晓得怎么去应用 source map 文件，那么该什么时候去进行这个过程？下面给出的示例，都是在前端进行解决，实际上服务器端也能够进行解决，这个时候须要思考的因素有：

• 是否会造成影响主流程的运行，因为如果放在前端解决，JavaScript 是单线程，可能会产生影响。
• 是否能承受额定的申请，下面示例中就有申请 source map 文件，其大小个别都比压缩后源文件要大。
• 是否能承受源码透露的危险。

前端异样解决上报，总的来说是为了及时甚至提前发现问题并解决，为用户提供更好的体验，也为改良产品提供数据参考。从这个不便来看，异样解决上报是一个辅助的性能，应该尽量减少占有的资源，所以 source map 的解析倡议放到服务器端解决。

参考资料

• Source Map Revision 3 Proposal
• JavaScript Source Map 详解
• source-map-support
• source-map