为什么是内联源地图？

我搜索了一下，发现人们使用内联源代码映射的唯一原因是用于开发。内联源映射不应该在生产中使用。

用缩小的文件内联源映射的理由是，浏览器在开发和生产过程中解析的是完全相同的 JavaScript。像 闭包编译器这样的缩小器不仅仅是缩小了代码。使用 高级选择，它还可以做一些事情，如: 死代码删除，函数内联，或积极的变量重命名。这使得缩小的代码(可能)在功能上不同于源文件。

当然，这仍然可以通过引用外部源映射文件来完成，但是有些人似乎更喜欢为他们的构建过程进行内联。

像 Browserify或 Webpack这样的 JS 捆绑工具将捆绑所有的 .js文件输入一个或多个捆绑包，甚至在开发模式下也是如此。因此，在这种情况下，将内联源映射添加到生成的 bundle 是帮助调试而不带来额外文件的最简单方法。

在某些情况下，您可能希望将内联源代码映射包含到已计算的代码中。例如，你有一个咖啡脚本输入字段，你想启用调试咖啡脚本中的代码。有一个关于已计算代码中源映射的堆栈溢出问题:

使用已计算代码获取源映射

您可以在注释中包含@source URL 来指定您的 eval 代码的 URL 并加载映射文件(参见 SourceMap Spec 3的第8页)。但是并不总是可以将文件写到某个位置。

cheap-module-source-map对于生产构建来说要好得多。

在测试时，inline-source-map用于进行快速而粗糙的构建

如果你正在安卓设备上远程调试 Chrome，那么 Chrome 调试器不能访问任何它想要访问的文件，这些文件包括单独的地图文件。如果将它们包含在内联中，就不会出现这个问题。

如果你正在开发一个浏览器扩展，内联源代码地图是唯一的调试选项，因为扩展本身不能访问源代码地图文件——即使有可能你必须指定你的所有源代码地图文件在 Manif.json (浏览器扩展的配置文件)。