### 導航 - [索引](# "總目錄") - [下一頁](# "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.