python web框架DEBUG的作用

本章主要**針對以下的幾個問題：

1、debg的作用及與靜態資源的關係；

2、剛上手web框架的時候發現在瀏覽器執行未能載入靜態資源；

3、nginx與靜態資源的關係；

4、其他伺服器。

一般的web框架裡一般都會分為開發模式和生產模式，具體的體現為debug是true還是false。而debug的作用主要有三種：

1、debug=true時（即開發環境），我們可以在瀏覽器和控制台看到輸出的錯誤資訊，但是如果是生產模式，一旦**出錯，則會被使用者看到源**。

注意：在設定為false時，還需要設定allowed_hosts，讓使用者只能通過某個ip或網域名稱訪問。

2、debug=true時，修改專案後，會自動重啟專案，不需要手動重啟。

當然，在我們自己開發的專案上是這樣的，因為每次我們修改完都要中斷上次執行的manage.py命令，然後再次輸入該命令執行才能看到修改後的頁面。而設定為開發模式時，只需要重新整理頁面即可。但是，如果是比較大的專案，該專案依賴於大量的其他服務等，仍然需要手動重啟該服務。

3、靜態檔案的管理。

當debug=true的時候，django是通過staticfileshandler來管理靜態檔案的，會自動幫我們對靜態檔案進行路由。

而debug=false的時候，django就不處理靜態檔案了，或者說靜態檔案訪問的介面就不走django了，而是交由其他的靜態伺服器如nginx來處理。

如果你將debug改為了false，卻沒有部署nginx，那就會發現無法訪問靜態檔案，css和js樣式全都不顯示。檢視f12，也會發現無法載入。我記得我剛開始學框架的時候，碰到這種問題，不對頭的查了半天卻都找不到正確答案，但是因為知識面太小，完美的避開了這個原因，導致一度都不清楚為什麼不顯示。

而django在部署時，還需要通過collectstatic命令來將所有靜態檔案統一放置到根目錄下的某個公共的目錄下（由static_root所指定的目錄，需自己設定），這樣做我們才能通過某個路由訪問靜態檔案。

部署時配置靜態檔案

1、在settings.py檔案裡找到static_url項，新增後兩項：

# 利用static_url對映static_root, # 部署後通過該路徑取代真實的靜態檔案路徑，在頁面訪問， static_url = '/static/' # collectstatic命令執行後統一放置的目錄 # 可取其他名，但建議統一用static， # 在nginx裡配置location /static/時指向該路徑 static_root = os.path.join(base_dir, '/static/' ) staticfiles_dirs = [ os.path.join(base_dir, 'common_static'),

]

2、加入到urls. py，以便模板訪問：

from django.conf import settings
from django.conf.urls.static import static
urlpatterns =
[# ... the rest of your urlconf goes here ...
]+ static(settings.static_url, document_root=settings.static_root)

3、執行命令：

python manage.py collectstatic

4、一般來說，nginx預設生產的配置檔案路徑為：/etc/nginx/nginx.conf，可以直接改，也可以新建立乙個（有時候可能會需要部署多個專案），進行如下配置：

server 
# 這一段用於配置靜態檔案對應的名字
# /static對應static_root 
location /static 
}

對我們的web開發來說，nginx有三個常用場景：處理靜態資源、負載均衡、反向**。

一般來說，我們部署時常用的：nginx+uwsgi+supervisor。nginx接受請求，如果請求的是靜態資源，則由nginx自己處理，直接返回給客戶端。而如果是請求動態資源，比如與資料庫的增刪改查等，nginx則會將請求分發給uwsgi，而supervisor只是用於方便管理uwsgi程序。

nginx其實不是必須的，uwsgi自己本身就可以完成整個的和瀏覽器互動的流程，但正如前面提到的nginx的三個常用場景，uwsgi在負載均衡和靜態檔案的處理上均不如nginx，以及uwsgi本身是內網介面，不應該被直接訪問，而nginx卻可以只開放某個接等等好處。

另外，除了nginx，還有乙個出現的比較早的是apache，二者剛好相反，nginx對於處理靜態檔案很不錯，但動態請求幾乎做不了什麼，而apache在動態的處理上有優勢。

而python的wsgi是後來出現的，也是用來處理動態請求的，它其實算是乙個為了統一而出現的伺服器閘道器介面。wsgi沒有官方的實現， wsgi更像乙個協議，只要遵照這些協議，wsgi應用都可以在任何伺服器上執行。

wsgi（全稱web server gateway inte***ce，伺服器閘道器介面），是web伺服器（如nginx）與應用伺服器（如uwsgi）通訊的一種規範，uwsgi是實現了wsgi server協議的伺服器。

它出現的原因是，比較早以前，python應用程式通常是為cgi，fastcgi，mod_python中的乙個而設計，甚至是為特定web伺服器的自定義的api介面而設計的。就是不同的框架對應不同的web伺服器，選擇某種框架就被規定了你要選擇哪種web伺服器，反之亦然。

uwsgi是乙個全功能的http伺服器，將http協議轉化成語言支援的網路協議，如wsgi協議、uwsgi協議、http協議，讓python可以直接使用。

uwsgi是一種uwsgi的內部協議，使用二進位制方式和其他應用程式進行通訊。

2、3、

4、5、

python web框架DEBUG的作用

python web開發框架

python web框架推薦

Python Web開發框架

python web框架DEBUG的作用

python web開發框架

python web框架 推薦

Python Web開發框架

相關推薦

python web框架推薦