同意this的问题, 部分赞成重复造轮子(或者理解为不兼容express). 其他就不能同意了. 且不管async/await来了与否, express在promise上的支持度是硬伤. 如果能做到这样:

app.use(async (req, resp, next)=>{
	console.log('start')
	await next()
	console.log('end')
})

那才是最吼的

区分一下版本好吗？koa 1.x是this，但2.x是ctx，不在this，而且说了generator方式可能会在v3.x干掉

@kiliwak 这种写法koa一样支持，几十行代码就可以搞定，没啥劲，你发现集成已有express插件的时候就挂掉了。。。。

@i5ting 能举个栗子是哪个插件会挂掉吗? 我还没碰到过哪, 让我试试

@kiliwak await后面就2种情形，1）async函数 2）promise 3）co返回promise的generator，这个稍微牵强。可是你的中间件的next返回的是啥呢？想想

@i5ting hai! 咱俩说的前提都不一致. 我说的await next()是要改造express, 让next()也返回一个promise. 并不是现在的express里的next模式. 你可以看看这个use-server

express为什么到现在还不发5呢？都alpha好久了。。。。

我觉得koa真正的问题是中间件的轮子没有express丰富吧，koa 2.x更好的支持了async/await，next的语意比express中的要科学，要使用async/await或者promise的话建议koa 2.x，喜欢回调的话express好一点

来自酷炫的 CNodeMD

怎么还有人拿koa1.来说事

文章基本是在说“因为Koa不符合我的编程习惯和思想，所以这些地方都是Koa的坑，而且我自己粗心没处理好作用域链导致调错this的问题也都怪Koa用了this，顺便预言一下未来JS的趋势是按照Express特性来发展的”。 最近是Express党和Koa党准备开战了吗？好多帖子都在黑Koa，说Koa是不稳定的、缺乏支持的、实验性的玩具。黑人问号的我不禁开始怀疑我是如何用Koa1开发支撑百万用户的服务且稳定持续集成产品化一年多的？～难不成我的服务器找高僧开过光了？

那么，问题来了，PHP和Python究竟哪个才是世界上最好的语言呢？

说点理性的吧，每一个技术、库、框架都有自己的特性和思想的以及适用的场景的，软件工程上没有银弹。 用NoSQL存储关系模型会觉得NoSQL难用，用SQL存储文档模型同样会觉得SQL难用。

@libook 我想问一下，数据库是mongodb吗？ 我每次报错的时候数据已经写入数据库导致我每次都要删除数据库，有什么办法解决这个问题了？因为mongodb又不支持事务处理！

@598220654

我的建议是要明确一下问题的答案：

1. 首先是数据库选型，数据模型主要是关系还是非关系？按需选择数据库类型。
2. 是否依赖数据库的特性？比如是否大多重要业务都依赖数据库的事务机制？是的话尽可能选择具备事务机制的数据库，但有时候其他因素比是否具备事务机制更有决定性，这样的话也可以考虑是否使用程序的方式实现类事务机制。
3. 数据库的事务机制是否真的能完全满足需求？任何业务复杂到一定程度都会遇到一致性的问题，在集群化或微服务化之后甚至使用数据库的事务机制也无法满足需求，这时候可能就需要类似于“Compensating Transaction Pattern”的机制来对失败的操作进行回滚。

@libook 谢谢你回答！ 1.因为刚入门node,很多知识不会，而且很多书籍上都是mongodb来操作。 2.之前做了一个demo，关于计算金额的，中间可能有报错的，搞得之前数据已经插入又要在数据库查找数据删除，所以感觉很麻烦。

<a>来自vue-wenda</a>

mark<a>来自vue-wenda</a>

@598220654 推荐 mongodb 事务处理包mongo-tx

来自酷炫的 CNodeMD