### 导航 - [索引](# "总目录") - [下一页](# "API") | - [上一页](# "CGI") | - [Flask 0.10.1 文档](#) » # 聚沙成塔 这里是增长你的代码库或是扩大应用规模的一些选择。 ### 阅读源码 Flask 的创建一定程度上是为了展示如何在现有的常用工具 Werkzeug（WSGI）和 Jinja（模板）之上构建你自己的框架，并且当它开发出来之后，它对广大受众很有用。当你增长你的代码库时，不要仅仅使用 Flask——去理解它。阅读源码。Flask 的代码是为了阅读而写；它是发布的文档，所以你可以使用它的内部 API。Flask 坚持为上游库里的 API 写文档，并且为内部工具写文档，这样你们可以找到你的项目需要的钩子注册点。 ### 钩子，继承 [*API*](#) 文档里面全都是可用的覆盖、钩子注册点和 [*信号*](#) 。你可以提供诸如请求和响应对象的自定义类。深入你所用的 API，并且在Flask 中探寻框架外可用的定制。去寻找把你的项目重构为实用工具集合和Flask 扩展的方法，探索社区中的大量的 [扩展](http://flask.pocoo.org/extensions/) [http://flask.pocoo.org/extensions/] ，如果你没找到你需要的工具，就去寻找可以用于构建你自己扩展的[模式](http://docs.torriacg.org/docs/flask/patterns/) [http://docs.torriacg.org/docs/flask/patterns/]。 ### 继承 [Flask](# "flask.Flask") 类有许多为继承设计的方法。你可以继承[Flask](# "flask.Flask") 快速添加或自定义行为（见链接的方法文档），并且无论你在哪里实例化一个应用类都会使用那个子类。这与[*应用程序的工厂函数*](#) 工作良好。 ### 用中间件包装 [*应用调度*](#) 章节描述了如何应用中间件的细节。你可以引入 WSGI 中间件来包装你的 Flask 实例并在 Flask 应用和 HTTP 服务器之间的中间层引入修正和变更。Werkzeug包含了一些[中间件](http://werkzeug.pocoo.org/docs/middlewares/) [http://werkzeug.pocoo.org/docs/middlewares/] 。 ### 分支 如果上述选择都不奏效，分支(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 扩展开发者为更大型应用改进的最佳途径就是从用户那里获取反馈。 © 版权所有 2013, Armin Ronacher.