### 導航 - [索引](# "總目錄") - [下一頁](# "信號") | - [上一頁](# "記錄應用錯誤") | - [Flask 0.10.1 文檔](#) ? # 配置處理 0.3 新版功能. 應用會需要某種配置。你可能會需要根據應用環境更改不同的設置，比如切換調試模式、設置密鑰、或是別的設定環境的東西。 Flask 被設計為需要配置來啟動應用。你可以在代碼中硬編碼配置，這對于小的應用并不壞，但是有更好的方法。 跟你如何載入配置無關，會有一個可用的配置對象保存著載入的配置值:[Flask](# "flask.Flask") 對象的 [config](# "flask.Flask.config") 屬性。這是 Flask自己放置特定配置值的地方，也是擴展可以存儲配置值的地方。但是，你也可以把自己的配置保存到這個對象里。 ### 配置基礎 [config](# "flask.Flask.config") 實際上繼承于字典，并且可以像修改字典一樣修改它: ~~~ app = Flask(__name__) app.config['DEBUG'] = True ~~~ 給定的配置值會被推送到 [Flask](# "flask.Flask") 對象中，所以你可以在那里讀寫它們: ~~~ app.debug = True ~~~ 你可以使用 [dict.update()](http://docs.python.org/dev/library/stdtypes.html#dict.update "(在 Python v3.5)") [http://docs.python.org/dev/library/stdtypes.html#dict.update] 方法來一次性更新多個鍵: ~~~ app.config.update( DEBUG=True, SECRET_KEY='...' ) ~~~ ### 內置的配置值 下列配置值是 Flask 內部使用的: | DEBUG | 啟用/禁用 調試模式 | |-----|-----| | TESTING | 啟用/禁用 測試模式 | | PROPAGATE_EXCEPTIONS | 顯式地允許或禁用異常的傳播。如果沒有設置或顯式地設置為 None ，當 TESTING 或DEBUG 為真時，這個值隱式地為 true. | | PRESERVE_CONTEXT_ON_EXCEPTION | 默認情況下，如果應用工作在調試模式，請求上下文不會在異常時出棧來允許調試器內省。這可以通過這個鍵來禁用。你同樣可以用這個設定來強制啟用它，即使沒有調試執行，這對調試生產應用很有用（但風險也很大） | | SECRET_KEY | 密鑰 | | SESSION_COOKIE_NAME | 會話 cookie 的名稱。 | | SESSION_COOKIE_DOMAIN | 會話 cookie 的域。如果不設置這個值，則cookie 對 SERVER_NAME 的全部子域名有效 | | SESSION_COOKIE_PATH | 會話 cookie 的路徑。如果不設置這個值，且沒有給 '/' 設置過，則 cookie 對APPLICATION_ROOT 下的所有路徑有效。 | | SESSION_COOKIE_HTTPONLY | 控制 cookie 是否應被設置 httponly 的標志，默認為 True | | SESSION_COOKIE_SECURE | 控制 cookie 是否應被設置安全標志，默認為 False | | PERMANENT_SESSION_LIFETIME | 以 [datetime.timedelta](http://docs.python.org/dev/library/datetime.html#datetime.timedelta "(在 Python v3.5)") [http://docs.python.org/dev/library/datetime.html#datetime.timedelta] 對象控制長期會話的生存時間。從 Flask 0.8 開始，也可以用整數來表示秒。 | | SESSION_REFRESH_EACH_REQUEST | 這個標志控制永久會話如何刷新。如果被設置為True （這是默認值），每一個請求 cookie都會被刷新。如果設置為 False ，只有當cookie 被修改后才會發送一個 set-cookie的標頭。非永久會話不會受到這個配置項的影響。 | | USE_X_SENDFILE | 啟用/禁用 x-sendfile | | LOGGER_NAME | 日志記錄器的名稱 | | SERVER_NAME | 服務器名和端口。需要這個選項來支持子域名（例如： 'myapp.dev:5000' ）。注意localhost 不支持子域名，所以把這個選項設置為 “localhost” 沒有意義。設置SERVER_NAME 默認會允許在沒有請求上下文而僅有應用上下文時生成 URL | | APPLICATION_ROOT | 如果應用不占用完整的域名或子域名，這個選項可以被設置為應用所在的路徑。這個路徑也會用于會話 cookie 的路徑值。如果直接使用域名，則留作None | | MAX_CONTENT_LENGTH | 如果設置為字節數， Flask 會拒絕內容長度大于此值的請求進入，并返回一個 413 狀態碼 | | SEND_FILE_MAX_AGE_DEFAULT: | 默認緩存控制的最大期限，以秒計，在[flask.Flask.send_static_file()](# "flask.Flask.send_static_file") (默認的靜態文件處理器)中使用。對于單個文件分別在[Flask](# "flask.Flask") 或[Blueprint](# "flask.Blueprint") 上使用[get_send_file_max_age()](# "flask.Flask.get_send_file_max_age")來覆蓋這個值。默認為 43200（12小時）。 | | TRAP_HTTP_EXCEPTIONS | 如果這個值被設置為 True ，Flask不會執行HTTP 異常的錯誤處理，而是像對待其它異常一樣，通過異常棧讓它冒泡地拋出。這對于需要找出HTTP 異常源頭的可怕調試情形是有用的。 | | TRAP_BAD_REQUEST_ERRORS | Werkzeug 處理請求中的特定數據的內部數據結構會拋出同樣也是“錯誤的請求”異常的特殊的 keyerrors 。同樣地，為了保持一致，許多操作可以顯式地拋出 BadRequest 異常。因為在調試中，你希望準確地找出異常的原因，這個設置用于在這些情形下調試。如果這個值被設置為 True ，你只會得到常規的回溯。 | | PREFERRED_URL_SCHEME | 生成URL的時候如果沒有可用的 URL 模式話將使用這個值。默認為 http | | JSON_AS_ASCII | 默認情況下 Flask 使用 ascii 編碼來序列化對象。如果這個值被設置為 False ， Flask不會將其編碼為 ASCII，并且按原樣輸出，返回它的unicode 字符串。比如 jsonfiy 會自動地采用utf-8 來編碼它然后才進行傳輸。 | | JSON_SORT_KEYS | 默認情況下 Flask 按照 JSON 對象的鍵的順序來序來序列化它。這樣做是為了確保鍵的順序不會受到字典的哈希種子的影響，從而返回的值每次都是一致的，不會造成無用的額外 HTTP 緩存。你可以通過修改這個配置的值來覆蓋默認的操作。但這是不被推薦的做法因為這個默認的行為可能會給你在性能的代價上帶來改善。 | | JSONIFY_PRETTYPRINT_REGULAR | 如果這個配置項被 True （默認值），如果不是 XMLHttpRequest 請求的話（由X-Requested-With 標頭控制）json 字符串的返回值會被漂亮地打印出來。 | 關于 SERVER_NAME 的更多 SERVER_NAME 用于子域名支持。因為 Flask 在得知現有服務器名之前不能猜測出子域名部分，所以如果你想使用子域名，這個選項是必要的，并且也用于會話 cookie 。 請注意，不只是 Flask 有不知道子域名是什么的問題，你的 web 瀏覽器也會這樣。現代 web 瀏覽器不允許服務器名不含有點的跨子域名 cookie 。所以如果你的服務器名是 'localhost' ，你不能在 'localhost' 和它的每個子域名下設置 cookie 。請選擇一個合適的服務器名，像 'myapplication.local' ，并添加你想要的 服務器名 + 子域名 到你的 host 配置或設置一個本地 [綁定](https://www.isc.org/software/bind) [https://www.isc.org/software/bind] 。 0.4 新版功能: LOGGER_NAME 0.5 新版功能: SERVER_NAME 0.6 新版功能: MAX_CONTENT_LENGTH 0.7 新版功能: PROPAGATE_EXCEPTIONS, PRESERVE_CONTEXT_ON_EXCEPTION 0.8 新版功能: TRAP_BAD_REQUEST_ERRORS, TRAP_HTTP_EXCEPTIONS,APPLICATION_ROOT, SESSION_COOKIE_DOMAIN,SESSION_COOKIE_PATH, SESSION_COOKIE_HTTPONLY,SESSION_COOKIE_SECURE 0.9 新版功能: PREFERRED_URL_SCHEME 0.10 新版功能: JSON_AS_ASCII, JSON_SORT_KEYS, JSONIFY_PRETTYPRINT_REGULAR 1.0 新版功能: SESSION_REFRESH_EACH_REQUEST ### 從文件配置 如果你能在獨立的文件里存儲配置，理想情況是存儲在當前應用包之外，它將變得更有用。這使得通過各式包處理工具（ [*部署和分發*](#) ）打包和分發你的應用成為可能，并在之后才修改配置文件。 則一個常見模式為如下: ~~~ app = Flask(__name__) app.config.from_object('yourapplication.default_settings') app.config.from_envvar('YOURAPPLICATION_SETTINGS') ~~~ 首先從 yourapplication.default_settings 模塊加載配置，然后用YOURAPPLICATION_SETTINGS 環境變量指向的文件的內容覆蓋其值。 在 Linux 或 OS X 上，這個環境變量可以在服務器啟動之前，在 shell 中用 export 命令設置: ~~~ $ export YOURAPPLICATION_SETTINGS=/path/to/settings.cfg $ python run-app.py * Running on http://127.0.0.1:5000/ * Restarting with reloader... ~~~ 在 Windows 下則使用其內置的 set 命令: ~~~ >set YOURAPPLICATION_SETTINGS=\path\to\settings.cfg ~~~ 配置文件其實是 Python 文件。只有大寫名稱的值才會被存儲到配置對象中。所以請確保你在配置鍵中使用了大寫字母。 這里是一個配置文件的例子: ~~~ # Example configuration DEBUG = False SECRET_KEY = '?\xbf,\xb4\x8d\xa3"<\x9c\xb0@\x0f5\xab,w\xee\x8d$0\x13\x8b83' ~~~ 確保足夠早載入配置，這樣擴展才能在啟動時訪問配置。配置對象上也有其它方法來從多個文件中載入配置。完整的參考請閱讀 [Config](# "flask.Config") 對象的文檔。 ### 配置的最佳實踐 之前提到的建議的缺陷是它會使得測試變得有點困難。基本上，這個問題沒有單一的100% 解決方案，但是你可以注意下面的事項來改善體驗: 1. 在函數中創建你的應用，并在上面注冊藍圖。這樣你可以用不同的配置來創建多個應用實例，以此使得單元測試變得很簡單。你可以用這樣的方法來按需傳入配置。 1. 不要寫出在導入時需要配置的代碼。如果你限制只在請求中訪問配置，你可以在之后按需重新配置對象。 ### 開發 / 生產 大多數應用不止需要一份配置。生產服務器和開發期間使用的服務器應該各有一份單獨的配置。處理這個的最簡單方法是，使用一份默認的總會被載入的配置，和一部分版本控制，以及獨立的配置來像上面提到的例子中必要的那樣覆蓋值: ~~~ app = Flask(__name__) app.config.from_object('yourapplication.default_settings') app.config.from_envvar('YOURAPPLICATION_SETTINGS') ~~~ 然后你只需要添加一個獨立的 config.py 文件然后 exportYOURAPPLICATION_SETTINGS=/path/to/config.py 。不過，也有其它可選的方式。例如你可以使用導入或繼承。 在 Django 世界中流行的是在文件頂部，顯式地使用fromyourapplication.default_settingsimport* 導入配置文件，并手動覆蓋更改。你也可以檢查一個類似 YOURAPPLICATION_MODE 的環境變量來設置production ， development 等等，并導入基于此的不同的硬編碼文件。 一個有意思的模式是在配置中使用類和繼承: ~~~ class Config(object): DEBUG = False TESTING = False DATABASE_URI = 'sqlite://:memory:' class ProductionConfig(Config): DATABASE_URI = 'mysql://user@localhost/foo' class DevelopmentConfig(Config): DEBUG = True class TestingConfig(Config): TESTING = True ~~~ 啟用這樣的配置你需要調用 [from_object()](# "flask.Config.from_object") ~~~ app.config.from_object('configmodule.ProductionConfig') ~~~ 管理配置文件有許多方式，這取決于你。這里仍然給出一個好建議的列表: - 在版本控制中保留一個默認的配置。向配置中遷移這份默認配置，或者在覆蓋配置值前，在你自己的配置文件中導入它。 - 使用環境變量來在配置間切換。這樣可以在 Python 解釋器之外完成，使開發和部署更容易，因為你可以在不觸及代碼的情況下快速簡便地切換配置。如果你經常在不同的項目中作業，你甚至可以創建激活一個 virtualenv 并導出開發配置的腳本。 - 使用 [fabric](http://fabfile.org/) [http://fabfile.org/] 之類的工具在生產環境中獨立地向生產服務器推送代碼和配置。參閱 [*使用 Fabric 部署*](#) 模式來獲得更詳細的信息。 ### 實例文件夾 0.8 新版功能. Flask 0.8 引入了示例文件夾。 Flask 在很長時間使得直接引用相對應用文件夾的路徑成為可能(通過 Flask.root_path )。這也是許多開發者加載存儲在載入應用旁邊的配置的方法。不幸的是，這只會在應用不是包，即根路徑指向包內容的情況下才能工作。 在 Flask 0.8 中，引入了 Flask.instance_path 并提出了“實例文件夾”的新概念。實例文件夾被為不使用版本控制和特定的部署而設計。這是放置運行時更改的文件和配置文件的最佳位置。 你可以在創建 Flask 應用時顯式地提供實例文件夾的路徑，也可以讓 Flask 自動找到它。對于顯式的配置，使用 instance_path 參數: ~~~ app = Flask(__name__, instance_path='/path/to/instance/folder') ~~~ 請注意給出的 *一定* 是絕對路徑。 如果 instance_path 參數沒有賦值，會使用下面默認的位置: - 未安裝的模塊: ~~~ /myapp.py /instance ~~~ - 未安裝的包: ~~~ /myapp /__init__.py /instance ~~~ - 已安裝的包或模塊: ~~~ $PREFIX/lib/python2.X/site-packages/myapp $PREFIX/var/myapp-instance ~~~ $PREFIX 是你 Python 安裝的前綴。這個前綴可以是 /usr 或者你的virtualenv 的路徑。你可以打印 sys.prefix 的值來查看前綴被設置成了什么。 既然配置對象提供從相對文件名來載入配置的方式，那么我們也使得它從相對實例路徑的文件名加載成為可能，如果你想這樣做。配置文件中的相對路徑的行為可以在“相對應用的根目錄”（默認）和 “相對實例文件夾”中切換，后者通過應用構造函數的 instance_relative_config 開關實現: ~~~ app = Flask(__name__, instance_relative_config=True) ~~~ 這里有一個配置 Flask 來從模塊預載入配置并覆蓋配置文件夾中配置文件（如果存在）的完整例子: ~~~ app = Flask(__name__, instance_relative_config=True) app.config.from_object('yourapplication.default_settings') app.config.from_pyfile('application.cfg', silent=True) ~~~ 實例文件夾的路徑可以在 Flask.instance_path 找到。 Flask 也提供了一個打開實例文件夾中文件的捷徑，就是 Flask.open_instance_resource() 。 兩者的使用示例: ~~~ filename = os.path.join(app.instance_path, 'application.cfg') with open(filename) as f: config = f.read() # or via open_instance_resource: with app.open_instance_resource('application.cfg') as f: config = f.read() ~~~ ? 版權所有 2013, Armin Ronacher.