大型应用

以下是一些建议，当你的代码库日益壮大或者应用需要规划时可以参考。

阅读源代码

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

挂接，扩展

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

继承

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

用中间件包装

应用调度 一文中详细阐述了如何使用中间件。你可以引入中间件来包装你的 Flask 实例，在你的应用和 HTTP 服务器之间的层有所作为。 Werkzeug 包含许多 中间件 。

派生

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

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

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

专家级的伸缩性

对于大多数网络应用来说，最复杂的莫过于对于用户量和数据量提供良好的伸缩性。 Flask 本身具有良好的伸缩性，其伸缩性受限于你的应用代码、所使用的数据储存方式、 Python 实现和应用所运行的服务器。

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

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

与社区沟通

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