用过 Flask 做 Web 开发的同学应该不会不记得 App Context 和 Request Context 这两个名字——这两个 Context 算是 Flask 中比较特色的设计。[1]

从一个 Flask App 读入配置并启动开始，就进入了 App Context，在其中我们可以访问配置文件、打开资源文件、通过路由规则反向构造 URL。[2] 当一个请求进入开始被处理时，就进入了 Request Context，在其中我们可以访问请求携带的信息，比如 HTTP Method、表单域等。[3]

所以，这两个 Context 也成了 Flask 框架复杂度比较集中的地方，对此有评价认为 Flask 的这种设计比 Django、Tornado ...

这个标题有点不太准确，其实应该说：慎用异步 WSGI Server 运行基于 Werkzeug 的应用。或者更宽泛一点——慎用异步 WSGI Server 运行使用 Thread Local 的应用。 Flask 是基于 Werkzeug 的故也在此列。貌似使用 Werkzeug 作为底层 WSGI 库的框架还有国内 limodou 老师的 Uliweb 。而其他使用 Thread Local 的 WSGI Application 不计其数，Bottle、web.py 都在此列。但我没有测试过其他的，仅仅掉下过 Flask 的坑。

用过 Bottle [0] 的同学应该不会忘记它的流式响应 [1] ——在视图函数中使用 yield 关键字，让调用结果成为一个迭代器，那么 HTTP 客户端将会得到这个迭代器每次迭代的结果一部分，迭代器产生多少客户端收到多少，就像流一样。用这种方法在产生一些大的响应对象时（比如大文件下载），能有效地节约服务器内存。

运行以下代码并在浏览器访问 http://localhost:5000/stream

Python 多到数不过来的 Web 框架已经成为了一大风景，而且不同于 PHP Frameworks 集体山寨 Rails 的风格，几乎每个 Python 框架都有自己的特色。我接触过的有 web.py、Django、Bottle、Flask ，其中属 Flask 最为我喜欢。有时候框架会被称为“轮子”，但是可以确定的一点是这四个框架一定不是轮子，我最喜欢的 Flask 有许多非常方便的特性，当然也有我想吐槽的不爽点。于是写一篇博客把吐槽记录下来。