大型应用

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

挂接，扩展

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

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

用中间件包装

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

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

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

专家级的伸缩性

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

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

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