2021-4-23 前端達(dá)人
最近幾年，如果你是一名前端開(kāi)發(fā)者，如果你沒(méi)有使用甚至聽(tīng)說(shuō)過(guò) babel，可能會(huì)被當(dāng)做穿越者吧？
說(shuō)到 babel，一連串名詞會(huì)蹦出來(lái)：
這些都是 babel 嗎？他們分別是做什么的？有區(qū)別嗎？
簡(jiǎn)單來(lái)說(shuō)把 JavaScript 中 es2015/2016/2017/2046 的新語(yǔ)法轉(zhuǎn)化為 es5，讓低端運(yùn)行環(huán)境(如瀏覽器和 node )能夠認(rèn)識(shí)并執(zhí)行。本文以 babel 6.x 為基準(zhǔn)進(jìn)行討論。最近 babel 出了 7.x，放在最后聊。
嚴(yán)格來(lái)說(shuō)，babel 也可以轉(zhuǎn)化為更低的規(guī)范。但以目前情況來(lái)說(shuō)，es5 規(guī)范已經(jīng)足以覆蓋絕大部分瀏覽器，因此常規(guī)來(lái)說(shuō)轉(zhuǎn)到 es5 是一個(gè)安全且流行的做法。
如果你對(duì) es5/es2015 等等也不了解的話，那你可能真的需要先補(bǔ)補(bǔ)課了。
總共存在三種方式：
其中后面兩種比較常見(jiàn)。第二種多見(jiàn)于 package.json 中的 scripts 段落中的某條命令；第三種就直接集成到構(gòu)建工具中。
這三種方式只有入口不同而已，調(diào)用的 babel 內(nèi)核，處理方式都是一樣的，所以我們先不糾結(jié)入口的問(wèn)題。
babel 總共分為三個(gè)階段：解析，轉(zhuǎn)換，生成。
babel 本身不具有任何轉(zhuǎn)化功能，它把轉(zhuǎn)化的功能都分解到一個(gè)個(gè) plugin 里面。因此當(dāng)我們不配置任何插件時(shí)，經(jīng)過(guò) babel 的代碼和輸入是相同的。
插件總共分為兩種：
舉個(gè)簡(jiǎn)單的例子，當(dāng)我們定義或者調(diào)用方法時(shí)，最后一個(gè)參數(shù)之后是不允許增加逗號(hào)的，如 callFoo(param1, param2,) 就是非法的。如果源碼是這種寫(xiě)法，經(jīng)過(guò) babel 之后就會(huì)提示語(yǔ)法錯(cuò)誤。
但最近的 JS 提案中已經(jīng)允許了這種新的寫(xiě)法(讓代碼 diff 更加清晰)。為了避免 babel 報(bào)錯(cuò)，就需要增加語(yǔ)法插件 babel-plugin-syntax-trailing-function-commas
比起語(yǔ)法插件，轉(zhuǎn)譯插件其實(shí)更好理解，比如箭頭函數(shù) (a) => a 就會(huì)轉(zhuǎn)化為 function (a) {return a}。完成這個(gè)工作的插件叫做 babel-plugin-transform-es2015-arrow-functions。
同一類語(yǔ)法可能同時(shí)存在語(yǔ)法插件版本和轉(zhuǎn)譯插件版本。如果我們使用了轉(zhuǎn)譯插件，就不用再使用語(yǔ)法插件了。
既然插件是 babel 的根本，那如何使用呢？總共分為 2 個(gè)步驟：
babel 里面，格式相同)
npm install babel-plugin-xxx 進(jìn)行安裝
具體書(shū)寫(xiě)格式就不詳述了。
比如 es2015 是一套規(guī)范，包含大概十幾二十個(gè)轉(zhuǎn)譯插件。如果每次要開(kāi)發(fā)者一個(gè)個(gè)添加并安裝，配置文件很長(zhǎng)不說(shuō)，npm install 的時(shí)間也會(huì)很長(zhǎng)，更不談我們可能還要同時(shí)使用其他規(guī)范呢。
為了解決這個(gè)問(wèn)題，babel 還提供了一組插件的集合。因?yàn)槌Ｓ?，所以不必重?fù)定義 & 安裝。(單點(diǎn)和套餐的差別，套餐省下了巨多的時(shí)間和配置的精力)
preset 分為以下幾種：
例如 syntax-dynamic-import 就是 stage-2 的內(nèi)容，transform-object-rest-spread 就是 stage-3 的內(nèi)容。
此外，低一級(jí)的 stage 會(huì)包含所有高級(jí) stage 的內(nèi)容，例如 stage-1 會(huì)包含 stage-2, stage-3 的所有內(nèi)容。
stage-4 在下一年更新會(huì)直接放到 env 中，所以沒(méi)有單獨(dú)的 stage-4 可供使用。
arrow-functions，es2017 包含 syntax-trailing-function-commas。但因?yàn)?env 的出現(xiàn)，使得 es2016 和 es2017 都已經(jīng)廢棄。所以我們經(jīng)?？梢钥吹?es2015 被單獨(dú)列出來(lái)，但極少看到其他兩個(gè)。很簡(jiǎn)單的幾條原則：
preset 的逆向順序主要是為了保證向后兼容，因?yàn)榇蠖鄶?shù)用戶的編寫(xiě)順序是 ['es2015', 'stage-0']。這樣必須先執(zhí)行 stage-0 才能確保 babel 不報(bào)錯(cuò)。因此我們編排 preset 的時(shí)候，也要注意順序，其實(shí)只要按照規(guī)范的時(shí)間順序列出即可。
簡(jiǎn)略情況下，插件和 preset 只要列出字符串格式的名字即可。但如果某個(gè) preset 或者插件需要一些配置項(xiàng)(或者說(shuō)參數(shù))，就需要把自己先變成數(shù)組。第一個(gè)元素依然是字符串，表示自己的名字；第二個(gè)元素是一個(gè)對(duì)象，即配置對(duì)象。
最需要配置的當(dāng)屬 env，如下：
"presets": [ // 帶了配置項(xiàng)，自己變成數(shù)組 [ // 第一個(gè)元素依然是名字 "env", // 第二個(gè)元素是對(duì)象，列出配置項(xiàng) { "module": false } ], // 不帶配置項(xiàng)，直接列出名字 "stage-2" ] 因?yàn)?env 最為常用也最重要，所以我們有必要重點(diǎn)關(guān)注。
env 的核心目的是通過(guò)配置得知目標(biāo)環(huán)境的特點(diǎn)，然后只做必要的轉(zhuǎn)換。例如目標(biāo)瀏覽器支持 es2015，那么 es2015 這個(gè) preset 其實(shí)是不需要的，于是代碼就可以小一點(diǎn)(一般轉(zhuǎn)化后的代碼總是更長(zhǎng))，構(gòu)建時(shí)間也可以縮短一些。
如果不寫(xiě)任何配置項(xiàng)，env 等價(jià)于 latest，也等價(jià)于 es2015 + es2016 + es2017 三個(gè)相加(不包含 stage-x 中的插件)。env 包含的插件列表維護(hù)在這里
下面列出幾種比較常用的配置方法：
{ "presets": [ ["env", { "targets": { "browsers": ["last 2 versions", "safari >= 7"] } }] ] }如上配置將考慮所有瀏覽器的最新2個(gè)版本(safari大于等于7.0的版本)的特性，將必要的代碼進(jìn)行轉(zhuǎn)換。而這些版本已有的功能就不進(jìn)行轉(zhuǎn)化了。這里的語(yǔ)法可以參考 browserslist
{ "presets": [ ["env", { "targets": { "node": "6.10" } }] ] }
如上配置將目標(biāo)設(shè)置為 nodejs，并且支持 6.10 及以上的版本。也可以使用 node: 'current' 來(lái)支持最新穩(wěn)定版本。例如箭頭函數(shù)在 nodejs 6 及以上將不被轉(zhuǎn)化，但如果是 nodejs 0.12 就會(huì)被轉(zhuǎn)化了。
另外一個(gè)有用的配置項(xiàng)是 modules。它的取值可以是 amd, umd, systemjs, commonjs 和 false。這可以讓 babel 以特定的模塊化格式來(lái)輸出代碼。如果選擇 false 就不進(jìn)行模塊化處理。
以上討論了 babel 的核心處理機(jī)制和配置方法等，不論任何入口調(diào)用 babel 都走這一套。但文章開(kāi)頭提的那一堆 babel-* 還是讓人一頭霧水。實(shí)際上這些 babel-* 大多是不同的入口(方式)來(lái)使用 babel，下面來(lái)簡(jiǎn)單介紹一下。
顧名思義，cli 就是命令行工具。安裝了 babel-cli 就能夠在命令行中使用 babel 命令來(lái)編譯文件。
在開(kāi)發(fā) npm package 時(shí)經(jīng)常會(huì)使用如下模式：
babel-cli 安裝為 devDependencies
scripts (比如 prepublish)，使用 babel 命令編譯文件
npm publish
這樣既可以使用較新規(guī)范的 JS 語(yǔ)法編寫(xiě)源碼，同時(shí)又能支持舊版環(huán)境。因?yàn)轫?xiàng)目可能不太大，用不到構(gòu)建工具 (webpack 或者 rollup)，于是在發(fā)布之前用 babel-cli 進(jìn)行處理。
babel-node 是 babel-cli 的一部分，它不需要單獨(dú)安裝。
它的作用是在 node 環(huán)境中，直接運(yùn)行 es2015 的代碼，而不需要額外進(jìn)行轉(zhuǎn)碼。例如我們有一個(gè) js 文件以 es2015 的語(yǔ)法進(jìn)行編寫(xiě)(如使用了箭頭函數(shù))。我們可以直接使用 babel-node es2015.js 進(jìn)行執(zhí)行，而不用再進(jìn)行轉(zhuǎn)碼了。
可以說(shuō)：babel-node = babel-polyfill + babel-register。那這兩位又是誰(shuí)呢？
babel-register 模塊改寫(xiě) require 命令，為它加上一個(gè)鉤子。此后，每當(dāng)使用 require 加載 .js、.jsx、.es 和 .es6 后綴名的文件，就會(huì)先用 babel 進(jìn)行轉(zhuǎn)碼。
使用時(shí)，必須首先加載 require('babel-register')。
需要注意的是，babel-register 只會(huì)對(duì) require 命令加載的文件轉(zhuǎn)碼，而 不會(huì)對(duì)當(dāng)前文件轉(zhuǎn)碼。
另外，由于它是實(shí)時(shí)轉(zhuǎn)碼，所以 只適合在開(kāi)發(fā)環(huán)境使用。
babel 默認(rèn)只轉(zhuǎn)換 js 語(yǔ)法，而不轉(zhuǎn)換新的 API，比如 Iterator、Generator、Set、Maps、Proxy、Reflect、Symbol、Promise 等全局對(duì)象，以及一些定義在全局對(duì)象上的方法(比如 Object.assign)都不會(huì)轉(zhuǎn)碼。
舉例來(lái)說(shuō)，es2015 在 Array 對(duì)象上新增了 Array.from 方法。babel 就不會(huì)轉(zhuǎn)碼這個(gè)方法。如果想讓這個(gè)方法運(yùn)行，必須使用 babel-polyfill。(內(nèi)部集成了 core-js 和 regenerator)
使用時(shí)，在所有代碼運(yùn)行之前增加 require('babel-polyfill')?；蛘吒Ｒ?guī)的操作是在 webpack.config.js 中將 babel-polyfill 作為第一個(gè) entry。因此必須把 babel-polyfill 作為 dependencies 而不是 devDependencies
babel-polyfill 主要有兩個(gè)缺點(diǎn)：
babel-polyfill 會(huì)導(dǎo)致打出來(lái)的包非常大，因?yàn)?nbsp;babel-polyfill 是一個(gè)整體，把所有方法都加到原型鏈上。比如我們只使用了 Array.from，但它把 Object.defineProperty 也給加上了，這就是一種浪費(fèi)了。這個(gè)問(wèn)題可以通過(guò)單獨(dú)使用 core-js 的某個(gè)類庫(kù)來(lái)解決，core-js 都是分開(kāi)的。babel-polyfill 會(huì)污染全局變量，給很多類的原型鏈上都作了修改，如果我們開(kāi)發(fā)的也是一個(gè)類庫(kù)供其他開(kāi)發(fā)者使用，這種情況就會(huì)變得非常不可控。
因此在實(shí)際使用中，如果我們無(wú)法忍受這兩個(gè)缺點(diǎn)(尤其是第二個(gè))，通常我們會(huì)傾向于使用 babel-plugin-transform-runtime。
但如果代碼中包含高版本 js 中類型的實(shí)例方法 (例如 [1,2,3].includes(1))，這還是要使用 polyfill。
我們時(shí)常在項(xiàng)目中看到 .babelrc 中使用 babel-plugin-transform-runtime，而 package.json 中的 dependencies (注意不是 devDependencies) 又包含了 babel-runtime，那這兩個(gè)是不是成套使用的呢？他們又起什么作用呢？
先說(shuō) babel-plugin-transform-runtime。
babel 會(huì)轉(zhuǎn)換 js 語(yǔ)法，之前已經(jīng)提過(guò)了。以 async/await 舉例，如果不使用這個(gè) plugin (即默認(rèn)情況)，轉(zhuǎn)換后的代碼大概是：
// babel 添加一個(gè)方法，把 async 轉(zhuǎn)化為 generator function _asyncToGenerator(fn) { return function () {....}} // 很長(zhǎng)很長(zhǎng)一段 // 具體使用處 var _ref = _asyncToGenerator(function* (arg1, arg2) { yield (0, something)(arg1, arg2); });
不用過(guò)于糾結(jié)具體的語(yǔ)法，只需看到，這個(gè) _asyncToGenerator 在當(dāng)前文件被定義，然后被使用了，以替換源代碼的 await。但每個(gè)被轉(zhuǎn)化的文件都會(huì)插入一段 _asyncToGenerator 這就導(dǎo)致重復(fù)和浪費(fèi)了。
在使用了 babel-plugin-transform-runtime 了之后，轉(zhuǎn)化后的代碼會(huì)變成
// 從直接定義改為引用，這樣就不會(huì)重復(fù)定義了。 var _asyncToGenerator2 = require('babel-runtime/helpers/asyncToGenerator'); var _asyncToGenerator3 = _interopRequireDefault(_asyncToGenerator2); // 具體使用處是一樣的 var _ref = _asyncToGenerator3(function* (arg1, arg2) { yield (0, something)(arg1, arg2); }); 從定義方法改成引用，那重復(fù)定義就變成了重復(fù)引用，就不存在代碼重復(fù)的問(wèn)題了。
但在這里，我們也發(fā)現(xiàn) babel-runtime 出場(chǎng)了，它就是這些方法的集合處，也因此，在使用 babel-plugin-transform-runtime 的時(shí)候必須把 babel-runtime 當(dāng)做依賴。
再說(shuō) babel-runtime，它內(nèi)部集成了
core-js: 轉(zhuǎn)換一些內(nèi)置類 (Promise, Symbols等等) 和靜態(tài)方法 (Array.from 等)。絕大部分轉(zhuǎn)換是這里做的。自動(dòng)引入。regenerator: 作為 core-js 的拾遺補(bǔ)漏，主要是 generator/yield 和 async/await 兩組的支持。當(dāng)代碼中有使用 generators/async 時(shí)自動(dòng)引入。asyncToGenerator 就是其中之一，其他還有如 jsx, classCallCheck 等等，可以查看 babel-helpers。在代碼中有內(nèi)置的 helpers 使用時(shí)(如上面的第一段代碼)移除定義，并插入引用(于是就變成了第二段代碼)。
babel-plugin-transform-runtime 不支持 實(shí)例方法 (例如 [1,2,3].includes(1))
此外補(bǔ)充一點(diǎn)，把 helpers 抽離并統(tǒng)一起來(lái)，避免重復(fù)代碼的工作還有一個(gè) plugin 也能做，叫做 babel-plugin-external-helpers。但因?yàn)槲覀兪褂玫?nbsp;transform-runtime 已經(jīng)包含了這個(gè)功能，因此不必重復(fù)使用。而且 babel 的作者們也已經(jīng)開(kāi)始討論這兩個(gè)插件過(guò)于類似，正在討論在 babel 7 中把 external-helpers 刪除，討論在 issue#5699 中。
前面提過(guò) babel 的三種使用方法，并且已經(jīng)介紹過(guò)了 babel-cli。但一些大型的項(xiàng)目都會(huì)有構(gòu)建工具 (如 webpack 或 rollup) 來(lái)進(jìn)行代碼構(gòu)建和壓縮 (uglify)。理論上來(lái)說(shuō)，我們也可以對(duì)壓縮后的代碼進(jìn)行 babel 處理，但那會(huì)非常慢。因此如果在 uglify 之前就加入 babel 處理，豈不完美？
所以就有了 babel 插入到構(gòu)建工具內(nèi)部這樣的需求。以(我還算熟悉的) webpack 為例，webpack 有 loader 的概念，因此就出現(xiàn)了 babel-loader。
和 babel-cli 一樣，babel-loader 也會(huì)讀取 .babelrc 或者 package.json 中的 babel 段作為自己的配置，之后的內(nèi)核處理也是相同。唯一比 babel-cli 復(fù)雜的是，它需要和 webpack 交互，因此需要在 webpack 這邊進(jìn)行配置。比較常見(jiàn)的如下：
module: { rules: [ { test: /\.js$/, exclude: /(node_modules|bower_components)/, loader: 'babel-loader' } ] } 如果想在這里傳入 babel 的配置項(xiàng)，也可以把改成：
// loader: 'babel-loader' 改成如下： use: { loader: 'babel-loader', options: { // 配置項(xiàng)在這里 } } 這里的配置項(xiàng)優(yōu)先級(jí)是最高的。但我認(rèn)為放到單獨(dú)的配置文件中更加清晰合理，可讀性強(qiáng)一些。
最近 babel 發(fā)布了 7.0。因?yàn)樯厦娌糠侄际轻槍?duì) 6.x 編寫(xiě)的，所以我們關(guān)注一下 7.0 帶來(lái)的變化(核心機(jī)制方面沒(méi)有變化，插件，preset，解析轉(zhuǎn)譯生成這些都沒(méi)有變化)
我只挑選一些和開(kāi)發(fā)者關(guān)系比較大的列在這里，省略的多數(shù)是針對(duì)某一個(gè) plugin 的改動(dòng)。完整的列表可以參考官網(wǎng)。
淘汰 es201x 的目的是把選擇環(huán)境的工作交給 env 自動(dòng)進(jìn)行，而不需要開(kāi)發(fā)者投入精力。凡是使用 es201x 的開(kāi)發(fā)者，都應(yīng)當(dāng)使用 env 進(jìn)行替換。但這里的淘汰 (原文 deprecated) 并不是刪除，只是不推薦使用了，不好說(shuō) babel 8 就真的刪了。
與之相比，stage-x 就沒(méi)那么好運(yùn)了，它們直接被刪了。這是因?yàn)?babel 團(tuán)隊(duì)認(rèn)為為這些 “不穩(wěn)定的草案” 花費(fèi)精力去更新 preset 相當(dāng)浪費(fèi)。stage-x 雖然刪除了，但它包含的插件并沒(méi)有刪除(只是被更名了，可以看下面一節(jié))，我們依然可以顯式地聲明這些插件來(lái)獲得等價(jià)的效果。完整列表
為了減少開(kāi)發(fā)者替換配置文件的機(jī)械工作，babel 開(kāi)發(fā)了一款 babel-upgrade 的工具，它會(huì)檢測(cè) babel 配置中的 stage-x 并且替換成對(duì)應(yīng)的 plugins。除此之外它還有其他功能，我們一會(huì)兒再詳細(xì)看。(總之目的就是讓你更加平滑地遷移到 babel 7)
這是 babel 7 的一個(gè)重大變化，把所有 babel-* 重命名為 @babel/*，例如：
babel-cli 變成了 @babel/cli。
babel-preset-env 變成了 @babel/preset-env。進(jìn)一步，還可以省略 preset 而簡(jiǎn)寫(xiě)為 @babel/env。
babel-plugin-transform-arrow-functions 變成了 @babel/plugin-transform-arrow-functions。和 preset 一樣，plugin 也可以省略，于是簡(jiǎn)寫(xiě)為 @babel/transform-arrow-functions。
這個(gè)變化不單單應(yīng)用于 package.json 的依賴中，包括 .babelrc 的配置 (plugins, presets) 也要這么寫(xiě)，為了保持一致。例如
{
"presets": [ - "env" + "@babel/preset-env" ]
}
順帶提一句，上面提過(guò)的 babel 解析語(yǔ)法的內(nèi)核 babylon 現(xiàn)在重命名為 @babel/parser，看起來(lái)是被收編了。
上文提過(guò)的 stage-x 被刪除了，它包含的插件雖然保留，但也被重命名了。babel 團(tuán)隊(duì)希望更明顯地區(qū)分已經(jīng)位于規(guī)范中的插件 (如 es2015 的 babel-plugin-transform-arrow-functions) 和僅僅位于草案中的插件 (如 stage-0 的 @babel/plugin-proposal-function-bind)。方式就是在名字中增加 proposal，所有包含在 stage-x 的轉(zhuǎn)譯插件都使用了這個(gè)前綴，語(yǔ)法插件不在其列。
最后，如果插件名稱中包含了規(guī)范名稱 (-es2015-, -es3- 之類的)，一律刪除。例如 babel-plugin-transform-es2015-classes 變成了 @babel/plugin-transform-classes。(這個(gè)插件我自己沒(méi)有單獨(dú)用過(guò)，慚愧)
babel 7.0 開(kāi)始不再支持 nodejs 0.10, 0.12, 4, 5 這四個(gè)版本，相當(dāng)于要求 nodejs >= 6 (當(dāng)前 nodejs LTS 是 8，要求也不算太過(guò)分吧)。
這里的不再支持，指的是在這些低版本 node 環(huán)境中不能使用 babel 轉(zhuǎn)譯代碼，但 babel 轉(zhuǎn)譯后的代碼依然能在這些環(huán)境上運(yùn)行，這點(diǎn)不要混淆。
在 babel 6 時(shí)，ignore 選項(xiàng)如果包含 *.foo.js，實(shí)際上的含義 (轉(zhuǎn)化為 glob) 是 ./**/*.foo.js，也就是當(dāng)前目錄 包括子目錄 的所有 foo.js 結(jié)尾的文件。這可能和開(kāi)發(fā)者常規(guī)的認(rèn)識(shí)有悖。
于是在 babel 7，相同的表達(dá)式 *.foo.js 只作用于當(dāng)前目錄，不作用于子目錄。如果依然想作用于子目錄的，就要按照 glob 的完整規(guī)范書(shū)寫(xiě)為 ./**/*.foo.js 才可以。only 也是相同。
這個(gè)規(guī)則變化只作用于通配符，不作用于路徑。所以 node_modules 依然包含所有它的子目錄，而不單單只有一層。(否則全世界開(kāi)發(fā)者都要爆炸)
和 babel 6 不同，如果要使用 @babel/node，就必須單獨(dú)安裝，并添加到依賴中。
在提到刪除 stage-x 時(shí)候提過(guò)這個(gè)工具，它的目的是幫助用戶自動(dòng)化地從 babel 6 升級(jí)到 7。
這款升級(jí)工具的功能包括：(這里并不列出完整列表，只列出比較重要和常用的內(nèi)容)
babel-* 替換為 @babel/*
@babel/* 依賴的版本更新為最新版 (例如 ^7.0.0)
scripts 中有使用 babel-node，自動(dòng)添加 @babel/node 為開(kāi)發(fā)依賴
babel 配置項(xiàng)，檢查其中的 plugins 和 presets，把短名 (env) 替換為完整的名字 (@babel/preset-env)plugins 和 presets，把短名 (env) 替換為完整的名字 (@babel/preset-env)
preset-stage-x，如有替換為對(duì)應(yīng)的插件并添加到 plugins
使用方式如下：
# 不安裝到本地而是直接運(yùn)行命令，npm 的新功能 npx babel-upgrade --write # 或者常規(guī)方式 npm i babel-upgrade -g
babel-upgrade --write
babel-upgrade 工具本身也還在開(kāi)發(fā)中，還列出了許多 TODO 沒(méi)有完成，因此之后的功能可能會(huì)更加豐富，例如上面提過(guò)的 ignore 的通配符轉(zhuǎn)化等等。
轉(zhuǎn)自：知乎。作者：前端解憂雜貨鋪
藍(lán)藍(lán)設(shè)計(jì)( sillybuy.com )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)
藍(lán)藍(lán)設(shè)計(jì)的小編 http://sillybuy.com