如题，公司选型中有多少选择egg.js的？（个人项目除外）。
个人感觉，egg的插件还不是特别完善，看到egg issue问题中好多人提的问题，作者都想大家去PR，这出发点是好的，但是在公司中，遇到问题就需要自己去PR的话，很花时间啊。如果是个人项目还是可以贡献代码的，因为时间允许。如何做出选择，我的备选方案是koa2和egg。我更倾向于koa2。
遇到问题就需要自己去PR的话
- 如果你用的 Koa 中间件，遇到问题后，你会自己去 PR 解决么？还是等就好了?
- 所有的 Koa 中间件，大部分都可以直接用在 egg 中。
- 如果 Koa 没有的中间件，你自己要不要写？（同理，egg 也需要你 PR 或者写）
egg 和 koa 不冲突，egg 只是在 koa 的基础上，做了一次规范约束，以及对应的一些封装而已。 egg 完全可以非常低成本的使用 koa 社区的所有东西。
如果你自己用 koa，也一样需要去做这样的一些封装，或者是用其他人的封装。（那为何不选择 egg 呢？ 至少目前看来 egg 的封装还是比较适中的，扩展性也不错，并且有大规模的线上验证）
我觉得egg已经做得很完善了，有时候开发者的思维跟使用者不一样，不是每个使用者都用到你这样的功能，所以开发者也没必要去开发和完善，过度设计不是一件好事 自豪地采用 CNodeJS ionic
有三种角色：框架开发者，插件开发者，应用开发者。
- 框架开发者，需要做的是 egg 的微内核，社区建设和技术支撑。（目前 egg 的微内核其实已经很文档了）
- 插件开发者，作为社区的一份子，来贡献一些特定领域的插件
- 作为一个开发者，如果某个领域，我自己用的不多的话，那需求不是很强烈的情况下，肯定没办法去跟进这块的研发，毕竟都没怎么用，如何保证给出的是最佳实践，如何保证跟进活跃度。
- 就好像 react / koa 这些社区的很多优秀插件，都不一定是官方出的。
- 作为一个开发者，更关注如何快速的完成需求，不像上面 2 个则还需要关注如何才是最佳实践，还需要考虑多个边缘情况的 edge case。
我们是同时有这三个角色的，但之间的界限是分得很清的。 egg 你可以看成是一个社区项目，只是刚好目前社区里面最活跃的这批人，他们的雇主是阿里，而且他们的业务中也大量用到 egg 而已。 前两者都是社区的一份子，而不是为第三者去做免费外包，有需求就必须马上跟进，靠人不如靠己。
但是在公司中，遇到问题就需要自己去PR的话，很花时间啊。
@MedusaLeee 我个人的看法是，
- 做业务的同时，也要注意提升自己的技术，从来不能等别人授人予鱼，而是要自己渔。
- 我们自己也是有自己的业务压力的，你可以关注下 egg 的 issue 和 PR，很多讨论和 commit 时间，都是在个人时间的。
- 参与社区和提交 PR 是最快的个人成长方式，你可以通过这个过程，了解到如何编写有质量的代码，如何异步协作。
- 选择 koa 自己封装和造轮子的时间，以及后面维护的付出，对比它带来的收益，其实是不正比的，我们应该把时间花在更有价值的事上。
egg 的定位是怎么样的，它做什么，不做什么，为什么我们推荐大家基于 egg 去定制自己的框架，有兴趣可以看下我这篇 Slide： 「Egg & Node.js 从小工坊走向企业级开发」 https://github.com/atian25/blog/issues/20
没有批评的意思，只是从这里看出楼主应该koa用的也不好。。 参考其他egg插件比如egg-jwt之类的，看他们是怎么在原有插件上封装的，然后自己封装，用不了多长时间吧。。。
@rwing 关键是，搞出来的东西，是只能用在自己项目的，后来接手的人：
- 遇到问题在网上更找不到解决方案。
- 文档往往也不会太全，就跟 egg 当初的 TBD
- 一些隐患问题不一定会发现。
如果公司项目是由你亲手来搭建，那么我觉得用原生的koa2来搭建，这很能磨炼自己（个人对generator的写法有点反感），而且自己也能完全掌控项目情况。如果是别人来搭建那就选egg好了，有文档，大家都能看懂，不会出现意见不合的情况
@hpgt 其实早在 Egg 1.0 版本的时候，就完全可以用 async function 来写了，底层早就兼容好了。只要你的 Node 版本支持就 ok 了。
从 Koa 重新搭建，我觉得真心没必要，就像我们之前用 Express 时也没想过要从 Connect 开始搭建？ 适当分层，把时间花在更美好的事上，才是有价值的。
@atian25 最近已经把egg的文档看了一遍，也准备用在自己的项目中， 不过我现在有个问题想请教一下，比如：我使用了egg-mongoose， 这个时候mongoose这个库发布了新版本对一些bug做了修复， egg-mongoose怎么更新到最新的mongoose版本呢
@liuxuech 我们的依赖都是通过 ^ 引入的，所以你只需要简单的重新安装下依赖，就能引入子依赖的更新了，无需上层类库跟随发版本。
当然，前提条件是千万不要锁版本。
统一回复下，感谢大家批评与建议。首先我用node时间也不短了，有三年了。这次选型除了题目中提出背景，还有个其他背景的，那就是团队中前端出身和应届生比较多，用egg的话可能把他们当机器更好，会仿照着写就行。但是我最反对的就是把员工当成机器，公司是为了赚钱，但是科技公司除了钱，技术积累和技术氛围很重要。我们老总也是个技术人。最后我们选择koa，原因是我们会在这次开发中把koa的一些知识都普及给员工，知道一个技术的发展史还是很重要的。毕竟koa相对底层，没有koa基础直接撸egg，也不好理解。我们公司是这样安排时间的，一天8小时，6-7小时开发，1-2小时代码review。新员工的成长比较看中。另外，我们提起了一个内部egg联系项目，当大家不忙的时候，用来练手的项目，egg微信评价系统。因为选型也是需要大家发表意见的，不是一个人说了算的，公开透明。再次感谢大家，我会继续努力。
来自酷炫的 CNodeMD
还有个其他背景的，那就是团队中前端出身和应届生比较多，用egg的话可能把他们当机器更好，会仿照着写就行。
我们很多团队中的成员，也都是应届生。
用 egg 不等于把他们当机器，他们还是需要去了解底层的内容的，需要去写插件的。 如这篇 结合源码解密 egg 运行原理 就是一个应届生写的。
egg 只是用来规范化他们的代码风格和质量，达到千人一面，这对新人来说，是好事：
- 一张白纸的时候，先要告诉他们，怎么样是我们团队推荐的，怎么能写出质量好的代码。
- 能使他们很快能熟悉旧的代码，接手并开发出像老人一样质量的代码。帮助他们提升开发效率。
- 这样他们才有时间和精力，抓住某一个点，逐个去深入，而不是把时间花在建立秩序上，这点对大公司小公司都很重要。
还是上面那张图：
@lluxuech https://eggjs.org/zh-cn/core/security.html#match-和-ignore
config.security = {
csrf: {
// 判断是否需要 ignore 的方法，请求上下文 context 作为第一个参数
ignore: ctx => isInnerIp(ctx.ip),
},
}
@atian25 ^_^，是的，文档上没有看到可以直接取消csrf的，让后那个判断方法，先直接让他返回true了。多谢回复~ let isInnerIp = function (ip) { console.log(‘您的ip地址’ + ip) return true; }
@atian25 例如关闭 xframe 防范： exports.security = { xframe: { enable: false, }, }; 所以xframe换成csrf
@atian25 在选型讨论的时候，个人非常推荐egg，既然都要做的事，并且别人已经做的非常成熟的事，干嘛不用别人的而去自己撸一遍。唯一的担忧是，ali的kpi产物大多有头没尾，离开了核心开发者后期基本就死，希望egg能一直发展下去
@erdun 我只回复一个点：如果不用 Egg，自行基于 express 或 Koa，你们是不是肯定也会在上面做一层封装，那问题来了：
- 你们团队有自信并且有足够的时间去踩坑，并且封装的比 Egg 好么？
- 你们团队负责封装这个框架的同学，有自信自己不会离职，而且即使离职后，也会一直继续维护这个框架么？
- 你们有自信维护好这个 Koa 之上的框架，却没有自信可以维护好基于 Egg 之上的框架么？
