原文链接：深入SourceMap原理
一 Source Map是什么？
Source Map,顾名思义，是保存源代码映射关系的文件，相信用过webpack的开发者对它应该不会陌生。在项目开发完进行打包后，在打包的文件夹里通常除了js，css,图片字体等资源文件外，大家一定还见过xxx.js.map的文件。这种带map后缀的文件就是Source Map文件——它保存了源代码和转换之后代码（通常经过压缩混淆和其他转换）的关系。
下图展示了部分打包之后生成的Source Map文件:
下面是一个典型的Source Map文件的格式：
{
"version": 3,
"sources": [
"log.js",
"main.js"
],
"names": [
"sayHello",
"name",
"length",
"substr",
"console",
"log"
],
"mappings": "AAAA,SAASA,SAAUC,MACjB,GAAIA,KAAKC,OAAS,EAAG,CACnBD,KAAOA,KAAKE,OAAO,EAAG,GAAK,MAE7BC,QAAQC,IAAI,QAASJ,MCJvBD,SAAS"
}
二 为什么使用Source Map?
明白了什么是Source Map之后，大家肯定有个疑问，我们为什么需要Source Map?
由于现代前端项目的发展，前端代码变得越来越庞大和复杂。大部分源码都需要经过转换，才能投入到生产环境中使用。
常见的转换过程包括但不限于：
- 压缩混淆（UglifyJS）
- 编译（TypeScript, CoffeeScript)
- 转译（Babel）
- 合并多个文件，减少带宽请求。
经过上述转换过程的代码，往往都会变得面目全非，就像下面这样:
这样虽然对带宽很友好，但是调试起来就不是那么轻松了。我们在代码出错的时候，肯定最希望能定位其在源码中的位置。
比如下面这两个错误提示：
对于大多数开发者来说，希望看到的应该是第二种提示方式，而这就是Source Map能够输出的能力。
三 Source Map是怎么实现映射的？
在探索这个问题之前，可以先想想真实世界里对这种语言转换是怎么做的？
I AM CHRIS ——> Map ——> CHRIS I AM
现在我们要从CHRIS I AM还原到I AM CHRIS,Map里应该存储哪些信息呢？
3.1 最简单粗暴的方法
将输出文件中每个字符位置对应在输入文件名中的原位置保存起来，并一一进行映射。上面的这个映射关系应该得到下面的表格:
| 字符 | 输出位置 | 在输入中的位置 | 输入的文件名 |
|---|---|---|---|
| c | 行1，列1 | 行1,列6 | 输入文件1.txt |
| h | 行1,列2 | 行1,列7 | 输入文件1.txt |
| r | 行1,列3 | 行1,列8 | 输入文件1.txt |
| i | 行1,列4 | 行1,列9 | 输入文件1.txt |
| s | 行1,列5 | 行1,列10 | 输入文件1.txt |
| i | 行1,列7 | 行1,列1 | 输入文件1.txt |
| a | 行1,列9 | 行1,列3 | 输入文件1.txt |
| m | 行1,列10 | 行1,列4 | 输入文件1.txt |
备注: 由于输入信息可能来自多个文件，所以这里也同时记录输入文件的信息。
将上面表格整理成映射表的话，看起来就像这样(使用"|"符号分割字符)
mappings: "1|1|输入文件1.txt|1|6,1|2输入文件1.txt|1|7,1|3|输入文件1.txt|1|8,1|4|输入文件1.txt|1|9,1|5|输入文件1.txt|1|10,1|7|输入文件1.txt|1|1,1|9|输入文件1.txt|1|3,1|10|输入文件1.txt|1|4"（长度：144）
这种方法确实能将处理后的内容还原成处理前的内容，但是随着内容的增加，转换规则的复杂，这个编码表的记录将飞速增长。目前仅仅10个字符，映射表的长度已经达到了144个字符。如何进一步优化这个映射表呢？
备注：
mappings: "输出文件行位置|输出文件列位置|输入文件名|输入文件行号|输入文件列号,....."
3.2 优化手段1:不要输出文件中的行号
在经历过压缩和混淆之后，代码基本上不会有多少行（特别是JS，通常只有1到2行）。这样的话，就可以在上节的基础上移除输出位置的行数，使用";"号来标识新行。
那么映射信息就变成了下面这样
mappings: "1|输入文件1.txt|1|6,2|输入文件1.txt|1|7,3|输入文件1.txt|1|8,4|输入文件1.txt|1|9,5|输入文件1.txt|1|10,7|输入文件1.txt|1|1,9|输入文件1.txt|1|3,10|输入文件1.txt|1|4; 如果有第二行的话"（长度：129）
备注：
mappings: "输出文件列位置|输入文件名|输入文件行号|输入文件列号,....."
3.3 优化手段2：提取输入文件名
由于可能存在多个输入文件，且描述输入文件的信息比较长，所以可以将输入文件的信息存储到一个数组里，记录文件信息时，只记录它在数组里的索引值就好了。
经过这步操作后，映射信息如下所示：
sources: ['输入文件1.txt'],
mappings: "1|0|1|6,2|0|1|7,3|0|1|8,4|0|1|9,5|0|1|10,7|0|1|1,9|0|1|3,10|0|1|4;" (长度：65)
经过转换后mappings字符数从129下降到了65。
备注：
mappings: "输出文件列位置|输入文件名索引|输入文件行号|输入文件列号,....."
3.4 优化手段3: 可符号化字符的提取
经过上一步的优化，mappings字符数有了很大的下降，可见提取信息是一个很有用的简化手段，那么还有什么信息是能够提取的么？
当然。已输出文件中的Chris字符为例，当我们找到了它的首字符C在源文件中的位置(行1,列6)时，就不需要再去找剩下的hris的位置了，因为Chris可以作为一个整体来看待。想想源码里的变量名，函数名，都是作为一个整体存在的。
现在可以把作为整体的字符提取并存储到一个数组里，然后和文件名一样，在mapping里只记录它们的索引值。这样就避免了每一个字符都要记的窘境，大大缩减mappings的长度。
添加一个包含所有可符号化字符的数组：
names: ['I', 'am', 'Chris']
那么之前Chris的映射就从
1|0|1|6,2|0|1|7,3|0|1|8,4|0|1|9,5|0|1|10
变成了
1|0|1|6|0
最终的映射信息变成了:
sources: ['输入文件1.txt'],
names: ['I', 'am', 'Chris'],
mappings: "1|0|1|6|2,7|0|1|1|0,9|0|1|3|1" (长度: 29)
备注：
1. “I am Chris"中的"I"抽出来放在数组里，其实意义不大，因为它本身也就只有一个字符。但是为了演示方便，所以拆出来放在数组里。
2. mappings: "输出文件列位置|输入文件名索引|输入文件行号|输入文件列号|字符索引,....."
3.5 优化手段4: 记录相对位置
前面记录位置信息（主要是列）时，记录的都是绝对位置信息，设想一下，当文件内容比较多时，这些数字可能会变的很大，这个问题怎么解决呢？
可以通过只记录相对位置来解决这个问题（除了第一个字符）。
来看一下具体怎么实现的，以之前的mappings编码为例:
mappings: "1(输出列的绝对位置)|0|1|6(输入列的绝对位置)|2,7(输出列的绝对位置)|0|1|1(输入列的绝对位置)|0,9(输出列的绝对位置)|0|1|3(输入列的绝对位置)|1"
转换成只记录相对位置
mappings: "1(输出列的绝对位置)|0|1|6(输入列的绝对位置)|2,6(输出列的相对位置)|0|1|-3(输入列的相对位置)|0,2(输出列的相对位置)|0|1|-2(输入列的绝对位置)|1"
从上面的例子可能看不太出这个方法的好处，但是当文件慢慢大起来，使用相对位置可以节省很多字符长度，特别是对于记录输出文件列信息的字符来说。
3.6 优化手段5: VLQ编码
经过上面几步操作之后，现在最应该优化的地方应该就是用来分割数字的"|“号了。
这个优化应该怎么实现呢？
在回答之前，先来看这样一个问题——如果你想顺序的记录4组数字，最简单的就是用”|"号进行分割。
1|2|3|4
如果每个数字只有1位的话，可以直接表示成
1234
但是很多时候每个数字不止有1位，比如
12|3|456|7
这个时候，就一定得用符号把各个数字分割开，像我们上面例子中一样。还有好的方法嘛？
通过VLQ编码的方式，你可以很好的处理这种情况，先来看看VLQ的定义：
3.6.1 VLQ定义
A variable-length quantity (VLQ) is a universal code that uses an arbitrary number of binary octets (eight-bit bytes) to represent an arbitrarily large integer.
翻译一下：VLQ是用任意个2进制字节组去表示一个任意数字的编码形式。
VLQ的编码形式很多，这篇文章中要说明的是下面这种：
- 一个组包含6个二进制位。
- 在每组中的第一位C用来标识其后面是否会跟着另一个VLQ字节组,值为0表示其是最后一个VLQ字节组，值为1表示后面还跟着另一个VLQ字节组。
- 在第一组中，最后1位用来表示符号，值为0则表示正数，为1表示负数。其他组的最后一位都是表示数字。
- 其他组都是表示数字。
这种编码方式也称为Base64 VLQ编码，因为每一个组对应一个Base64编码。
3.6.2 小例子说明VLQ
现在我们用这套VLQ编码规则对12|3|456|7进行编码，先将这些数字转换为二进制数。
12 ——> 1100
3 ——> 11
456 ——> 111001000
7 ——> 111
- 对12进行编码
12需要1位表示符号，1位表示是否延续，剩下的4位表示数字
| B5© | B4 | B3 | B2 | B1 | B0 |
|---|---|---|---|---|---|
| 0 | 1 | 1 | 0 | 0 | 0 |
- 对3进行编码
| B5© | B4 | B3 | B2 | B1 | B0 |
|---|---|---|---|---|---|
| 0 | 0 | 0 | 1 | 1 | 0 |
- 对456进行编码
从转换关系中能够看到，456对应的二进制已经超过了6位，用1组来表示肯定是不行的，这里需要用两组字节组来表示。先拆除最后4个数(1000)放入第一个字节组，剩下的放在跟随字节组中。
| B5© | B4 | B3 | B2 | B1 | B0 | B5© | B4 | B3 | B2 | B1 | B0 | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 |
- 对7进行编码
| B5© | B4 | B3 | B2 | B1 | B0 |
|---|---|---|---|---|---|
| 0 | 0 | 1 | 1 | 1 | 0 |
最后得到下列VLQ编码:
011000 000110 110000 011100 001110
通过Base64进行转换之后：
最终得到下列结果:
YGwcO
3.6.3 转换之前的例子
通过上面这套VLQ的转换流程转换之前的例子，先来编码1|0|1|6|2.
转换成VLQ为：
1 ——> 1(二进制) ——> 000010(VLQ)
0 ——> 0(二进制) ——> 000000(VLQ)
1 ——> 1(二进制) ——> 000010(VLQ)
6 ——> 110(二进制) ——> 001100(VLQ)
2 ——> 10(二进制) ——> 000100(VLQ)
合并后编码为
000010 000000 000010 001100 000100
转换成Base64
BABME
其他也是按这种方式编码，最后得到的mapping文件如下：
sources: ['输入文件1.txt'],
names: ['I', 'am', 'Chris'],
mappings: "BABME,OABBA,SABGB" (长度: 17)
和第一节的mappings文件对比一样，是不是一样呢？
3.6.4 one more thing
在真实场景中，我们在mappings中经常可以看到不是5位的字符。大于5位好理解，可能表示的数字太大。比如123456789转换成Base64 VLQ编码就是qxmvrH。而少于5位的情况在于mappings的编码片段中可能不需要那么多信息就能进行映射，比如不需要Names属性，这样只通过4位信息也就能获取到映射关系了。一个编码片段可能会有以下几种长度：
- 5 - 包含全部五个部分：输出文件中的列号，输入文件索引，输入文件中的行号，输入文件中的列号，符号索引
- 4 - 输出文件中的列号，输入文件索引，输入文件中的行号，输入文件中的列号
- 1 - 输出文件中的列号
通过上面的讲解，相信大家一定对Source Map是如何映射源码转换后代码之间的位置关系有所了解。在了解了Source Map原理之后，日后再去使用它肯定能够得心应手。
