Flask是一个优秀的Web框架，很多人说它好，但是95%的人其实是在人云亦云，不去读它的源码、不了解作者其他项目、不深入使用很难真的理解它的好。我试着介绍下它备受好评的一些原因： 

1. 文档和snippets。文档算是非常好了，基本上你应该知道的都用比较通俗易懂的方式传达给你了，还会告诉你应该怎么设计。但是其实我还想说的是 http://flask.pocoo.org/snippets/，对于文档不满足的其实作者和一些深度用户都已经给了方案，比如会话（session），有专门的分类http://flask.pocoo.org/snippets/category/sessions/，想了解怎么个Redis集成，直接看http://flask.pocoo.org/snippets/75/就好了。

2. 设计哲学。Flask和Django甚至在这点上是完全相反的，Flask只愿意提供最小的核心，给你足够的自由，你可以去试试提交PR想加入一些依赖或者对一些你工作中需要的，但是有点小众的功能有多难，很难说服Flask团队的人支持你。但是Flask提供了非常好的扩展系统，哪怕你是一个新手，也能在文档的提示下编写一个可用的扩展。第三方扩展生态环境非常繁盛，但是质量也是参差不齐，考验你的眼力。我觉得大家喜欢Flask的原因之一就是这种设计哲学和Python工程师的气质是有重合的。

3. 装饰器表示路由。第一次看官方的例子，我都目瞪口呆了。原来装饰器可以这样用，逼格比其他的Web框架在我心中高了一点点。

4. Flask的依赖Werkzeug是一个WSGI工具集，Twisted开源的klein也使用了它。它有什么好呢？其中包含了实现非常好的LocalProxy、cached_property、import_string、find_modules、TypeConversionDict等。LocalProxy这种本地代理的思想，给开发者提供了非常大的空间；除了上面提到的还有多种数据结构，可以看werkzeug下的datastructures.py文件，现在我们在不同的项目都会依赖Werkzeug（Web框架并不是Flask），有时候竟然就是为了用cached_property等实现...；那import_string+find_modules能干什么呢？ 可以看 「 Flask最佳实践 」，里面有对重构大型项目下多个蓝图（blueprint）的应用。

5. 蓝图（Blueprint）实现了应用的模块化，使用蓝图让应用层次清晰，开发者可以更容易的开发和维护项目。蓝图通常作用于相同的URL前缀，比如/user/:id、/user/profile这样的地址，都以/user开头，那么就可以放在一个模块中。使用register_blueprint注册模块，如果想去掉模块只需要去掉对应的这个注册语句即可，多方便。 

6. 上下文（Context）。先看一个示例：

仔细想一下，这里先引用了flask.request，但是直到用户访问/people/的时候才通过request.args.get('name')获得请求的参数值。试想，引用的时候还没有发生这个请求，那么请求上下文是怎么获得的呢？

flask.request就是一个获取名为_request_ctx_stack的栈顶对象的LocalProxy实例：

上述逻辑能正常使用，是因为其流程是这样的：

• 用户访问产生请求。

• 在发生请求的过程中向_request_ctx_stack推入这个请求上下文的对象，它会变成栈顶。request就会成为这个请求上下文，也就包含了这次请求相关的信息和数据。

• 在视图函数中使用request就可以使用request.args.get('name')了。

设想不使用LocalStack和LocalProxy的话，要想让视图函数访问到请求对象只能将其作为参数，一步步传入视图函数中。这样做的缺点是会让每个视图函数都增加一个request参数，而Flask巧妙地使用上下文把某些对象变为全局可访问（实际上是特定环境的局部对象的代理），每个线程看到的上下文对象却是不同的，这样就巧妙地解决了这个问题。