第二章 Django 配置信息

Django 配置信息

Django 的配置文件 setting.py 用于配置整个网站的环境和功能，核心配置必须有项目路径、密钥配置、域名访问权限、App列表、中间件、资源文件、模板配置、数据库的连接方式。

2.1 基本配置信息

一个简单的项目必须具备的基本配置信息有：项目路径、密钥配置、域名访问权限、App列表和中间件。以 MyDjango 项目为例，settings.py 的基本配置如下：

import os
# 项目路径
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

# 密钥配置
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'u_x)*sw2mkj8dd_g=$2p!&wr7c9v(%#8+5ktt(3k8q05oi@z^('

# 调试模式
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True

# 域名访问权限
ALLOWED_HOSTS = []


# Application definition
# App 列表
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

上述代码列出了项目路径 BASE_DIR、密钥配置 SECRET_KEY、调试模式 DEBUG、域名访问权限 ALLOWED_HOSTS 和 App 列表 INSTALLED_APPS，各个配置说明如下：

项目路径 BASE_DIR：主要通过 os 模块读取当前项目在计算系统的具体路径，该代码在创建项目时自动生成，一般情况下无须修改。

密钥配置 SECRET_KEY：这是一个随机值，在项目创建的时候自动生成，一般情况下无须修改。主要用于重要数据的加密处理，提高项目的安全性，避免遭到攻击者恶意破坏。密钥主要用于用户密码、CSRF机制和会话Session等数据加密。

• 用户密码：Django 内置一套 Auth 认证系统，该系统具有用户认证和存储用户信息等功能，在创建用户的时候，将用户密码通过密钥进行加密处理，保证用户的安全性。
• CSRF机制：该机制主要用于表单提交，防止窃取网站的用户信息来制造恶意请求。
• 会话Session：Session 的信息存放在Cookie中，以一串随机的字符串表示，用于标识当前访问网站的用户身份，记录相关用户信息。

调试模式 DEBUG：该值为布尔类型。如果在开发调试阶段，那么应设置为 True，在开发调试过程中会自动检测代码是否发生更改，根据检测结果执行是否刷新重启系统。如果项目部署上线，那么应将其改为 False，否则会泄漏网站的相关信息。

域名访问权限 ALLOWED_HOSTS：设置可访问的域名，默认值为空列表。当DEBUG 为 True 并且 ALLOWED_HOSTS 为空列表时，项目只允许以 localhost 或 127.0.0.1 在浏览器上访问。当 DEBUG 为 False 时，ALLOWED_HOSTS为必填项，否则程序无法启动，如果想允许所有域名访问，可以ALLOWED_HOSTS=[*]。

App 列表 INSTALLED_APPS：告诉 Django 有哪些 App。在项目创建时已经有 admin、auth、session 等配置信息，这些都是 Django 内置的应用功能，各个功能说明如下：

• admin：内置的后台管理系统。
• auth：内置的用户认证系统。
• contenttypes：记录项目中所有 model 元数据（Django 的 ORM 框架）。
• sessions：Session 会话功能，用于标识当前访问网站的用户身份，记录相关用户信息。
• messages：消息提示功能。
• staticfiles：查找静态资源路径。

如果在项目中创建了 App，就必须在 App 列表 INSTALLED_APPS 添加 App 名称。将 MyDjango 项目已经创建的 App 添加到 App 列表，代码如下：

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'index',
]

2.2 资源文件配置

资源文件配置分为静态资源和媒体资源。静态资源的配置方式由配置属性 STATIC_URL、STATICFILES_DIRS 和 STATIC_ROOT 进行设置；媒体资源的配置方式由配置属性 MEDIA_URL 和 MEDIA_ROOT 决定。

2.2.1 资源路由----STATIC_URL

静态资源指的是网站中不会改变的文件。在一般的应用程序中，静态资源包括 CSS 文件、JavaScript 文件以及图片等资源文件。此处简单介绍 CSS 文件和 JavaScript 文件。

CSS 也称层叠样式表（Cascading Style Sheets），是一种用来表现 HTML (标准通用标记语言的一个应用)或 XML（标准通用标记语言的一个子集）等文件样式的计算机语言。CSS 不仅可以静态的修饰网页，还可以配合各种脚本语言动态的对网页各元素进行格式化。

JavaScript 是一种直译式脚本语言，也是一种动态类型、弱类型、基于原型的语言，内置支持类型。它的解释器被称为 JavaScript 引擎，为浏览器的一部分，广泛用于客户端的脚本语言，最早是在 HTML（标准通用标记语言下的一个应用）网页上使用的，用来给 HTML 网页啬动态功能。

一个项目开发过程中肯定需要使用 CSS 和 JavaScript 文件，这些静态文件的存放主要由配置文件 settings.py 设置，Django 默认配置信息如下：

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/3.0/howto/static-files/

STATIC_URL = '/static/'

上述配置是设置静态资源的路由地址，其作用是通过浏览器访问 Django 的静态资源。默认情况下，Django 只能识别项目应用 App 的 static 文件夹里面的静态资源。当项目启动时，Django 会从项目应用 App 里面查找相应的资源文件，查找功能主要由 App 列表 INSTALLED_APPS 的 staticfiles 实现。在 index 中创建 static 文件夹并在文件夹中放置随便一张图片：

Django 在调试模式（DEBUG=True）下只能识别项目应用 App 的 static 文件夹里面的静态资源，如果该文件夹改为其他名字，Django 就无法识别，若将 static 文件夹放在 MyDjango 的项目目录下，则 Django 也是无法识别的。

为了进一步验证 Django 在调试模式（DEBUG=True）下只能识别项目应用 App 的 static 文件夹，我们在 index 文件夹里创建 Mystatic 文件夹并放置图片 cow.jpg，在 MyDjango 根目录下创建 static 文件夹并放置图片 duck.jpg。最终整个 MyDjango 的静态资源文件夹有：

• static（在 index 文件夹）
• Mystatic（在 index 文件夹）
• static（在 MyDjango 根目录）

启动 MyDjango 并在浏览器上分别访问：

• http://127.0.0.1:8000/static/dog.jpg
• http://127.0.0.1:8000/static/duck.jpg
• http://127.0.0.1:8000/staic/cow.jpg

我们发现只有 dog.jpg 是可以访问的，而 duck.jpg 和 cow.jpg 无法访问。

综上所述，若资源路由 STATIC_URL 的值为/static/，则浏览器访问静态资源的网站必须为 static，否则无法访问，并且 Django 在调试模式（DEBUG=True）下只能识别App目录下的 static 文件夹。

2.2.2 资源集合----STATICFILES_DIRS

由于 STATIC_URL 的特殊性，在开发中会造成诸多不便，比如将静态文件夹存放在项目的根目录以及定义多个静态文件夹等。以 MyDjango 为例，若想在网页上正常访问图片 duck.jpg 和 cow.jpg，可以将根目录的 static 文件夹和 index 的 Mystatic 文件夹写入资源集合 STATICFILES_DIRS。

在配置文件 settings.py 中设置 STATICFILES_DIRS 属性。该属性以列表的形式表示，设置方式如下：

STATICFILES_DIRS = [
    # 设置根目录的静态资源文件夹
    os.path.join(BASE_DIR, 'static'),
    # 设置 App(index) 的静态资源文件夹 Mystatic
    os.path.join(BASE_DIR, 'index/Mystatic')
]

再次启动 MyDjango 并在浏览器上分别访问dog.jpg、duck.jpg 和 cow.jpg，可以发现三者都能访问了。

浏览器访问图片的时候，图片路径皆为http://127.0.0.1/static/xxx.jpg，图片路径的 static 是指资源路径 STATIC_URL 的值，若将其设置为STATIC_URL = '/lowenve/'，再次重启 MyDjango 项目并在浏览器上将图片资源路径的 static 改为 lowenve 即可。

2.2.3 资源部署----STATIC_ROOT

静态资源配置还有 STATIC_ROOT，其作用是在服务器上部署项目，实现服务器和项目之间的映射。STATIC_ROOT 主要收集整个项目的静态资源并存放在一个新的文件夹，然后该文件夹与服务器之间构建映射关系。STATIC_ROOT 的配置如下：

STATIC_ROOT = os.path.join(BASE_DIR, 'AllStatic')

当项目的配置属性 DEBUG 设置为 True 的时候，Django 会自动提供静态文件代理服务，此时整个项目处于开发阶段，因此无须使用 STATIC_ROOT。当配置属性 DEBUG 设为 False 的时候，意味着项目进入生产环境，Django 不再提供静态资源代理服务，此时需要在项目的配置文件中设置 STATIC_ROOT。

设置 STATIC_ROOT 需要使用 Django 操作指令 collectstatic来收集所有静态资源，这些静态资源都会保存在 STATIC_ROOT 所设置的文件夹里。关于 STATIC_ROOT 的使用会在后续章节详细讲述。

2.2.4 媒体资源—MEDIA

一般情况下，STATIC_URL 是设置静态文件的路由地址，如 CSS 样式文件、JavaScript 文件以及常用图片等。对于一些经常变动的资源，通常将其存放在媒体资源文件夹，如用户头像、歌曲文件等。

媒体资源和静态资源是可以同时存在的，而且两者可以独立运行，互不影响，而媒体资源只有配置属性 MEDIA_URL 和 MEDIA_ROOT。以 MyDjango 为例，在 MyDjango 的根目录下创建 media 文件夹并存放图片 monkey.jpg。

然后在配置文件 settings.py 里设置配置属性 MEDIA_URL 和 MEDIA_ROOT，MEDIA_URL 用于设置媒体资源的路由地址，MEDIA_ROOT 用于获取 media 文件夹在计算机系统的完整路径信息，如下所示：

# 设置媒体路径地址信息
MEDIA_URL = '/media/'
# 获取 media 文件夹的完整路径信息
MEDIA_ROOT = os.path.join(BASE_DIR, 'media')

配置属性设置后，还需要将 media 文件夹注册到 Django 里，让 Django 知道如何找到媒体文件，否则无法在浏览器上访问该文件夹的文件信息。打开 MyDjango 文件夹的 urls.py 文件，为媒体文件夹 media 添加相应的路由地址，代码如下：

from django.contrib import admin
from django.urls import path, re_path
# 导入项目应用 index
from index.views import index

from index.views import index
# 配置媒体文件夹 media
from django.views.static import serve
from django.conf import settings

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', index),
    re_path('media/(?p<path>.*)', serve, {'document_root': settings.MEDIA_ROOT}, name='media'),
]

最后再次启动 MyDjango，并在浏览器上访问 http://127.0.0.1:8000/media/monkey.jpg 和 http://127.0.0.1:8000/static/dog.jpg，发现两都皆可正常访问。

2.3 模板配置

在 Web 开发中，模板是一种较为特殊的 HTML 文档。这个 HTML 文档嵌入了一些能够让 Django 识别的变量和指令，然后由 Django 的模板引擎解析这些变量和指令，生成完整的 HTML 网页并返回给用户浏览。模板是 Django 里面的 MTV 框架模式的T部分，配置模板路径是告诉 Django 在解析模板时，如何找到模板所在的位置。创建项目时，Django 已有初始的模板配置信息如下：

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

模板配置是以列表形式呈现的，每个元素具有不同的含义，其含义说明如下：

• BACKEND：定义模板引擎，用于识别模板里面的变量和指令。内置的模板引擎有 Django Templates 和 jinja2.Jinja2，每个模板引擎都有自己的变量和指令语法。
• DIRS：设置模板所在路径，告诉 Django 在哪个地方查找模板的位置，默认为空列表。
• APP_DIRS：是否在APP里查找模板文件。
• OPTIONS：用于填充在 RequestContext 的上下文（模板里面的变量和指令），一般情况下不做任何修改。

模板配置只配置 DIRS 的属性即可，在项目的根目录和 index 下分别创建 templates 文件夹，并在文件夹下分别创建文件 index.html 和 app_index.html，如下所求：

.
├── MyDjango
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-36.pyc
│   │   ├── settings.cpython-36.pyc
│   │   ├── urls.cpython-36.pyc
│   │   └── wsgi.cpython-36.pyc
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── db.sqlite3
├── index
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-36.pyc
│   │   └── views.cpython-36.pyc
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── static
│   │   └── dog.jpg
│   ├── templates
│   │   └── app_index.html  # 这～
│   ├── tests.py
│   └── views.py
├── manage.py
├── media
└── templates
    └── index.html  # 还有这～

一般情况下，根目录的 templates 通常存放共用的模板文件，能为各个 App 的模板文件调用，这个模板符合代码重复使用的原则。根据上面树形图中的文件位置，配置属性 TEMPLATES 的配置信息如下：

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
            os.path.join(BASE_DIR, 'templates'),
            os.path.join(BASE_DIR, 'index/tempaltes')
            ],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },

中间件

中间件（Middlevare）是一个用来处理 Django 的请求（Request）和响应（Response）的框架级别的钩子，它是一个轻量、低级别的插件系统，用于在全局范围内改变 Django 的输入和输出。

当用户在网站中进行某些操作时，这个过程是用户向网站发送 HTTP 请求（Request）；而网站会根据用户的操作返回相关的网页内容，这个过程称为响应处理（Response）。从请求到响应的过程中，当 Django 接收到用户请求时，首先经过中间件处理请求信息，然后后端 views 执行相关的处理，然后将处理结果返回给用户。

中间件的作用是处理用户请求信息和返回响应内容。开发者可以根据自己的开发需求自定义中间件，只要将自定义的中间件添加到配置属性 MIDDLEWARE 中即可激活。

一般情况下，Django 默认的中间件配置均可满足大部分的开发需求。我们在项目的 MIDDLEWARE 中添加 LocaleMiddleware 中间件，使得 Django 内置的功能支持中文显示，代码如下：

MIDDLEWARE = [
    'debug_toolbar.middleware.DebugToolbarMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    # 添加中间件 LocaleMiddleware
    'django.middleware.locale.LocaleMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

配置属性 MIDDLEWARE 的数据格式为列表类型，每个中间件的设置顺序是固定的，如果随意变更中间件，就很容易导致程序异常。每个中间件的说明如下：

• SecurityMiddleware：内置的安全机制，保护用户和网站的通信安全。
• SessionMiddleware：会话 Session 功能。
• LocaleMiddleware：国际化和本地化功能。
• CommonMiddleware：处理请求信息，规范化请求内容。
• CsrfViewMiddleware：开启 CSRF 防护功能。
• AuthenticationMiddleware：开启内置的用户认证系统。
• MessageMiddleware：开启内置的信息提示功能。
• XFrameOptionsMiddleware：防止恶意程序单击劫持。