在Web前端开发中，通常会对生产环境中的代码进行压缩和混淆，以减少代码量，提高源代码安全性。但是，当生产环境中出现JS错误时，压缩和混乱的代码也会使定位错误变得更加困难。
我们先来看一个爱奇艺智能前端异常监控平台(简单的金鹰眼)检测到的错误日志：
图1鹰眼收集的JS错误示例
可以看到，压缩后的错误行号和列号已经丢失，函数名已经转换，很难确定错误的真实文件名。这样，很难根据压缩代码的错误信息定位错误，但在线代码必须压缩并上传。
如何平衡？SourceMap是解决这一矛盾的利器。本文将介绍源图的基本概念及其在前端异常监控中的应用、设计和实践。
源图介绍
源代码映射是存储源代码和编译代码之间映射关系的信息文件，包含代码转换前后的位置信息。目前各种主流的打包工具都支持源图的生成，比如： Uglify JS、Grunt、glow、Webpack等等。源图的生成通常在项目打包的编译阶段进行。打包工具首先将源代码解析成抽象语法树。生成编译后的代码时，也就是图2中生成的过程中，使用AST中节点的源信息来生成Source Map。
图2编译和生成源映射
第二，使用源代码图进行JS错误收集和错误分析
JS错误一般可以通过window.addEventListener来收集来监控错误事件，而框架错误一般是通过框架暴露的钩子函数来收集的，比如Vue.config.errorHandler在收集到的错误中，错误堆栈信息可以从Error.prototype.stack中解析出来
在获得错误堆栈信息和源映射文件的内容后，您可以通过Mozilla的源映射库找到错误。该库中的SourceMapConsumer实例表示已解析的源映射的相关信息。我们可以通过提供该实例的文件位置和文件内容来查询生成的源中原始文件位置的信息。
目前各大监控平台都有源码图的解析功能进行错误监控。比如开源监控平台Sentinel支持Webpack插件和自带的CLI工具上传地图文件进行解析，支付平台Fundebug支持通过前端UI、自带的CLI和接口上传地图文件进行解析。但是这些平台也有一些缺点，比如有的不支持用户选择文件进行关联匹配，有的在用户选择地图匹配不成功时场景交互体验不友好。受此启发，我们基于简单的金毛监控系统开发了Source Map功能，它具有以下优点：
支持更简单的配置，通过Webpack的Plugin上传Source Map文件，上传过程中的异常不影响项目的整体编译过程，代码入侵低。支持更多的源图文件上传和选择方式，以适应更多的业务错误监控场景，在使用过程中有更清晰的提示和更友好的交互。支持地图文件管理功能，新版本可以通过选择项目名称与版本号的关联，选择版本历史的地图文件进行匹配。下面详细介绍源图在监控系统中的应用，简单金毛源图的功能设计和实践。
三、源图在监控系统中的应用
将源图应用于前端异常监控系统，需要解决的主要问题是用户如何上传源图，监控系统如何将源图与错误信息关联。考虑到易用性，简单的golden retriever SourceMap函数支持三种使用模式：手动上传单个JS错误栈的SourceMap，集成插件自动上传关联的JS错误栈信息，单个JS错误栈从Source Map列表中选择关联。如图3所示。
图3鹰眼源图三大功能
因此，总体结构如下：
图4整体架构
以下是每个模块的介绍：
源图自动上传插件(支持Webpack3):用户可以在项目打包过程中集成这个插件，自动上传生成的源图。这个插件可以在Webpack中输出A，不影响项目的编译过程。
sset 到 output目录之后，获取打包生成的map文件并执行上传逻辑。并且可以通过参数配置可以选择在Webpack编译完成执行后对map文件进行删除，不影响上线流程。鉴于历史项目使用Webpack老版本较多，简单的金毛针对Webpack不同的版本进行了兼容优化。手动上传Source Map模块：使用者可针对单条JS错误，上传单个Source Map进行匹配，并且进行了同名检测的提示，在能够自助上传map外也能通过提示减少错误匹配的情况。Source Map自助选择模块：提供了可以通过Source Map管理中心进行选择map进行关联的功能，对于不能每次每个版本都能上传Source Map文件的项目，能够进行列表和搜索选择需要匹配的map文件。Source Map定位展示模块：展示JS报错对应的真实源代码及位置。Source Map管理中心：集中管理Source Map文件的添加删除。上面提到的三种使用方式是互补的关系，其中集成插件自动上传关联JS错误堆栈信息的方式是非常建议使用者接入的，其优势在于可方便地集成到项目的自动化构建发布流程。接入一次之后，收到JS报错时，便可查看此报错在源代码的位置。实现流程如图五示:
SourceMap自动上传插件拉取项目打包生成的Source Map文件。调用文件上传中心接口上传文件。文件上传中心有独立的鉴权机制、对接了网络安全服务。获取SourceMap文件存储信息后连同项目、版本提交至Source Map管理中心。提交完成后可以删除构建过程中产生的Source Map文件。使用者在前端异常监控系统查看JS报错时，监控系统根据JS报错的项目、版本号从SourceMap管理中心获取Source Map文件。调用Mozillasource-map库进行解析关联，对源代码信息进行可视化展示。图五 Hawkeye Source Map自动上传插件流程设计
四、项目中接入
在项目中接入Source Map自动上传插件的方法及使用技巧如下：
初始化监控平台接入代码时需要携带versionNum字段，该字段为当前项目的版本号，以便于后期错误堆栈和项目map文件进行版本管理处理。在项目打包时生成map文件（需要独立的map文件）。Webpack对于Source Map的生成配置，建议模式使用hidden-source-map，其能够生成完整独立的map文件且不会泄露sourceMappingURL，但缺点是会造成编译耗时增加。cheap-source-map和cheap-module-source-map因省略一些内容，并不会准确完整的还原错误位置。打包部署项目时集成map上传插件, 在devDependencies中安装插件，在项目中的Webpack的plugin配置中增加该插件配置。若接入监控平台时正确传入版本号和项目名称，并且在项目打包时通过map上传插件上传正确版本及项目名称的map文件。简单的金毛在发生错误上报堆栈信息时会自动将JS名称和map文件进行匹配，显示其错误正确的源码地址。若无法自动匹配时，也可以从Source Map管理中心选择该项目和版本对应的map文件进行匹配，或者手动上传map文件自行匹配。在简单的金毛监控后台的使用方式如图六标注示意：
图六 Hawkeye Source Map功能接入示例
五、总结与展望
我们再看开篇提到的错误，在简单的金毛管理系统中Source Map视图下，可以很方便地看到真实文件名和代码行号了，如图七。由于可以直接定位到JS出错的源代码位置，接入了此功能的项目，JS错误定位排查效率得到了极大的提升。
图七 简单的金毛JS错误SourceMap视图
在一些项目生成Source Map以及集成上传Source Map插件的实践中，我们也遇到过一些难点：
1、在一些采用自定义Webpack配置打包的项目中，按照官方常规的devtool:hidden-source-map配置总会使得一些打包生成的JS文件体积增大，除了单独生成的Source Map文件，在一些编译后的JS中混入了一些SourceMap的内容。我们通过详细查看这些体积增大的JS文件的特点和内容，最终对vue-loader、css-loader分别指定CSS的Source Map选项关闭解决问题。
2、微前端项目的Source Map关联问题。在一些微前端架构项目中，微前端独立上线，有独立的版本控制，而采集报错的Hawkeye JSSDK只需集成在基座项目，微前端打包上线的流程中无法获取基座的版本，会造成SourceMap文件无法自动关联匹配。我们采取一种比较简洁的方式，在采集JSSDK中支持传入微前端版本的函数，在基座项目中根据微前端的标识等计算获取微前端的版本，当采集到报错投递时，将微前端的版本一同投递。这样后台关联时，优先匹配微前端版本号，其次匹配基座版本号，即可成功自动关联。
3、因为准确的定位错误需要上传完整的独立map文件，在个别较大的项目中，打包生成Source Map文件时，会影响编译速度，比较坏的情况下会增加80%的编译时间。所以后续考虑根据这些项目自身情况，独立封装和优化SourceMap生成模块，而不是通过指定打包工具的选项执行其内置生成流程，尽量减少对项目整体打包耗时的影响。
另外，根据接入项目的情况，简单的金毛Source Map自动上传插件后续也会支持更多打包构建工具，比如rollup、gulp。