原文：codesky.me/archives/eg…
用掘金刊登虽然分流了但是主要是！现在分享的曝光率实在太低了！！所以…………↑支持的请点下原博收藏下关注下以及我的微博。
咦，这篇文章标题为什么反了？
实际上这是个人走过的心路历程，最初看到 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，如果定位到不是你——接下来甩锅给谁好呢？
总的来说，虽然有些蛋疼，还不算太惨不忍睹，某些场景下还是比较棒的。
