用掘金刊登雖然分流了但是主要是！現在分享的曝光率實在太低了！！所以…………↑支援的請點下原博收藏下關注下以及我的微博。
咦，這篇文章標題為什麼反了？
實際上這是個人走過的心路歷程，最初看到 eggjs 的時候，我就覺得 Egg 很明顯不符合我的審美——我選擇 koa 的理由就是小巧精緻，all in middleware. 而 eggjs 不是畫蛇添足嗎？
這次新專案用到了公司自改版 egg，不過其實也就是 egg 多封裝了幾個 service。
——一開始我是拒絕的。
egg 與 koa
egg 底層用了 koa，從開發體驗上來說，有種求同存異的感覺，因為 koa 是自己一個個包找來的，所以我彷彿從 0 開始知道了為什麼世界這麼轉，而封裝好的世界就沒有這種快感，同時，它擴充套件了一些概念：service / model / middleware / controller 都會進行自動註冊，在 koa 的世界裡，你可能需要自己寫一段程式碼來實現自動註冊。
此外，在 koa 的基礎上，它免於了一些選擇困難症，也就是說，只要開啟它的外掛，你就遵守 egg 的規定就可以了。
當然，這種時候也帶來了另一種糾結，這類企業開發的框架規定了一種開發的標準語法和規範，你沒法按照自己喜歡的方式來，只能遵守它的規定，沒有 koa 那種愛怎麼寫怎麼寫的自由感——不過從另一個角度來看，可能是為了長期維護的可行性做出的犧牲。
配置
和我們平時用的配置庫差不多，都是根據 env 區分檔名，值得一提的是，單元測試時，環境變數為變更為 unittest，所以可以定製測試環境時的配置。如果沒有找到的配置會降級到 config.default.js 中取尋找。
測試
如果我這篇文章只是簡單的把官方文件壓縮壓縮再灌輸給大家，大家肯定也讀的不(hen)開心。主要想說的還是 egg 給我們在測試環節帶來的便利。
測試時往往我會思考以下問題：測些什麼，mock 些什麼，選擇啥庫，這三個問題往往會阻礙我行進的步伐，尤其是 mock 步驟太多的時候——SSO 要不要 mock，某些服務要不要 mock。呼叫了其他外部服務要不要 mock。這樣一來一去可能就更不想測試了。
在 egg 中封裝好的 Service 或者是 context 的屬性是可以直接 mock 配置的，使得整個過程非常的流暢，流暢的另一個原因當然是不用想如同「今天吃什麼」一樣的問題——「今天挑什麼庫用」。
文件
剩下的就是 koa 和 egg 的文件了，koa 概念很少，基本是用到什麼查什麼就行了，而 egg 相比之下引入的新概念和內建的 API 就比較多了，按照我們的尿性，字太長不看，很有可能會錯過什麼，這裡已經把某些我曾經錯過的部分抽出來介紹了（逃）。
在 egg API 文件的閱讀時，請記住，如果寫著 the same as 或者 alias，請到指定位置檢視介面資訊；點選原始碼也可能有意外之喜。
總之
如果你期待被規範，egg 還是一個值得選擇的框架，於此同時，也可以定製自己的 egg 版本，封裝一些常用 Service 給自己用，不過另一方面，由於封裝的太齊全，我也遇到了：egg 是照著這個來的 -> 點選進入這個東西的文件 -> 這一部分請看這個文件 -> 又進入了另一個文件的深層窘境，這種深化帶來的問題是，出了 Bug，如果定位到不是你——接下來甩鍋給誰好呢？
總的來說，雖然有些蛋疼，還不算太慘不忍睹，某些場景下還是比較棒的。