变得更专业

以下为扩充你的代码库或是扩大应用规模的一些选择。

阅读源代码

Flask 的创建一定程度上是为了展示如何在现有的常用工具 Werkzeug（WSGI） 和 Jinja（模板）之上构建你自己的框架，并且当它开发出来之后，它对广大 受众很有用。 当你增长你的代码库时，不要仅仅使用 Flask——去理解它。 阅读源码。 Flask 的代码是为了阅读而写；它是发布的文档，所以你可以使用它的内部 API。 Flask 坚持为上游库里的 API 写文档，并且为内部工具写文档，这样你们可以 找到你的项目需要的钩子注册点。

钩。扩展。

API 文档里面全都是可用的覆盖、钩子注册点和 信号 。 你可以提供诸如请求和响应对象的自定义类。 深入你所用的 API，并且在 Flask 中探寻框架外可用的定制。 寻找可以将项目重构为实用程序和Flask扩展集合的方法。探索社群中的许多扩展，如果您找不到所需的工具，请寻找模式来构建自己的扩展。

子类

Flask 类有许多为继承设计的方法。 你可以继承 Flask 快速添加或自定义行为（见链接的方法文档），并且 无论你在哪里实例化一个应用类都会使用那个子类。 这与 应用程序的工厂函数 工作良好。 有关示例，请参见Subclassing Flask。

使用中间件封装

应用调度 章节描述了如何应用中间件的细节。 你可以引入 WSGI 中 间件来包装你的 Flask 实例并在 Flask 应用和 HTTP 服务器之间的中间层引入 修正和变更。 Werkzeug包括多个中间件。

Fork

如果上述选择都不奏效，分支(fork) Flask。 Flask 的大部分代码都限定在 Werkzeug 和 Jinja2 中。 这些库做了大部分工作。 Flask 只作为胶水把它们粘合在一起。 对每个项目，都有一个底层框架带来阻碍的点（归咎于原始开发者的假设）。 这很正常，因为如果不是这样，框架本身会是一个非常复杂的系统，导致学习曲 线陡峭，给用户带来许多挫折。

这不是Flask独有的。许多人使用补丁和修改版本的框架来克服缺点。 这个思路 也体现在 Flask 的许可证上。 如果你决定修改这个框架，你不需要回馈任何的修 改。

分支的消极面当然就是 Flask 扩展会更容易不可用，因为新的框架有一个不同 的导入名称。 此外，集成上游的修改可能是一个复杂的过程，取决于修改的数目。 为此，分支应该作为最后手段。

缩放像一个pro。

对许多 web 应用，代码的复杂程度比起为预期的用户或数据条目而扩大规模就不 是问题了。 Flask 自己扩大规模的限制只在于你的应用代码、你想用的数据存储 和 Python 解释器以及你运行的 web 服务器。

良好的规模扩张意味着，如果你把服务器的数量加倍，你会得到大约两倍于原来的性能。 而糟糕的则意味着，当你添加了一台新的服务器，应用不会有任何性能提升或根本不 支持第二台服务器。

在 Flask 中关于应用的扩张只有一个制约因素，那就是上下文局部代理。 它们依赖于在 Flask 中上下文是被定义为是线程、还是进程或 greenlet。 如果你的服务器使用不是基于 线程或 greenlet 的并行计算， Flask 不再能支持这些全局代理。 然而大多数 服务器使用线程、 greenlet 或独立进程来实现并发，而这些方法在底层的 Werkzeug 库中有着良好的支持。

参与社群讨论

Flask开发人员使用大小代码库的用户可以访问该框架。 Flask 开发者维护框架对大小代码库用户的可理解性，所以一旦你遇到了由 Flask 引起的麻烦，不要犹豫，用邮件列表或 IRC 频道联系开发者。 Flask 和 Flask 扩展开发者为更大型应用改进的最佳途径就是从用户那里获取反馈。