[TOC] >[danger] ##### 给自己的标记 [虽然收费但是写的很好](https://kaiwu.lagou.com/course/courseInfo.htm?courseId=88#/detail/pc?id=2267) >[success] # source map -- 源代码地图 ~~~ 1.简单的来理解，webpack打包后的代码，又混淆又压缩的，代码出现问题想调试，看到这一堆乱糟糟的 代码要怎么解决，我们是不是可以出一个映射文件，这个文件是没打包正常的代码，这样就可以快速定位 这个就是'source map' 2.当然也要注意生产环境不要把'source map'文件暴露出去，这样整个业务逻辑都暴露出去了，开发环境使用 效果更佳 ~~~ [mdn](https://developer.mozilla.org/zh-CN/docs/Tools/Debugger/How_to/Use_a_source_map) [阮一峰老师source map讲解](http://www.ruanyifeng.com/blog/2013/01/javascript_source_map.html) [简单易懂系列](https://www.jianshu.com/p/d929fe4c62da) >[danger] ##### source map 文件构成 ~~~ { version : 3, // Source map的版本，目前为3 file: "out.js", // 转换后的文件名 sourceRoot : "", // 转换前的文件所在的目录。如果与转换前的文件在同一目录，该项为空 sources: ["foo.js", "bar.js"], // 转换前的文件。该项是一个数组，表示可能存在多个文件合并 names: ["src", "maps", "are", "fun"], // 转换前的所有变量名和属性名 mappings: "AAgBC,SAAQ,CAAEA" // 记录位置信息的字符串 } ~~~ >[danger] ##### source map 如何和压缩文件关联 ~~~ 1.source-map 的基本原理是，在编译处理的过程中，在生成产物代码的同时生成产物代码中被转换的部分 与源代码中相应部分的映射关系表。有了这样一张完整的映射表，我们就可以通过 Chrome 控制台中的 "Enable Javascript source map"来实现调试时的显示与定位源代码功能 2.根据'source-map' 原理，我们需要将生成的'source-map' 和对应压缩后的代码产生关联，具体用法 只要在转换后的代码尾部'//# sourceMappingURL= map文件' , 举个例子'//# sourceMappingURL=./bundle.js.map' ~~~ * 谷歌控制台  >[info] ## 通过webpack 配置source map ~~~ 1.webpack 也同样可以配置对应打包后文件的'source map'，通过配置'devtool' 字段 2.webpack对source map支持12中不同的方式 ~~~ >[danger] ##### webpack source map 几种模式理解 ~~~ webpack source map 一般是下面几种的组合产生的各种结果 1.'eval': 是否使用eval 执行模块代码，单独使用该模式在编译文件末尾使用'eval + sourceURL' 来映射编译文件与源文件，具体内容不映射 ， 信息错误时不能定位到源文件的具体位置， 而是定位编译文件的位置(也就是说只会定位到错误文件，不会定位到代码具体位置) 该模式不会生成'sourceMap'文件 2.'source-map': 产生.map文件 3.'cheap': 不包含列信息也不包含loader的sourcemap 4.'module': 没有经过loader加工的sourcemap 比如开发时候使用const ,对应'sourcemap'看的的依旧是const 而不是转换成es5的var 5.'inline':将.map作为DataURI嵌入，不单独生成.map文件（这个配置项比较少见） 6.'hidden' - 代码不引入source-map，手动引入 7.'nosources' - 无法在控制台查看源文件 ~~~ * webpack对source map支持12中不同的方式 ~~~ 'eval', 'cheap-eval-source-map', 'cheap-module-eval-source-map', 'eval-source-map', 'cheap-source-map', 'cheap-module-source-map', 'inline-cheap-source-map', 'inline-cheap-module-source-map', 'source-map', 'inline-source-map', 'hidden-source-map', 'nosources-source-map' ~~~ * 对其中几种的解释 ~~~ 1.'eval': 不生成source-map,仅能定位哪个文件出了错误 2.'eval-source-map': 生成source-map, 可定位错误具体的行 列信息 3.'cheap-eval-source-map': 生成source-map, 可定位错误具体的行信息，没有列的信息, 加工后的源代码 4.'cheap-module-eval-source-map': 生成source-map, 可定位错误具体的行信息没有列的信息, 未加工源代码 与手写一致 5.'inline-source-map': 使用dataURL的方式将source-map嵌入到代码中，会导致代码体积变大 6.'hidden-source-map': 生成了source-map， 但代码中没有引入该文件， 因此看不到效果 7.'nosources-source-map': 该模式可以看到错误的位置，但点击错误信息追踪看不到源代码，保护源代码不被暴露 ~~~ [Source Map 每种模式打包对比](https://webpack.js.org/configuration/devtool/#devtool) >[danger] ##### webpack source map 使用 ~~~ 1.开发模式/开发环境推荐使用'cheap-module-eval-source-map' 2.生成环境推荐'none',也可以选择'nosources-source-map'原因'可以看到错误定位但不暴露源代码' ~~~ ~~~ module.exports = { devtool: 'inline-source-map', // 配置source-map mode: 'production', entry, output: { path: path.join(__dirname, 'dist'), filename: '[name].js' }, module: { rules: [{ test: /\.js$/, exclude: /node_modules/, use: 'babel-loader' }, { test: /\.css$/, use: ['style-loader', 'css-loader'] }] }, devServer: { contentBase: './dist', // 指定托管的根目录 hot: true // 启用热更新 }, plugins: [].concat(htmlWebpackPlugins) } ~~~ >[danger] ##### 开发和生产应该怎么选 ~~~ 1.'开发环境'，通常我们关注的是构建速度快，质量高，以便于提升开发效率，而不关注生成文件的大小和访问方式。 '生产环境'，通常我们更关注是否需要提供线上 source map , 生成的文件大小和访问方式是否会对页面性能造成影响 等，其次才是质量和构建速度 2.首先开发过程中（开发环境）， cheap-module-eval-source-map，原因有以下三点： 2.1.使用框架的情况会比较多，以 React 和 Vue.js 为例，无论是 JSX 还是 vue 单文件组件，Loader 转换后差别都很大，我需要调试 Loader 转换前的源代码。 2.2.一般情况下，我编写的代码每行不会超过 80 个字符，对我而言能够定位到行到位置就够了，而且 省略列信息还可以提升构建速度。 2.3.这种模式下启动打包会比较慢，但大多数时间内我使用的 webpack-dev-server 都是在监视模式下 重新打包，它重新打包的速度非常快。 3.生产环境的打包，选择 none，它不会生成 Source Map 3.1.首先，Source Map 会暴露我的源代码到生产环境。如果没有控制 Source Map 文件访问权限的话， 但凡是有点技术的人都可以很容易的复原项目中涉及的绝大多数源代码，这非常不合理也不安全，我想很 多人可能都忽略了这个问题。 3.2.其次，调试应该是开发阶段的事情，你应该在开发阶段就尽可能找到所有问题和隐患，而不是到了生产环 境中再去全民公测。如果你对自己的代码实在没有信心，我建议你选择 nosources-source-map 模式， 这样出现错误可以定位到源码位置，也不至于暴露源码 ~~~ >[danger] ##### 推荐导读文章 [source map刨根问底系列](https://www.cnblogs.com/axl234/p/6500534.html) [如何正确使用 SourceMap？](https://shiguanghai.top/blogs/%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/%E5%89%8D%E7%AB%AF%E5%B7%A5%E7%A8%8B%E5%8C%96/%E5%A6%82%E4%BD%95%E6%AD%A3%E7%A1%AE%E4%BD%BF%E7%94%A8%20SourceMap.html#%E4%B8%8D%E5%90%8C%E9%A2%84%E8%AE%BE%E7%9A%84%E7%A4%BA%E4%BE%8B%E7%BB%93%E6%9E%9C%E5%AF%B9%E6%AF%94) [webpack 配置source map官网系列](https://webpack.docschina.org/configuration/devtool/) >[danger] ##### 问答 * 这个需要后续研究这个前端监控系统 ~~~ 1.生产环境下不建议使用source map(我也觉得不应该将代码的业务逻辑暴露给其他人), 但是在这种情况下， 线上报错我们应该如何来调试？ '答：' 一般情况下公司内应该是有前端监控系统的，一旦报错，可以把 sourcemap 上传到这个监控系统里面。 但是不要把 sourcemap 文件和静态资源的 cdn 一起发布到线上就好了 解决思路方式'hidden-sourcemap 配合 sentry' hidden-source-map 模式 在这个模式下，我们在开发工具中看不到 Source Map 的效果，但是它也确实生成了 Source Map 文件， 这就跟 jQuery 一样，虽然生成了 Source Map 文件，但是代码中并没有引用对应的 Source Map 文件， 开发者可以自己选择使用。 2.出于安全考虑 Chrome 隐藏了 source map 的请求，需要通过 net-log 来查询 ~~~