1️⃣ Source Map 源码地图

前端发展到现阶段，很多时候都不会直接运行源代码，可能需要对源代码进行合并、压缩、转换等操作，真正运行的是转换后的代码 , 这就给调试带来了困难，因为当运行发生错误的时候，我们更加希望能看到源代码中的错误，而不是转换后代码的错误
为了解决这一问题，chrome浏览器率先支持了source map，其他浏览器纷纷效仿，目前，几乎所有新版浏览器都支持了source map
source map 实际上是一个配置，配置中不仅记录了所有源码内容，还记录了和转换后的代码的对应关系
image.png
image.png

1️⃣ 最佳实践

source map 应在开发环境中使用，作为一种调试手段
source map 不应该在生产环境中使用，source map的文件一般较大，不仅会导致额外的网络传输，还容易暴露原始代码。即便要在生产环境中使用source map，用于调试真实的代码运行问题，也要做出一些处理规避网络传输和代码暴露的问题。

1️⃣ webpack中的source map

使用 webpack 编译后的代码难以调试，可以通过 devtool 配置来优化调试体验
概述： 一种将压缩/编译文件中的代码映射回源文件中的原始位置的技术，让我们调试代码不在困难
详细配置见官网：配置 -> devtool
介绍

  1.   1. cheap 只保留行, 编译速度快
  2.   2. eval webpack 生成的代码（每个模块彼此分开，并使用模块名称进行注释）, 编译速度快
  3.   3. inline 以 base64 方式将 source-map 嵌入到代码中，缺点造成编译后代码体积很大
  4.   4. module会将loader的source map加入 调试更加友好

基本使用介绍 ( 外部: 源码地图重新生成一个文件 | 内联: 源码地图嵌入带代码中 )

  1.   1. source-map：外部，错误代码的准确信息和源代码的错误位置
  2.   2. inline-source-map：内联，错误代码的准确信息和源代码的错误位置
  3.   3. hidden-source-map：外部，错误代码的错误原因但是没有错误位置，不能追踪源代码的错误，只能提示到构建后代码的错误位置
  4.   4. eval-source-map：内联，每一个文件都生成对应的 source-map，都在eval，错误代码的准确信息和源代码的错误位置
  5.   5. nosources-source-map：外部，找到错误代码的准确信息，但是没有任何源代码信息
  6.   6. cheap-source-map：外部，找到错误代码的准确信息，但是没有任何源代码信息（只能精确到行）
  7.   7. cheap-module-source-map：外部，找到错误代码的准确信息，但是没有任何源代码信息（只能精确到行）

推荐使用：

  1.   1. 开发环境： 
  2.      1. 推荐：cheap-module-eval-source-map
  3.      2. 速度快（ eval > inline > cheap > ... ）
  4.         1. cheap-eval-source-map
  5.         2. eval-source-map
  6.      3. 调试友好
  7.         1.  cheap-module-eval-source-map
  8.         2.  cheap-eval-source-map
  9.   2. 生产环境：生产环境下推荐使用外部，因为内联的话内存会比较大
  10.      1. 推荐： cheap-module-source-map
  11.      2. 源代码需要隐藏
  12.         1. nosources-source-map：全部隐藏
  13.         2. hidden-source-map：只会隐藏源代码，会提示构建后代码错误信息
  14.      3. 调试需要更友好
  15.         1.  cheap-module-source-map

image.png

  1. module.exports = {
  2.       devtool: 'cheap-module-eval-source-map', // 开发环境推荐
  3.       devtool: 'cheap-module-source-map' // 生产环境推荐
  4. }