以下是一些建議，當你的代碼庫日益壯大或者應用需要規(guī)劃時可以參考。

閱讀源代碼

Werkzeug （ WSGI ）和 Jinja （模板）是兩個被廣泛使用的工具，而 Flask 起源就是 用于展示如何基于這兩個工具創(chuàng)建你自己的框架。隨著不斷地開發(fā)， Flask 被越來越多 的人認可了。當你的代碼庫日益壯大時，不應當僅僅是使用 Flask ，而更應當理解它。 閱讀 Flask 的源代碼吧。 Flask 的源代碼閱讀方便，文檔公開，有利于你直接使用內(nèi)部的 API 。 Flask 堅持把上游庫的 API 文檔化，并文檔化自己內(nèi)部的工具，方便按你的 需要找到掛接點。

掛接，擴展

API 文檔隨處可見可用重載、掛接點和信號 。你可以定制類似請求或響應對象的自定義類。請深入研究你所使用的 API ，并在 Flask 發(fā)行版中有哪些可以立即使用的可定制部分。請研究你的哪些項目可以重構(gòu)為工具集或 Flask 擴展。你可以在 社區(qū)中發(fā)現(xiàn)很多 擴展 。如果找不到滿意的， 那就寫一個你自己的吧。

繼承

Flask 類有許多方法專門為繼承而設計。你可通過繼承 Flask （參見鏈接的方法文檔）快速的添加或者定制行為，并把子類 實例化為一個應用類。這種方法同樣適用于應用工廠 。

用中間件包裝

應用調(diào)度 一文中詳細闡述了如何使用中間件。你可以引入中間件來包裝你的 Flask 實例，在你的應用和 HTTP 服務器之間的層有所作為。 Werkzeug 包含許多中間件 。

派生

如果以下建議都沒有用，那么直接派生 Flask 吧。 Flask 的主要代碼都在 Werkzeug 和 Jinja2 這兩個庫內(nèi)。這兩個庫起了主要作用。 Flask 只是把它們粘合在一起而已。對于一個項目來講，底層框架的切入點很重要。因為如果不重視這一點，那么框架會變得非常 復雜，勢必帶來陡峭的學習曲線，從而嚇退用戶。

Flask 并不推崇唯一版本。許多人為了避免缺陷，都使用打過補丁或修改過的版本。這個理念在 Flask 的許可中也有所體現(xiàn)：你不必返回你對框架所做的修改。

分支的缺點是大多數(shù)擴展都會失效，因為新的框架會使用不同的導入名稱。更進一步： 整合上游的變動將會變得十分復雜，上游變動越多，則整合越復雜。因此，創(chuàng)建分支一般是不得不為之的最后一招。

專家級的伸縮性

對于大多數(shù)網(wǎng)絡應用來說，最復雜的莫過于對于用戶量和數(shù)據(jù)量提供良好的伸縮性。 Flask 本身具有良好的伸縮性，其伸縮性受限于你的應用代碼、所使用的數(shù)據(jù)儲存方式、 Python 實現(xiàn)和應用所運行的服務器。

如果服務器數(shù)量增加一倍，你的應用性能就增加一倍，那么就代表伸縮性好。如果伸縮性 不好，那么即使增加服務器的數(shù)量，也不會得到更好的性能。伸縮性更差的甚至不支持增加第二臺服務器。

Flask 中唯一影響伸縮性的因素是環(huán)境本地代理。Flask 中的環(huán)境本地代理可以被定義為線程、進程或 greenlet 。如果你的服務器不支持這些，那么 Flask 就不能支持全局代理。 但是，當今主流的服務器都支持線程、進程或 greenlet ，以提高并發(fā)性。 Flask 的基礎 庫 Werkzeug 對于線程、進程或 greenlet 都能夠提供良好的支持。

與社區(qū)溝通

不管你的代碼庫是否強大， Flask 開發(fā)者總是保持框架的可操作性。如果發(fā)現(xiàn) Flask 有 什么問題，請立即通過郵件列表或 IRC 與社區(qū)進行溝通。對于 Flask 及其擴展的開發(fā)都 來說，提升其在大型應用中的功能的最佳途徑是傾聽用戶的心聲。

? Copyright 2013, Armin Ronacher. Created using Sphinx.