您是否曾希望，即使在合并和缩减代码后，也能在不影响性能的情况下，使客户端代码保持可读性，更重要的是可调试？现在，您可以通过源映射的神奇功能轻松实现。
源映射是一种将合并/缩减后的文件映射回未构建状态的方法。当您为生产而构建时，除了缩小和合并 JavaScript 文件之外，您还会生成一个源映射，其中包含有关原始文件的信息。在生成的 JavaScript 中查询特定行号和列号时，您可以在源映射中进行查找，该映射会返回原始位置。开发者工具（目前是 WebKit 每日版本、Google Chrome 或 Firefox 23 及更高版本）可以自动解析源映射，使其看起来像是在运行未缩小和未合并的文件。
此演示可让您右键点击包含生成的源的文本区域中的任意位置。选择“获取原始位置”将通过传入生成的行号和列号来查询源映射，并返回原始代码中的位置。请确保您的控制台已打开，以便查看输出结果。
现实世界
在查看 Source Maps 的以下实际实现之前，请确保您已在 Chrome Canary 版或 WebKit 每日夜版中启用源代码映射功能，方法是点击开发者工具面板中的设置齿轮图标，然后选中“启用源映射”选项。
Firefox 23 及更高版本在内置开发者工具中默认启用源映射。
为什么我应该关注源代码映射？
目前，源映射仅在未压缩/合并的 JavaScript 与压缩/未合并的 JavaScript 之间有效，但随着 CoffeeScript 等编译为 JavaScript 的语言的讨论，甚至可能增加对 CSS 预处理器（如 SASS 或 LESS）的支持，前景一片光明。
将来，我们可以轻松使用几乎所有语言，就好像带有源映射的浏览器原本就支持这些语言一样：
- CoffeeScript
- ECMAScript 6 及更高版本
- SASS/LESS 和其他
- 编译为 JavaScript 的几乎所有语言
来看看在 Firefox 控制台的实验性版本中对 CoffeeScript 进行调试的抓屏：
Google Web Toolkit (GWT) 最近添加了对 Source Maps 的支持。 GWT 团队的 Ray Cromwell 制作了一个精彩的抓屏，展示了实际源映射支持。
我编写的另一个示例使用 Google 的 Traceur 库，您可以通过此库编写 ES6（ECMAScript 6 或 Next）并将其编译为 ES3 兼容代码。Traceur 编译器还会生成源映射。看看这个 ES6 trait 和类演示，它们就像是浏览器原生支持它们，这都归功于源映射。
演示中的文本区域还允许您编写 ES6，该区域将实时编译并生成源映射以及等效的 ES3 代码。
源映射的工作原理是什么？
目前，唯一支持源映射生成的 JavaScript 编译器/缩减器是 Closure 编译器。（稍后我会说明其使用方法。）在您合并和缩减 JavaScript 后，它旁边会有一个源映射文件。
目前，Closure 编译器不会在末尾添加特殊注释，用于向浏览器开发者工具表明源映射可用：
//# sourceMappingURL=/path/to/file.js.map
这样，开发者工具就能将调用映射回它们在原始源文件中的位置。之前注释 pragma 为 //@，但由于存在一些问题，并且 IE 条件编译注释，已做出将其更改为 //# 的决定。目前，Chrome Canary 版、WebKit Nightly 和 Firefox 24 及更高版本支持新的注释 pragma。此语法更改也会影响 source网址。
如果您不喜欢这种奇怪注释的想法，也可以在编译的 JavaScript 文件中设置一个特殊标头：
X-SourceMap: /path/to/file.js.map
像注释一样，它会告诉源映射使用者在哪里查找与 JavaScript 文件关联的源映射。此标头还可以解决以不支持单行注释的语言引用源映射的问题。
只有当您启用了源映射并打开开发者工具时，才会下载源映射文件。您还需要上传原始文件，以便开发者工具可以在必要时引用和显示它们。
如何生成源映射？
您需要使用 Closure 编译器来缩减、串联和生成 JavaScript 文件的源映射。命令如下所示：
java -jar compiler.jar \
--js script.js \
--create_source_map ./script-min.js.map \
--source_map_format=V3 \
--js_output_file script-min.js
两个重要的命令标志是 --create_source_map 和 --source_map_format。这是必需的，因为默认版本为 V2，而我们只想使用 V3。
源映射详解
为了更好地了解源映射，我们将举一个由 Closure 编译器生成的源映射文件的小例子，并深入了解“映射”部分的工作原理。以下示例与 V3 规范示例略有不同。
{
version : 3,
file: "out.js",
sourceRoot : "",
sources: ["foo.js", "bar.js"],
names: ["src", "maps", "are", "fun"],
mappings: "AAgBC,SAAQ,CAAEA"
}
如上所示，源映射是一个包含大量有用信息的对象字面量：
- 源映射所基于的版本号
- 所生成代码的文件名（您的已缩小/已合并的生产文件）
- sourceRoot 可让您在来源之前添加文件夹结构 - 这也是一种节省空间的技术
- 来源包含合并的所有文件名
- 名称包含出现在代码中的所有变量/方法名称。
- 最后，映射属性就是使用 Base64 VLQ 值的奇迹所在。空间的节省就是在这里完成的。
Base64 VLQ 并保持源映射较小
起初，源映射规范包含所有映射的输出非常冗长，导致源映射的大小大约是所生成代码的大小的 10 倍。版本 2 将大小缩减了约 50%，而版本 3 又缩减了 50%，因此对于 133 kB 的文件，最终得到的源映射大小约为 300 kB。
那么，他们是如何在仍然保持复杂映射的同时缩减应用大小的呢？
使用 VLQ（可变长度数量）将值编码为 Base64 值。映射属性是一个超大字符串。该字符串中有分号 (;)，表示生成的文件中的行号。每行中都有逗号 (,) 代表该行中的每个线段。在可变长度字段中，每个分段均为 1、4 或 5。有些元素可能显示得更长，但包含扩展位。每个片段都基于前一个片段构建，这有助于减小文件大小，因为每个位都与其之前的片段相关。
如上所述，每个段的可变长度可以是 1、4 或 5。此图被视为可变长度为 4 且包含一个扩展位 (g)。我们将分解该段，并向您展示源映射是如何确定原始位置的。
上面显示的值纯粹是 Base64 解码值，需要经过一些额外的处理才能获取其真实值。每个细分通常计算出五项内容：
- 生成的列
- 显示此内容的原始文件
- 原始行号
- 原始列
- 原始名称（如果有）
并非每个段都有名称、方法名称或参数，因此所有段都会在四到五个可变长度之间切换。上面段图中的 g 值称为扩展位，它允许在 Base64 VLQ 解码阶段进一步优化。扩展位允许您在分段值的基础上进行构建，因此您可以存储大数字而无需存储大数字，这是一种非常巧妙的空间节省技术，其根为 midi 格式。
上图 AAgBC 经过进一步处理后将返回 0、0、32、16、1 - 32 是帮助构建以下值 16 的扩展位。B 采用 Base64 完全解码后为 1。因此，使用的重要值为 0、0、16、1。这样我们就知道生成文件的第 1 行（行数按分号保留）列 0 映射到文件 0（文件 0 的数组是 foo.js），即第 16 行的列 1。
为了展示片段是如何解码的，我将引用 Mozilla 的 Source Map JavaScript 库。您也可以查看 WebKit 开发者工具源代码映射代码（同样使用 JavaScript 编写）。
为了正确理解我们如何从 B 获得值 16，我们需要对按位运算符以及该规范如何用于源映射有基本的了解。通过使用按位 AND (&) 运算符比较数字 (32) 和 VLQ_CONTINUATION_BIT（二进制 100000 或 32），前一个数字 g 被标记为延续位。
32 & 32 = 32
// or
100000
|
|
V
100000
这会在各位位置返回 1，这两个位都出现。因此，33 & 32 的 Base64 解码值将返回 32，因为它们仅共享 32 位位置，如上图所示。然后，对于前面的每个延续位，位“shift value”增加 5。在上面的示例中，它只移动了 5 次，因此将 1 (B) 向左移动了 5。
1 <<../ 5 // 32
// Shift the bit by 5 spots
______
| |
V V
100001 = 100000 = 32
然后将该值从 VLQ 带符号值进行转换，方法是将数字 (32) 右移一个位。
32 >> 1 // 16
//or
100000
|
|
V
010000 = 16
这就是我们将 1 变成 16 的过程。这似乎有点过于复杂，但一旦数字开始越来越大，就显得更加有意义了。
潜在的 XSSI 问题
该规范提到了因使用源映射而可能出现的跨网站脚本包含问题。为了缓解此问题，建议您在源映射的第一行前面加上“)]}”来故意使 JavaScript 失效，这样就会抛出语法错误。WebKit 开发者工具可以处理此问题。
if (response.slice(0, 3) === ")]}") {
response = response.substring(response.indexOf('\n'));
}
如上所示，系统会对前三个字符进行切片，以检查它们是否与规范中的语法错误匹配，如果匹配，则删除第一个新行实体 (\n) 之前的所有字符。
sourceURL 和 displayName 的实际运用：评估函数和匿名函数
虽然不属于源映射规范，但下面的两种惯例可以让您在使用评估和匿名函数时大大简化开发工作。
第一个帮助程序看起来与 //# sourceMappingURL 属性非常相似，并且实际上在源映射 V3 规范中提到了。通过在代码中添加以下特殊注释（将进行评估），您可以为评估命名，使其在您的开发者工具中显示为更符合逻辑的名称。查看使用 CoffeeScript 编译器的简单演示：
演示：通过 source网址 查看 eval() 的代码以脚本形式显示
//# sourceURL=sqrt.coffee
另一个帮助程序可让您使用匿名函数当前上下文中提供的 displayName 属性来命名匿名函数。分析以下演示，了解 displayName 属性的实际运用。
btns[0].addEventListener("click", function(e) {
var fn = function() {
console.log("You clicked button number: 1");
};
fn.displayName = "Anonymous function of button 1";
return fn();
}, false);
在开发者工具中对代码进行性能分析时，系统将显示 displayName 属性，而不是 (anonymous) 之类的属性。不过，displayName 几乎已陷入停滞，不会实施到 Chrome 中。但希望仍然没有消除，系统提出了一种名为 debugName 的更好的方案。
截至编写时，评估命名仅适用于 Firefox 和 WebKit 浏览器。displayName 属性仅适用于 WebKit 每日构建。
让我们团结起来
目前关于添加到 CoffeeScript 的源映射支持，已就此展开了讨论。请查看相关问题并添加支持，以便将源映射生成内容添加到 CoffeeScript 编译器中。这对于 CoffeeScript 及其忠实的关注者来说将是一个巨大的胜利。
UglifyJS 还有一个源代码映射问题，您应该也检查一下。
大量工具可生成源映射，包括 Coffee 编译器。在我看来，这个问题现在已经说不完了。
可用于生成源映射的工具越多，对我们来说就越好，因此请去向您喜爱的开源项目提问或添加源映射支持。
不完美
目前，源映射未能满足的一个方面是监视表达式。问题在于，尝试检查当前执行上下文中的参数或变量名称不会返回任何内容，因为它们实际上不存在。这需要执行某种反向映射，才能对照编译的 JavaScript 中的实际参数/变量名称，查找您要检查的参数/变量的真实名称。
这当然是一个可解决的问题，如果我们更加关注源映射，我们会看到一些令人惊叹的功能和更好的稳定性。
问题
最近，jQuery 1.9 从官方 CDN 分发时增加了对源映射的支持。此外，该文档还指出了在 jQuery 加载前使用 IE 条件编译注释 (//@cc_on) 时的一个特殊错误。此后有一个提交，可通过将 sourceMapping网址 封装在多行注释中来缓解此问题。吸取经验教训不使用条件注释，
之后，通过将语法更改为 //#，此问题已得到解决。
工具和资源
下面还提供了另外一些资源和工具，供您参考：
- Nick Fitzgerald 有一个支持源映射的 UglifyJS 分支
- 保罗·爱丽诗 (Paul Ireland) 提供了一个实用的小演示，其中展示了源代码映射
- 查看 WebKit 更改集，了解此发布时间
- 该变更集还包含一个布局测试，让整篇文章都开始了
- Mozilla 存在一个错误，您应在内置控制台中跟踪源映射的状态
- 康拉德·欧文 (Conrad Irwin) 为所有 Ruby 用户编写了一个超级实用的源映射 gem
- 关于 eval 命名和 displayName 属性的一些补充内容
- 您可以查看 Closure Compilers 源代码以创建源代码映射
- 提供了一些有关对 GWT 源代码映射的支持的屏幕截图和谈话
源映射在开发者工具集中是非常强大的实用程序。它的超级实用之处在于，它能够使 Web 应用保持精简但易于调试。这也是一个非常强大的学习工具，对新手开发者来说，了解经验丰富的开发者如何构建和编写应用，而不必费心翻阅无法阅读的精简版代码。
还等什么？立即开始为所有项目生成源代码映射！