[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 來查詢 ~~~