今天我了解到可以将源映射直接包含在缩小的JavaScript文件中，而不是将它们放在单独的example.min.map文件中。我想知道：为什么有人想做这样的事情？
拥有源映射的好处对我来说很清楚：例如，在运行缩小的文件时，可以使用原始的、未压缩的源文件调试错误。最小化的好处也很明显：源文件的大小大大减少，使浏览器下载速度更快。
那么，鉴于映射的大小甚至大于缩小代码本身，为什么我要将源映射包含在缩小的文件中呢？
我四处搜索，我能看到人们内联源映射的唯一原因是用于开发。内联源映射不应在生产中使用。
将源映射与缩小的文件内联的理由是浏览器在开发和生产中解析完全相同的 JavaScript。像闭包编译器这样的简化器不仅仅是"仅仅"缩小代码。使用高级选项，它还可以执行以下操作：删除死代码、函数内联或主动变量重命名。这使得缩小的代码（可能）在功能上与源文件不同。
当然，这仍然可以通过引用外部源映射文件来完成，但有些人似乎更喜欢在他们的构建过程中内联。
如果您在安卓设备上远程调试 Chrome，Chrome 调试器无法只访问设备上所需的任何文件，其中包括单独的地图文件。如果以内联方式包含它们，则不会遇到此问题。
Browserify或Webpack这样的JS捆绑工具将捆绑所有.js文件输入一个或多个捆绑包，即使在开发模式下也是如此。因此，在这种情况下，将内联源映射添加到生成的捆绑包是帮助调试而无需额外文件的最简单方法。
在某些情况下，您可能希望将内联源映射包含在计算的代码中。例如，您有一个咖啡脚本输入字段，并且您想在咖啡脚本中启用对代码的去虫处理。有一个关于评估代码中的源映射的堆栈溢出问题：
获取使用计算代码的源映射
您可以在注释中包含@sourceURL以指定评估代码的 URL 并加载映射文件（请参阅 SourceMap 规范 3 的第 8 页）。但并不总是可以将文件写入某个位置。
如果您正在开发浏览器扩展，内联源映射是调试的唯一选项，因为扩展本身无法访问源映射文件 - 即使您可能必须在 manifest.json（浏览器扩展的配置文件）中指定所有源映射文件。
cheap-module-source-map对于生产构建来说要好得多。
inline-source-map用于在测试时进行快速和脏的构建
用例（对我来说）是不支持源映射的非浏览器环境（或者根本不支持，因此需要 webpack）。
或者另一种说法，没有网络的webpack。