本章主要探討針對以下的幾個問題：
1、DEBG的作用及與靜態資源的關係；
2、剛上手web框架的時候發現在瀏覽器運行未能加載靜態資源；
3、Nginx與靜態資源的關係；
4、其他服務器。
DEBUG的作用
一般的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,
# 部署後通過該路徑取代真實的靜態文件路徑，在頁面訪問，
# 如路徑爲IP:port/path/to/mysite/common_static/appname/xx.css，
# 在瀏覽器訪問IP:port/mysite/static/common_static/appname/xx.css，
STATIC_URL = '/static/'
# collectstatic命令執行後統一放置的目錄
# 可取其他名，但建議統一用static，
# 在Nginx裏配置location /static/時指向該路徑
STATIC_ROOT = os.path.join(BASE_DIR, '/static/')
# 非必須，是非app下的static目錄，比如一些公共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
執行後，會將項目中所有app的static目錄（包括STATICFILES_DIRS 下的靜態文件）都蒐集到STATIC_ROOT 指定的目錄裏。
4、一般來說，Nginx默認生產的配置文件路徑爲：/etc/nginx/nginx.conf ，可以直接改，也可以新創建一個（有時候可能會需要部署多個項目），進行如下配置：
server {
listen 8000;
server_name 127.0.0.1
charset UTF-8;
access_log /var/log/nginx/yourweb_access.log;
error_log /var/log/nginx/yourweb_error.log;
# 目前不需要關注這裏
location / {
include uwsgi_params; # 這裏是配置了uwsgi之後
uwsgi_pass 127.0.0.1:8000;
client_max_body_size 100M;
}
# 這一段用於配置靜態文件對應的名字
# /static對應STATIC_ROOT
location /static {
autoindex on;
alias /your/path/to/static/; # 你的static最終合成的路徑
}
}
Nginx
對我們的web開發來說，Nginx有三個常用場景：處理靜態資源、負載均衡、反向代理。
一般來說，我們部署時常用的：Nginx+uwsgi+supervisor。Nginx接受請求，如果請求的是靜態資源，則由Nginx自己處理，直接返回給客戶端。而如果是請求動態資源，比如與數據庫的增刪改查等，Nginx則會將請求分發給uwsgi，而supervisor只是用於方便管理uwsgi進程。
Nginx其實不是必須的，uwsgi自己本身就可以完成整個的和瀏覽器交互的流程，但正如前面提到的Nginx的三個常用場景，uwsgi在負載均衡和靜態文件的處理上均不如Nginx，以及uwsgi本身是內網接口，不應該被直接訪問，而Nginx卻可以只開放某個接等等好處。
另外，除了Nginx，還有一個出現的比較早的是Apache，二者剛好相反，Nginx對於處理靜態文件很不錯，但動態請求幾乎做不了什麼，而Apache在動態的處理上有優勢。
uwsgi
而Python的WSGI是後來出現的，也是用來處理動態請求的，它其實算是一個爲了統一而出現的服務器網關接口。WSGI沒有官方的實現， WSGI更像一個協議，只要遵照這些協議，WSGI應用都可以在任何服務器上運行。
WSGI（全稱Web Server Gateway Interface，服務器網關接口），是Web服務器（如nginx）與應用服務器（如uWSGI）通信的一種規範，uWSGI是實現了WSGI server協議的服務器。
它出現的原因是，比較早以前，Python應用程序通常是爲CGI，FastCGI，mod_python中的一個而設計，甚至是爲特定Web服務器的自定義的API接口而設計的。就是不同的框架對應不同的web服務器，選擇某種框架就被規定了你要選擇哪種web服務器，反之亦然。
而Django和Flask都是實現了WSGI application協議的web框架。它們都有自己實現的WSGI server，因此我們可以直接啓動，但主要用於服務器調試，但真正部署生產環境時就要用uWSGI服務了。（uwsgi是協議，uWSGI是web服務器，注意大小寫。）
Django使用的是Python自帶的simple HTTPServer創建的，在安全性和效率上不怎樣，uWSGI服務器自己實現了基於uwsgi協議的server部分，我們只需要在uwsgi的配置文件中指定application的地址，uWSGI就能直接和應用框架中的WSGI application通信。
uWSGI是一個全功能的HTTP服務器，將HTTP協議轉化成語言支持的網絡協議，如WSGI協議、uwsgi協議、http協議，讓Python可以直接使用。
uwsgi是一種uWSGI的內部協議，使用二進制方式和其他應用程序進行通信。
參考鏈接：
1、https://baike.baidu.com/item/wsgi/3381529?fr=aladdin
2、https://www.xuebuyuan.com/652975.html
3、https://blog.csdn.net/liugaigai427/article/details/83280353
4、https://www.jianshu.com/p/1c6ae9ccd174
5、https://docs.djangoproject.com/en/2.0/howto/static-files/