这里是增长你的代码库或是扩大应用规模的一些选择。
Flask 的创建一定程度上是为了展示如何在现有的常用工具 Werkzeug（WSGI） 和 Jinja（模板）之上构建你自己的框架，并且当它开发出来之后，它对广大 受众很有用。当你增长你的代码库时，不要仅仅使用 Flask——去理解它。阅读源码。 Flask 的代码是为了阅读而写；它是发布的文档，所以你可以使用它的内部 API。 Flask 坚持为上游库里的 API 写文档，并且为内部工具写文档，这样你们可以 找到你的项目需要的钩子注册点。
:ref:`api` 文档里面全都是可用的覆盖、钩子注册点和 :ref:`signals` 。 你可以提供诸如请求和响应对象的自定义类。深入你所用的 API，并且在 Flask 中探寻框架外可用的定制。去寻找把你的项目重构为实用工具集合和 Flask 扩展的方法，探索社区中的大量的 扩展 ， 如果你没找到你需要的工具，就去寻找可以用于构建你自己扩展的 模式。
:class:`~flask.Flask` 类有许多为继承设计的方法。你可以继承 :class:`~flask.Flask` 快速添加或自定义行为（见链接的方法文档），并且 无论你在哪里实例化一个应用类都会使用那个子类。这与 :ref:`app-factories` 工作良好。
:ref:`app-dispatch` 章节描述了如何应用中间件的细节。你可以引入 WSGI 中 间件来包装你的 Flask 实例并在 Flask 应用和 HTTP 服务器之间的中间层引入 修正和变更。Werkzeug包含了一些 中间件 。
如果上述选择都不奏效，分支(fork) Flask。Flask 的大部分代码都限定在 Werkzeug 和 Jinja2 中。这些库做了大部分工作。Flask 只作为胶水把它们粘合在一起。 对每个项目，都有一个底层框架带来阻碍的点（归咎于原始开发者的假设）。 这很正常，因为如果不是这样，框架本身会是一个非常复杂的系统，导致学习曲 线陡峭，给用户带来许多挫折。
不仅仅是对 Flask，许多人用打了补丁的或修改过的框架来弥补短处。这个思路 也体现在 Flask 的许可证上。如果你决定修改这个框架，你不需要回馈任何的修 改。
分支的消极面当然就是 Flask 扩展会更容易不可用，因为新的框架有一个不同 的导入名称。此外，集成上游的修改可能是一个复杂的过程，取决于修改的数目。 为此，分支应该作为最后手段。
对许多 web 应用，代码的复杂程度比起为预期的用户或数据条目而扩大规模就不 是问题了。 Flask 自己扩大规模的限制只在于你的应用代码、你想用的数据存储 和 Python 解释器以及你运行的 web 服务器。
良好的规模扩张意味着，如果你把服务器的数量加倍，你会得到大约两倍于原来的性能。 而糟糕的则意味着，当你添加了一台新的服务器，应用不会有任何性能提升或根本不 支持第二台服务器。
在 Flask 中关于应用的扩张只有一个制约因素，那就是上下文局部代理。它们依赖于在 Flask 中上下文是被定义为是线程、还是进程或 greenlet。如果你的服务器使用不是基于 线程或 greenlet 的并行计算， Flask 不再能支持这些全局代理。然而大多数 服务器使用线程、 greenlet 或独立进程来实现并发，而这些方法在底层的 Werkzeug 库中有着良好的支持。
Flask 开发者维护框架对大小代码库用户的可理解性，所以一旦你遇到了由 Flask 引起的麻烦，不要犹豫，用邮件列表或 IRC 频道联系开发者。 Flask 和 Flask 扩展开发者为更大型应用改进的最佳途径就是从用户那里获取反馈。