Babel它是一個編譯器可以讓你使用最新版本的ES規範比如ES2015（ES6），ES2016（ES7），ES2017（ES8）的寫法並把它編譯成老的ES5的寫法。 首先babel的轉換其實做了兩件事情

語法轉換新API的polyfill相容但是但是，"平平無奇"的babel本身只會轉義語法，但是我們還想用等等。所以就會有這麼大一堆不明所以的東西 @babel/polyfill，@babel/preset-env，@babel/plugin-transform-runtime，@babel/runtime

@babel/polyfill

很容易理解，它就是各種API墊片,只要在主入口引用，就能完美使用各種新的API，完全沒有任何需要配置的地方。 但是但是，這樣就是把整個第三方墊片引入，打包出來會非常的大。所以就用到接下來的@babel/preset-env

@babel/preset-env

@babel/preset-env 主要乾的事情呢，根據你的設定表示你要啥，它就給你啥，不多給也不少給。使用@babel/preset-env最主要的配置欄位就是和

target

target表示所以編譯的程式碼執行的環境，可以是瀏覽器，可以是node，只要設定相應的欄位，它就能根據規則插入和轉義相應的語法跟API 例如以下的表示相容市場佔有率>1%，瀏覽器的最新兩個版本，ie8以下不相容

useBuiltIns

useBuiltIns有三種取值，不同的取值會影響API的匯入方式 false就是不用polyfill，如果在業務入口 , 會無視 .browserslist 將所有的 polyfill 載入進來。entry需要手動，它會根據中的配置來過濾出polyfillusage不需要手動(加上也無妨，編譯時會自動去掉), 且它會根據中的配置來過濾出polyfill + 業務程式碼使用到的新 API 按需進行 polyfill。useage並不會對第三方包做檢測，所以如果某些第三包使用高階的API那麼在低版本的瀏覽器上也是會報錯的，例如：基本上的開發使用+已經完全很完美了 但是以上看起來好完美，但是還有一個巨大問題！！！ 以上所有的墊片的匯入都是直接掛載在全域性物件上的，對於寫業務API的時候這樣並不影響使用，但是如果對於開發第三方包的情況，babel-polyfill 會汙染全域性變數，給很多類的原型鏈上都作了修改，這種情況就會變得非常不可控。

@babel/plugin-transform-runtime和@babel/runtime 讓Babel在更進一步

更改babel配置 其中的corejs引數有坑，後面說! 我們在來看看打包結果 是不是很神奇所有的新api都包裹在一個物件裡，沒有去汙染全域性變數。 soga，既然這麼神奇，為嘛不直接一步到位用這種方法呢？ 我們仔細一點看的話，發現下面的程式碼並沒有被轉化，這就是babel/plugin-transform-runtime的缺點了，它並沒有去轉義例項新API的方法，如果在程式碼裡使用到了新API的例項方法，這裡是會跪的。 還需要留意的一點，在package.json下@babel/plugin-transform-runtime是在devDependencies，@babel/runtime是在dependencies下(因為裡面都是轉化的API墊片) @babel/runtime內部集成了 core-js轉換一些內建類 (Promise, Symbols等等) 和靜態方法 (Array.from 等)。絕大部分轉換是這裡做的。自動引入regenerator作為 core-js 的拾遺補漏，主要是 generator/yield 和 async/await 兩組的支援。當代碼中有使用 generators/async 時自動引入。最後大殺器，無敵巨坑：corejs3 我們應該經常在其他文件和使用說明中看到 runtime 不支援例項方法，確實在之前的使用中，無論是 Babel 7.0.0 ~ 7.4.0 抑或 Babel < 7.0.0, 對此都無能為力。只能透過配置 corejs （可選 false | 2）來決定是否使用 babel/runtime-corejs 替代core-js 抑或 polyfill （可選 true | false）來決定是否全域性引入新的內建函式。重點： 真正的改變出現在 Babel 7.4.0 之後，你可以選擇引入 @babel/runtime-corejs3，設定 corejs: 3 來幫助您實現對例項方法的支援。 如果在Babel 7.4之後的版本，更改配置corejs : 3 在看轉化結果 它連例項API都轉了，（早幹嘛去了，前端ER真的學不動了！！！！ 最後附上Webpack版本Babel配置