作者:李俊才 (jcLee95):https://blog.csdn.net/qq_28550263
邮箱 :291148484@163.com
本文地址:https://blog.csdn.net/qq_28550263/article/details/132893616
【介绍】:本文讲解Django的项目结构与配置。
目 录
- 1. 概述
- 2. Django的项目结构
- 2.1 项目根目录(Project Root)
- 2.2 应用目录(Apps)
- 2.3 配置文件
- 2.4 数据库迁移目录
- 2.5 静态文件目录
- 2.5.1 静态文件目录的配置
- 2.5.2 应用中的静态文件
- 2.5.3 加载静态文件
- 2.5.4 静态文件的收集
- 2.5.5 静态文件的配置选项
- 2.6 模板目录(Templates)
- 2.6.1 模板目录的配置
- 2.6.2 APP_DIRS 选项
- 2.6.3 模板文件的命名规则
- 2.6.4 模板继承
- 2.6.5 模板标签和过滤器
- 2.6.6 模板加载顺序
- 2.7 测试文件目录(Tests)
- 2.8虚拟隔离环境
- 3. Django的配置文件settings.py
- 3.1 基础路径和文件生成
- 3.2 快速开始开发设置
- 3.2.1 `SECRET_KEY` 设置
- 3.2.2 `DEBUG` 设置
- 3.2.3 `ALLOWED_HOSTS` 设置
- 3.3 应用程序定义
- 3.3.1 django.contrib.admin
- 3.3.2 django.contrib.auth
- 3.3.3 django.contrib.contenttypes
- 3.3.4 django.contrib.sessions
- 3.3.5 django.contrib.messages
- 3.3.6 django.contrib.staticfiles
- 3.4 中间件设置
- 3.5 URL 配置(指定跟路由文件)
- 3.6 模板配置
- 3.7 WSGI 应用程序设置
- 3.8 数据库配置
- 3.9 密码验证设置
- 3.10 国际化和时区设置
- 3.10.1 `LANGUAGE_CODE`
- 3.10.2 `TIME_ZONE`
- 3.10.3 `USE_I18N`
- 3.10.4 `USE_TZ`
- 3.11 静态文件设置
- 3.12 默认主键字段类型设置
- F. 附:一个真实的初始配置文件
1. 概述
本文介绍了Django项目的整体结构,这仅仅是基本的Django项目结构,包括各个文件和目录的作用,以及如何通过Django项目的设置文件(settings.py)指定他们;然后全面介绍了一个初始的Django项目中settings.py文件各个配置项的功能和配置方法。
2. Django的项目结构
Django 项目结构是指一个典型的 Django 项目所包含的目录和文件组织方式,这种结构旨在提供一种清晰、可维护和可扩展的方式来组织项目代码和资源。
2.1 项目根目录(Project Root)
项目的顶层目录,通常是项目的名称。在这个目录下,您会找到项目的配置文件、顶级应用、静态文件、模板等。
manage.py
:Django 项目管理工具的入口文件,用于执行各种管理命令。myproject/
(项目名称):项目的 Python 包,也是项目的主目录。requirements.txt
:列出了项目所需的所有 Python 包的列表,通常使用pip
安装。
例如,以下是在控制台上输出的一个进行过数据库迁移(migrate)的项目的文件目录结构:
myproject
├── myproject
│ ├── __init__.py # 用于将 myproject 目录标识为 Python 包
│ ├── asgi.py # ASGI 应用程序入口点,用于支持异步 Web 服务器
│ ├── settings.py # 项目的主要设置文件,包括数据库配置、应用程序设置等。
│ ├── urls.py # URL 路由配置文件,定义了 URL 映射到视图函数的规则。
│ └── wsgi.py # 用于生产环境部署的 WSGI 应用程序入口点。
├── db.sqlite3 # SQLite 数据库文件,项目中的默认数据库。
└── manage.py # Django 项目管理工具,用于执行各种管理命令,如启动开发服务器、创建数据库迁移等。
注:我们一般在虚拟环境下安装当前Django项目所需要的依赖,开发完成后,再在该虚拟环境中导出本项目用到的包,而不是系统Python所使用的包。可以使用入下命令导出pip安装过的以来并写入名为
requirements.txt
的文本:pip freeze > \path\to\requirements.txt # 替换为你想保存requirements.txt文件的位置
当我们在新的环境中,需要一次性恢复该文本中的依赖时,可以运行以下命令:
pip install -r requirements.txt
不仅仅是Django项目,其它的Python项目也可以使用这种方式完成迁移。
2.2 应用目录(Apps)
一个 Django 项目可以包含多个应用,每个应用负责处理项目中的一个特定功能或模块。每个应用都有自己的目录结构,通常包括以下内容:
models.py
:定义应用的数据模型,包括数据库表的结构和字段。views.py
:定义应用的视图函数,处理 HTTP 请求和生成 HTTP 响应。urls.py
:定义应用的 URL 映射规则,将 URL 请求与视图函数关联起来。templates/
:存放应用的 HTML 模板文件,用于生成页面内容。static/
:存放应用的静态文件,如 CSS、JavaScript、图像等。- 其他自定义模块和资源文件。
2.3 配置文件
Django的项目的配置文件通常位于项目根目录同名子目录下的 settings.py
文件,用于配置项目的各种设置,包括数据库连接、静态文件路径、国际化设置等。
2.4 数据库迁移目录
包含了用于数据库迁移的文件,用于管理数据库模式的变化。每当您更改数据模型时,Django 会自动生成新的迁移文件,并可以使用 makemigrations
和 migrate
命令来应用这些变化。
2.5 静态文件目录
Django 的静态文件目录用于存放项目中使用的静态文件,包括 CSS 样式表、JavaScript 脚本、图像、字体等。这些静态文件通常不包含动态内容,而是用于渲染网页的外部资源。在 Django 中,您可以配置静态文件的存放位置和访问方式,以便在开发和生产环境中都能正确加载这些资源。
2.5.1 静态文件目录的配置
在 Django 项目的配置文件 settings.py
中,有一个名为 STATIC_URL
的设置,用于定义静态文件的 URL 路径。这是在生成 HTML 页面时引用静态文件的路径。
STATIC_URL = '/static/'
在默认的配置中,STATIC_URL
设置为 /static/
,这意味着所有静态文件的 URL 都以 /static/
开头。
2.5.2 应用中的静态文件
Django 应用程序通常包含一个名为 static
的目录,用于存放该应用的静态文件。这些文件按应用进行组织,每个应用都有自己的 static
目录,内部包含与该应用相关的静态资源。例如:
myapp/
├── static/
│ └── myapp/
│ ├── css/
│ │ └── style.css
│ ├── js/
│ │ └── script.js
│ └── img/
│ └── logo.png
上面的tree中,myapp
应用有一个与之关联的 static
目录,其中包含了 CSS、JavaScript 和图像文件。从后端的角度看,最常将一些第三方的js和css文件放在这些目录中,如bootstrap、jquery的相关文件。
2.5.3 加载静态文件
在 HTML 模板中,您可以使用 {% static %}
模板标签来加载静态文件。这个标签将根据 STATIC_URL
设置生成正确的 URL 路径。
<link rel="stylesheet" href="{% static 'myapp/css/style.css' %}">
<script src="{% static 'myapp/js/script.js' %}"></script>
<img src="{% static 'myapp/img/logo.png' %}" alt="Logo">
在上述示例中,{% static %}
标签将静态文件的相对路径转换为完整的 URL。
2.5.4 静态文件的收集
在生产环境中,Django 通常不会立即提供静态文件。相反,它会将这些文件收集到一个集中的位置,以提高性能。您可以使用以下命令来收集静态文件:
python manage.py collectstatic
这将把所有应用中的静态文件收集到一个指定的目录,通常是项目根目录下的 static/
目录。
2.5.5 静态文件的配置选项
Django 还提供了其他一些与静态文件相关的配置选项,例如:
-
STATIC_ROOT
:指定用于收集静态文件的根目录。默认情况下,它是项目根目录下的static/
目录。在生产环境中,通常需要将其设置为一个 Web 服务器可以访问的路径。 -
STATICFILES_DIRS
:一个包含要额外搜索的静态文件目录的列表。通常用于包含项目级别的静态文件,而不是应用级别的。
这些配置选项可以在 settings.py
中进行自定义设置,以满足项目的特定需求。
静态文件目录是 Django 项目中重要的一部分,它使开发人员能够有效地管理和提供静态资源,从而确保网站的外观和功能都正常工作。
2.6 模板目录(Templates)
模板目录 (Templates
) 在 Django 项目中起到了关键作用,它用于存放 HTML 模板文件,这些模板被用于生成网页内容。Django 的视图函数会根据请求选择合适的模板进行渲染,并将生成的 HTML 页面返回给用户。下面是关于模板目录的详细讲解,包括如何配置 Django 来查找和使用模板:
2.6.1 模板目录的配置
在 Django 项目的配置文件 settings.py
中,有一个名为 TEMPLATES
的设置,它是一个包含模板配置的列表。这个列表中的每个字典表示一个模板引擎的配置。通常,BACKEND
指定了模板引擎的后端,而 DIRS
则指定了模板文件所在的目录。
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [], # 在这里配置模板目录的路径
'APP_DIRS': True,
'OPTIONS': {
'context_processors': [
# ...
],
},
},
]
'DIRS'
:这是一个包含模板目录路径的列表。您可以在这里指定自定义的模板目录,Django 将在这些目录中查找模板文件。例如,如果您希望将模板文件存放在项目根目录下的templates/
文件夹中,可以配置为'DIRS': [BASE_DIR / 'templates']
。
2.6.2 APP_DIRS 选项
APP_DIRS
是模板配置中的一个选项,如果设置为 True
,Django 将会在每个已安装应用的目录下寻找名为 templates
的子目录,并将其加入模板搜索路径。这意味着每个应用可以有自己的模板目录,方便应用内组织模板。
2.6.3 模板文件的命名规则
Django 模板文件通常以 .html
为扩展名,但也可以使用其他扩展名。模板的命名通常与视图函数或模型相关联,以便更容易理解和管理。例如,如果有一个名为 blog
的应用,该应用中的文章列表页面模板可以命名为 article_list.html
。
2.6.4 模板继承
Django 的模板系统支持模板继承,这是一种将模板分解为多个可重用块的方式。通过 {% block %}
标签,您可以在基础模板中定义块,然后在子模板中重写这些块。这使得创建具有一致外观和布局的页面变得更加简单。以下是一个示例:
基础模板 base.html
:
<html>
<head>
<title>{% block title %}My Site{% endblock %}</title>
</head>
<body>
<div id="content">
{% block content %}{% endblock %}
</div>
</body>
</html>
子模板 article_list.html
:
{% extends "base.html" %}
{% block title %}Article List{% endblock %}
{% block content %}
<h1>Article List</h1>
<!-- 页面内容 -->
{% endblock %}
在上面的示例中,article_list.html
模板继承了 base.html
模板,并重写了 title
和 content
块。
2.6.5 模板标签和过滤器
Django 提供了丰富的模板标签和过滤器,用于在模板中执行逻辑和处理数据。标签用 {% %}
包裹,过滤器用 {{ }}
包裹。例如,您可以使用 {% for %}
标签循环遍历列表,使用 {{ value|filter }}
语法对变量进行过滤。
{% for article in articles %}
<h2>{{ article.title }}</h2>
<p>{{ article.content|linebreaks }}</p>
{% endfor %}
2.6.6 模板加载顺序
Django 模板系统按照一定的顺序查找模板文件,通常从最特定到最通用的顺序。首先,它查找应用目录下的模板,然后查找自定义目录(如果已配置),最后查找 Django 内置模板目录。
这些是关于 Django 模板目录的基本概念和配置。模板是 Django 中生成动态网页内容的关键部分,能够使您以更清晰和模块化的方式组织网页代码,提高开发效率和可维护性。
2.7 测试文件目录(Tests)
包含项目的测试文件,用于编写和运行单元测试和集成测试。
2.8虚拟隔离环境
Python 虚拟环境用于隔离项目的依赖项,可以在放在项目根目录下的 venv/
目录中。虚拟环境包含了项目所需的 Python 包,以确保项目的依赖不会与全局 Python 环境冲突。不过这不是强制性的,如果你喜欢,只要能够方便进入该虚拟隔离环境即可。
3. Django的配置文件settings.py
以下是对上述 Django 配置文件 settings.py
中各个部分的小节解析:
3.1 基础路径和文件生成
from pathlib import Path
BASE_DIR = Path(__file__).resolve().parent.parent
在这一部分,BASE_DIR
变量被设置为当前配置文件所在目录的上级目录,用于构建项目中的其他路径。
3.2 快速开始开发设置
SECRET_KEY = 'django-insecure-*a00ec65jkjd119ed=e3+1w)gjh15b)7@5hp1z1mh(o*ev&7tg'
DEBUG = True
ALLOWED_HOSTS = []
这里设置了项目的一些快速开发选项,包括密钥、调试模式和允许的主机。请注意,这些设置在生产环境中应该进行修改。
当分析 SECRET_KEY
、DEBUG
和 ALLOWED_HOSTS
这几个配置项时,我们可以详细解释它们的含义和在 Django 项目中的作用。
3.2.1 SECRET_KEY
设置
SECRET_KEY = 'django-insecure-*a00ec65jkjd119ed=e3+1w)gjh15b)7@5hp1z1mh(o*ev&7tg'
SECRET_KEY
是 Django 项目中非常重要的配置项,它用于加密和保护用户会话、密码等敏感数据。这个密钥是用于加密和解密数据的种子。
-
作用:
- 保护用户会话:
SECRET_KEY
用于签名和验证用户会话,以确保用户登录状态的安全性。 - 加密密码: 在存储和验证用户密码时,密钥用于加密和解密密码,以确保密码的机密性。
- 保护用户会话:
-
示例:
通常,SECRET_KEY
的值是一个随机生成的字符串,例如:SECRET_KEY = '2m_5#&^ihfw7z(b^^7+0^3wb*gj4%j4*#j%(9-ted-5q(^7p4z'
在生产环境中,不应将实际的密钥硬编码在配置文件中,而是从环境变量中加载,以增加安全性。
3.2.2 DEBUG
设置
DEBUG = True
DEBUG
配置项用于控制是否启用调试模式。在开发过程中,通常将其设置为 True
,以获得详细的错误信息和调试工具。在生产环境中,应将其设置为 False
,以减少安全风险。
-
作用:
- 调试模式: 当
DEBUG
设置为True
时,Django 将提供详细的错误页面、堆栈跟踪和调试信息,用于开发和调试应用程序。 - 安全性: 在生产环境中,将
DEBUG
设置为False
会减少错误信息的暴露,从而提高应用程序的安全性。
- 调试模式: 当
-
示例:
在开发阶段,可以将DEBUG
设置为True
,以便查看详细的错误信息。在生产中,应将其设置为False
,例如:DEBUG = False
3.2.3 ALLOWED_HOSTS
设置
ALLOWED_HOSTS = []
ALLOWED_HOSTS
配置项用于定义允许访问应用程序的主机列表。这是一个安全性配置,用于限制哪些主机可以连接到应用程序。
-
作用:
- 安全性: 通过设置
ALLOWED_HOSTS
,可以防止恶意主机的请求,从而提高应用程序的安全性。 - 配置多个域名: 可以将多个域名或 IP 地址添加到
ALLOWED_HOSTS
中,以允许多个主机访问应用程序。
- 安全性: 通过设置
-
示例:
在生产环境中,应该将实际的域名或 IP 地址添加到ALLOWED_HOSTS
中,例如:ALLOWED_HOSTS = ['example.com', 'www.example.com', '192.168.1.100']
这将允许
example.com
、www.example.com
和192.168.1.100
访问应用程序,而拒绝其他主机的请求。
总之,SECRET_KEY
、DEBUG
和 ALLOWED_HOSTS
都是 Django 项目中关键的配置项,它们直接影响着项目的安全性和行为。在生产环境中,务必谨慎地配置这些选项以确保应用程序的稳定性和安全性。
3.3 应用程序定义
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]
INSTALLED_APPS
列出了项目中安装的应用程序。这些应用程序包括了 Django 提供的一些内置应用,如管理界面、认证系统等。可以看到,在项目创建初,已经安装了一些默认的框架自带应用。
下面将对几个默认自带的应用进行简介。
3.3.1 django.contrib.admin
该应用提供了强大的管理后台界面,用于管理数据库中的数据和 Django 应用程序的配置。允许管理员用户轻松添加、修改和删除数据库记录。管理员可以登录到 /admin 路径,并使用该应用程序管理应用程序的数据库数据。
(如,http://127.0.0.1:8000/admin)
3.3.2 django.contrib.auth
该应用提供了用户认证和授权系统,包括用户注册、登录、密码重置、用户组等功能。允许管理用户、用户组和权限。用户可以注册账户,登录到应用程序,访问需要身份验证的视图。
3.3.3 django.contrib.contenttypes
该应用提供了内容类型框架,允许创建通用关系并查找模型之间的关联。可用于创建通用外键、反向关联和多态关联。允许模型之间建立关联,如评论模型可以关联到文章或图片模型。
3.3.4 django.contrib.sessions
该应用提供了会话管理功能,用于在 Web 应用程序中存储和检索用户会话数据。可用于实现用户登录状态的跟踪和管理。可以使用会话来存储购物车内容、用户首选项等数据。
3.3.5 django.contrib.messages
该应用提供了消息通知框架,用于向用户显示一次性消息,如成功、错误或信息消息。帮助用户获得有关他们的操作结果的反馈。可以在表单提交后向用户显示成功或错误消息。
3.3.6 django.contrib.staticfiles
该应用用于处理静态文件,如 CSS、JavaScript 和图像文件的收集和提供。管理应用程序中的静态资源,以便能够在模板中使用它们。
3.4 中间件设置
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
MIDDLEWARE
列表包含了在请求和响应处理期间执行的中间件。中间件用于执行不同的任务,例如安全性、会话管理、身份验证等。
3.5 URL 配置(指定跟路由文件)
ROOT_URLCONF = 'myproject.urls'
ROOT_URLCONF
设置用于定义项目中 URL 映射的模块。
3.6 模板配置
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',
],
},
},
]
TEMPLATES
列表配置了项目中模板引擎的选项,包括模板目录和上下文处理器。
3.7 WSGI 应用程序设置
WSGI_APPLICATION = 'myproject.wsgi.application'
WSGI_APPLICATION
设置用于定义项目的 WSGI 应用程序。
3.8 数据库配置
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
}
}
DATABASES
字典包含了项目数据库的配置选项,包括数据库引擎和数据库文件路径。
其中:
-
'BACKEND'
: 用于指定使用的模板引擎后端。比如,通常情况下,这应该设置为'django.template.backends.django.DjangoTemplates'
,因为 Django 自带了一个模板引擎后端。 -
'DIRS'
: 包含额外的模板目录路径列表。这些路径用于查找自定义模板文件。例如,如果有自定义模板存放在项目根目录下的templates
文件夹中,可以将路径添加到此列表中:'DIRS': [BASE_DIR / 'templates'],
-
'APP_DIRS'
: 指定是否要搜索应用程序中的模板目录。例如,设置为True
,以启用应用程序的模板目录搜索。 -
'OPTIONS'
: 包含其他模板引擎选项的字典。例如在'OPTIONS'
中,可以配置一些其他的选项,如下:'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', # 消息通知 ], 'builtins': [ 'myapp.template_tags.my_template_tag', # 自定义模板标签 ], },
-
'context_processors'
列表包含上下文处理器的名称,这些处理器可以向模板提供额外的上下文数据。例如,'django.contrib.auth.context_processors.auth'
将向模板提供已认证的用户信息。 -
'builtins'
包含要在模板中使用的内置标签和过滤器。如果有自定义的模板标签,可以将其添加到此列表中。
-
这些配置项使得能够自定义项目中的模板引擎行为,包括模板目录、上下文处理器和内置标签。根据项目的需求,可以灵活配置模板引擎以满足需求。
3.9 密码验证设置
AUTH_PASSWORD_VALIDATORS = [
{
'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
},
]
AUTH_PASSWORD_VALIDATORS
列表定义了密码验证策略,以确保用户密码的安全性。在上面的默认设置中:
-
'django.contrib.auth.password_validation.UserAttributeSimilarityValidator'
:
这个验证器用于检查密码是否与用户的属性过于相似。它会比较密码与用户的属性(例如用户名)的相似性,并根据设置的相似性要求来判断密码是否安全。 -
'django.contrib.auth.password_validation.MinimumLengthValidator'
:
此验证器检查密码的最小长度是否满足要求。可以在Django的设置中设置密码的最小长度要求。 -
'django.contrib.auth.password_validation.CommonPasswordValidator'
:
此验证器用于检查密码是否包含了常见的弱密码,如"password"或"123456"等。它会根据一组常见密码列表来检查密码的强度。 -
'django.contrib.auth.password_validation.NumericPasswordValidator'
:
这个验证器用于检查密码是否包含数字。它要求密码中必须包含至少一个数字字符。
通过将这些验证器添加到 AUTH_PASSWORD_VALIDATORS
列表中,Django 确保了密码的安全性,以防止用户使用过于简单或容易猜测的密码。这有助于提高系统的安全性,防止密码被恶意攻击或破解。可以根据项目的安全要求自定义这些验证器或添加其他自定义验证器。
3.10 国际化和时区设置
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_TZ = True
这些设置用于配置项目的国际化和时区。
下面是关于 Django 中国际化和时区设置项的解析,包括可以取的值以及每个值的含义:
3.10.1 LANGUAGE_CODE
是一个字符串,例如 'en-us'
, 'es-es'
等。
该设置指定了项目的默认语言和区域设置。它决定了在项目中使用的语言,以及如何格式化日期、时间和数字。
例如,'en-us'
表示美国英语,使用 'zh-hans'
表示中文简体,使用 'zh-hant'
表示中文繁体;使用'fr'
表示法语;使用'es-es'
表示西班牙语;使用'ru'
表示俄语;使用'fa'
表示波斯语;使用'ja'
表示日语;使用'ko'
表示韩语;使用'la'
表示拉丁语等等。
3.10.2 TIME_ZONE
是一个字符串,例如 'UTC'
, 'America/New_York'
等。
该设置指定了项目的默认时区。它影响到所有与日期和时间相关的操作,确保它们按照指定的时区进行计算和显示。例如,'UTC'
表示协调世界时,'America/New_York'
表示美国东部时间。
3.10.3 USE_I18N
是一个布尔值 (True
或 False
)。
该设置指示是否启用国际化。如果设置为 True
,Django 将尝试根据 LANGUAGE_CODE
配置来本地化项目内容,包括日期、时间和数字格式化。例如,True
表示启用国际化,False
表示禁用国际化。
3.10.4 USE_TZ
是一个布尔值 (True
或 False
)。
该设置指示是否启用时区支持。如果设置为 True
,Django 将使用 TIME_ZONE
配置来处理日期和时间,确保它们在指定的时区中正确显示和计算。例如,True
表示启用时区支持,False
表示禁用时区支持。
以上这些设置允许你自定义项目的国际化和时区,以确保应用在不同地区和语言环境下都能正确工作。根据的项目需求,可以根据上述说明来配置这些设置项。
3.11 静态文件设置
STATIC_URL = 'static/'
STATIC_URL
用于定义静态文件的 URL 路径。在Django中,静态文件通常包括CSS、JavaScript、图像和其他前端资源,它们被用于网站的样式和交互功能。它定义了静态文件在网站中的根URL路径。
例如,如果
STATIC_URL
设置为'static/'
,那么静态文件的URL
将以http://example.com/static/
开头。
通常情况下,STATIC_URL 的设置以斜杠结尾,以确保静态文件的URL路径正确。这是因为在Django中,静态文件的URL路径是相对于根URL的。
静态文件通常存储在项目的 static
目录中,STATIC_URL
指定了如何访问这些静态文件。
例如,如果有一个名为
style.css
的CSS文件位于static/css/
目录中,那么可以通过STATIC_URL
+'css/style.css'
来访问它。
使用 STATIC_URL 的好处是,当项目需要部署到不同的环境(开发、测试、生产等)时,只需更改 STATIC_URL 的设置,而不必修改模板中的静态文件路径。这样可以提高项目的可维护性和可移植性。
3.12 默认主键字段类型设置
DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'
DEFAULT_AUTO_FIELD
用于定义模型的默认主键字段类型。在 Django 3.2 版本以及之后的版本中才引入了这个设置,用于指定模型的默认主键字段类型。
DEFAULT_AUTO_FIELD
可以设置为多种不同的值,每个值对应不同的主键字段类型,以满足不同的项目需求。
-
'django.db.models.AutoField'
:
这是Django默认的主键字段类型。自动生成32位整数类型的主键值。适用于大多数小型到中型应用。 -
'django.db.models.BigAutoField'
:
自动生成64位整数类型的主键值。适用于处理大型数据集,避免主键值溢出。 -
'django.db.models.UUIDField'
:
使用UUID(Universally Unique Identifier)作为主键。生成全局唯一的主键值,适用于多个数据库之间数据合并或分布式系统。 -
自定义主键字段类型:
你还可以定义自己的自定义主键字段类型,并在DEFAULT_AUTO_FIELD
中引用它们。这需要你创建一个继承自models.Field
的自定义字段类。例如:# 自定义主键字段类型 from django.db import models class MyCustomPrimaryKey(models.Field): def db_type(self, connection): return 'my_custom_type' # 在 settings.py 中使用自定义主键字段类型 DEFAULT_AUTO_FIELD = 'myapp.models.MyCustomPrimaryKey' # myapp 表示 Django 项目中的一个应用(app)的名称。
这里,myapp 是一个虚拟的示例应用名称,您需要将其替换为实际项目中的应用名称。实际上,DEFAULT_AUTO_FIELD 设置需要引用包含自定义主键字段的应用和模型。这是因为自定义主键字段应该定义在项目的某个应用的模型中。所以,myapp.models.MyCustomPrimaryKey 中的 myapp 是应用的名称,models 是应用中包含自定义主键字段的 Python 模块,MyCustomPrimaryKey 是自定义主键字段的名称。也就是说,如果你的项目中真有一个名为 myapp 的应用,并且在该应用的 models.py 文件中定义了 MyCustomPrimaryKey 字段,那么您可以使用上述设置。否则,请将 myapp 替换为实际的应用名称,并确保自定义主键字段位于该应用中的模型中。
通过设置 DEFAULT_AUTO_FIELD
,可以选择适合项目需求的默认主键字段类型,以满足性能和数据管理方面的要求。不同的主键字段类型适用于不同的场景,可以根据项目的特点进行选择。
F. 附:一个真实的初始配置文件
"""
Django settings for myproject project.
Generated by 'django-admin startproject' using Django 4.2.5.
For more information on this file, see
https://docs.djangoproject.com/en/4.2/topics/settings/
For the full list of settings and their values, see
https://docs.djangoproject.com/en/4.2/ref/settings/
"""
from pathlib import Path
# Build paths inside the project like this: BASE_DIR / 'subdir'.
BASE_DIR = Path(__file__).resolve().parent.parent
# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/4.2/howto/deployment/checklist/
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'django-insecure-*a00ec65jkjd119ed=e3+1w)gjh15b)7@5hp1z1mh(o*ev&7tg'
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
ALLOWED_HOSTS = []
# Application definition
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
ROOT_URLCONF = 'myproject.urls'
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',
],
},
},
]
WSGI_APPLICATION = 'myproject.wsgi.application'
# Database
# https://docs.djangoproject.com/en/4.2/ref/settings/#databases
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
}
}
# Password validation
# https://docs.djangoproject.com/en/4.2/ref/settings/#auth-password-validators
AUTH_PASSWORD_VALIDATORS = [
{
'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
},
]
# Internationalization
# https://docs.djangoproject.com/en/4.2/topics/i18n/
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_TZ = True
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/4.2/howto/static-files/
STATIC_URL = 'static/'
# Default primary key field type
# https://docs.djangoproject.com/en/4.2/ref/settings/#default-auto-field
DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'