python web框架DEBUG的作用

本章主要探讨针对以下的几个问题：

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/