大型应用¶

Werkzeug （ WSGI ）和 Jinja （模板）是两个被广泛使用的工具，而 Flask 起源就是用于展示如何基于这两个工具创建你自己的框架。随着不断地开发， Flask 被越来越多的人认可了。当你的代码库日益壮大时，不应当仅仅是使用 Flask ，而更应当理解它。所以，请阅读 Flask 的源代码吧。 Flask 的源代码阅读方便，文档公开，有利于你直接使用内部的 API 。 Flask 坚持把上游库的 API 文档化，并文档化自己内部的工具，因此通过阅读源代码，可以为你的项目找到更好的切入点。

挂接，扩展¶

文档随处可见可用重载、挂接点和 信号 。你可以定制类似请求或响应对象的自定义类。请深入研究你所使用的 API ，并在 Flask 发行版中有哪些可以立即使用的可定制部分。请研究你的哪些项目可以重构为工具集或 Flask扩展。你可以在社区中发现很多 。如果找不到满意的，那就写一个你自己的吧。

类有许多方法专门为继承而设计。你可通过继承 （参见链接的方法文档）快速的添加或者定制行为，并把子类实例化为一个应用类。这种方法同样适用于 应用工厂 。示例参见 。

用中间件包装¶

如果以下建议都没有用，那么直接派生 Flask 吧。 Flask 的主要代码都在Werkzeug 和 Jinja2 这两个库内。这两个库起了主要作用。 Flask 只是把它们粘合在一起而已。对于一个项目来讲，底层框架的切入点很重要。因为如果不重视这一点，那么框架会变得非常复杂，势必带来陡峭的学习曲线，从而吓退用户。

Flask 并不推崇唯一版本。许多人为了避免缺陷，都使用打过补丁或修改过的版本。这个理念在 Flask 的许可中也有所体现：你不必返回你对框架所做的修改。

分支的缺点是大多数扩展都会失效，因为新的框架会使用不同的导入名称。更进一步：整合上游的变动将会变得十分复杂，上游变动越多，则整合越复杂。因此，创建分支一般是不得不为之的最后一招。

专家级的伸缩性¶

如果服务器数量增加一倍，你的应用性能就增加一倍，那么就代表伸缩性好。如果伸缩性不好，那么即使增加服务器的数量，也不会得到更好的性能。伸缩性更差的甚至不支持增加第二台服务器。

Flask 中唯一影响伸缩性的因素是环境本地代理。Flask 中的环境本地代理可以被定义为线程、进程或 greenlet 。如果你的服务器不支持这些，那么 Flask 就不能支持全局代理。但是，当今主流的服务器都支持线程、进程或 greenlet ，以提高并发性。 Flask 的基础库 Werkzeug 对于线程、进程或 greenlet 都能够提供良好的支持。

不管你的代码库是否强大， Flask 开发者总是保持框架的可操作性。如果发现Flask 有什么问题，请立即通过邮件列表或 IRC 与社区进行沟通。对于 Flask 及其扩展的开发都来说，提升其在大型应用中的功能的最佳途径是倾听用户的心声。