Django配置文件解析_[Django]Django配置文件

核心配置详解

1. BASE_DIR

在 Django 项目开发中，我们经常需要引用项目中的各种文件路径，比如：

静态文件目录（STATICFILES_DIRS）
模板目录（TEMPLATES）
媒体文件目录（MEDIA_ROOT）
数据库文件路径（DATABASES）

如果没有一个统一的基准路径，我们需要为每个配置项写完整的绝对路径，这不仅麻烦，而且在项目迁移时会导致路径错误。Django通过在配置文件setting.py中BASE_DIR来定义项目路径，方便进行路径的统一管理。

传统方式（os 模块）

# settings.py
import os
from pathlib import Path

# 传统方式（Django 3.1 之前常用）
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

解析这个路径计算过程：

__file__：当前文件（settings.py）的路径
os.path.abspath(__file__)：获取 settings.py 的绝对路径
os.path.dirname(...)第一次：获取 settings.py 所在目录（通常是项目名/目录）
os.path.dirname(...)第二次：获取项目的根目录

现代方式（pathlib，Django 3.1+ 推荐）

# settings.py
from pathlib import Path

# 现代方式（Django 3.1+ 默认）
BASE_DIR = Path(__file__).resolve().parent.parent

解析这个路径计算过程：

__file__：当前文件（settings.py）的路径，例如 settings.py 或 ./settings.py
Path(__file__)：将文件路径字符串转换为 Path 对象
.resolve()：将路径转换为绝对路径，并解析所有符号链接
例如：/home/user/projects/myproject/myproject/settings.py
.parent第一次：获取 settings.py 所在的目录（通常是项目名目录）
例如：/home/user/projects/myproject/myproject/
.parent第二次：获取项目的根目录
例如：/home/user/projects/myproject/ （这就是 BASE_DIR）

项目结构示例：

# 假设项目结构如下：
# /home/user/django_projects/
# └── myblog/                    <- BASE_DIR 指向这里
#     ├── manage.py
#     └── myblog/                <- 第一次 parent 到这里
#         ├── __init__.py
#         ├── settings.py        <- __file__ 指向这里
#         ├── urls.py
#         └── wsgi.py

# 在 settings.py 中：
from pathlib import Path

# 步骤演示
file_path = Path(__file__)              # settings.py (相对路径)
absolute_path = file_path.resolve()     # /home/user/django_projects/myblog/myblog/settings.py
first_parent = absolute_path.parent     # /home/user/django_projects/myblog/myblog
BASE_DIR = first_parent.parent          # /home/user/django_projects/myblog

# 一行代码完成：
BASE_DIR = Path(__file__).resolve().parent.parent

配置文件后面很多文件的路径（比如数据库、静态文件）都要基于这个“家”（BASE_DIR）来写，避免硬编码路径，项目搬到哪都能用。

具体示例：

静态文件配置

# 静态文件配置
STATIC_URL = '/static/'

# 使用 BASE_DIR 构建静态文件目录路径
STATICFILES_DIRS = [
    BASE_DIR / 'static',  # pathlib 方式
    # 或者 os.path.join(BASE_DIR, 'static'),  # os 方式
]

# 收集后的静态文件目录
STATIC_ROOT = BASE_DIR / 'staticfiles'

模板配置

# 模板配置
TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
            BASE_DIR / 'templates',  # 项目级模板目录
        ],
        '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',
            ],
        },
    },
]

媒体文件配置

# 媒体文件配置
MEDIA_URL = '/media/'
MEDIA_ROOT = BASE_DIR / 'media'

数据库配置（SQLite）

# 数据库配置
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

2. APP 路径组织

Django 默认使用 python manage.py startapp appname 创建的 app 会直接放在项目根目录下，这在小型项目中没问题，但在稍微复杂一点的项目中就会导致项目根目录下文件和文件夹过多，结构混乱。

因此在配置文件setting.py中重新设置一下app的目录很有必要。

sys.path.insert(0, os.path.join(BASE_DIR, 'apps'))

在Python中使用 import 语句时，Python 会按照 sys.path 列表中的顺序，依次在这些目录中查找模块。当在配置文件中添加这句代码后，Python就会在apps目录里查找相关app，如果没有写这个语句就要写完整的路径导入相关的app了。其中sys.path.insert(0, path)的意思是插入到路径列表的开头，这样做的优点是插入到最前面可以确保我们的 apps 目录被优先搜索，避免与系统包或其他第三方包冲突。

3. DEBUG

默认值是True。在本地开发测试环境下设置DEBUG=True可以显示bug信息，便于开发者找出代码错误所在。当你在部署项目在生产环境时，请切记设置DEBUG=False。这是因为生产环境下打开Debug一旦发生错误或异常会暴露很多敏感设置信息。

注意: 当你设置DEBUG=False, 你一定要设置ALLOWED_HOSTS选项, 否则会抛出异常。

① 作用范围

DEBUG=True（开发环境）

# settings.py
DEBUG = True

# DEBUG=True 时的行为：
# 1. 显示详细的错误页面（堆栈跟踪、局部变量、设置信息）
# 2. 自动重载代码（代码修改后自动生效）
# 3. 收集并显示 SQL 查询（在 HTTP 响应中）
# 4. 提供调试工具栏（需安装 django-debug-toolbar）
# 5. 允许所有主机访问（ALLOWED_HOSTS 可以为空）
# 6. 静态文件由 Django 自动服务（runserver）

错误页面示例：

TypeError at /api/users/
Cannot read properties of undefined (reading 'id')

Request Method: GET
Request URL: http://localhost:8000/api/users/
Django Version: 4.2
Exception Type: TypeError
Exception Value: Cannot read properties of undefined
Python Executable: /usr/bin/python3
Python Version: 3.9.5

Traceback (most recent call last):
  File "/path/to/views.py", line 25, in get_user
    user_id = request.data['id']
  ...

Local variables:
  request = <HttpRequest: GET /api/users/>
  user = None
  ...

DEBUG=False（生产环境）

# settings.py
DEBUG = False

# DEBUG=False 时的行为：
# 1. 显示自定义错误页面（500.html, 404.html）
# 2. 不泄露敏感的系统信息
# 3. 性能优化（不收集调试信息）
# 4. 必须设置 ALLOWED_HOSTS
# 5. 静态文件需要使用 collectstatic 收集
# 6. 不自动重载代码

错误页面示例：

<!-- 500.html -->
<!DOCTYPE html>
<html>
<head>
    <title>服务器错误</title>
</head>
<body>
    <h1>服务器错误</h1>
    <p>抱歉，服务器遇到了问题。请稍后再试。</p>
</body>
</html>

② 基础配置方式

方式一：直接设置（不推荐）

# settings.py - 开发环境
DEBUG = True
ALLOWED_HOSTS = []

# settings.py - 生产环境
DEBUG = False
ALLOWED_HOSTS = ['www.example.com', 'example.com']

问题：每次部署都要手动修改，容易出错。

方式二：环境变量控制（推荐）

# settings.py
import os
from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent.parent

# 从环境变量读取，默认为 False（安全优先）
DEBUG = os.environ.get('DEBUG', 'False') == 'True'

# 根据环境变量设置 ALLOWED_HOSTS
if DEBUG:
    # 开发环境允许所有主机
    ALLOWED_HOSTS = []
else:
    # 生产环境必须指定允许的主机
    ALLOWED_HOSTS = os.environ.get('ALLOWED_HOSTS', '').split(',')

使用方式：

# 开发环境
export DEBUG=True
python manage.py runserver

# 生产环境
export DEBUG=False
export ALLOWED_HOSTS=www.example.com,example.com
python manage.py runserver

4. ALLOWED_HOSTS

默认值为空[]。设置ALLOWED_HOSTS是为了限定用户请求中的host值，以防止黑客构造包来进行头部攻击。该选项正确设置方式如下:

DEBUG=True: ALLOWED_HOSTS可以为空，也可设置为[‘127.0.0.01’, ‘localhost’]
DEBUG=False: ALLOWED_HOSTS=[‘46.124.78.xx’, ‘www.bat.com’，’127.0.0.1’]

当你关闭DEBUG时，HOST一般为服务器公网IP或者注册域名。当你还需要使用子域名时，你可以用.bat.com。它将匹配bat.com, www.bat.com和news.bat.com。在正式部署项目时，请尽量不要设置ALLOWED_HOSTS=['*']。

5. SECRET_KEY

SECRET_KEY是Django根据自己算法生成的一大串随机数，本质是个加密盐，用于以下场景：

加密签名：CSRF token、Session cookie、Flash messages
密码管理：密码重置 token、账户激活链接
安全验证：各种安全相关的哈希和签名操作

重要：泄露 SECRET_KEY 会导致严重的安全问题，攻击者可以： - 伪造用户会话 - 绕过 CSRF 保护 - 生成有效的密码重置链接

生成SECRET_KEY

方法1：Django 自动生成（创建项目时）

# Django 在创建项目时会自动生成一个 SECRET_KEY
django-admin startproject myproject

方法2：使用 Python 生成

# 方法 2.1：使用 secrets 模块（推荐，Python 3.6+）
import secrets
secret_key = secrets.token_urlsafe(50)
print(secret_key)

# 方法 2.2：使用 django.core.management
from django.core.management.utils import get_random_secret_key
secret_key = get_random_secret_key()
print(secret_key)

# 方法 2.3：使用 random（不推荐）
import random
import string
chars = string.ascii_letters + string.digits + string.punctuation
secret_key = ''.join(random.choice(chars) for _ in range(50))

配置方式

方式1：硬编码（仅限开发环境）

# settings.py - 开发环境
SECRET_KEY = 'django-insecure-your-development-key-here'

方式2：环境变量读取

import os
SECRET_KEY = os.environ.get('SECRET_KEY')

方式3：从项目文件价外的某个文件读取

with open('/etc/secret_key.txt') as f:
    SECRET_KEY = f.read().strip()

6. CSRF_TRUSTED_ORIGINS

CSRF_TRUSTED_ORIGINS 是 Django 3.2+ 引入的配置，用于指定哪些域名可以通过跨站请求访问你的 Django 应用。

作用：防止 CSRF（跨站请求伪造）攻击，同时允许合法的跨域请求。

为什么需要它

当你的前端和后端部署在不同域名或端口时，例如： - 前端：https://www.example.com - 后端：https://api.example.com - 开发环境：http://localhost:3000 → http://localhost:8000

Django 会拦截这些跨域的 POST/PUT/DELETE 请求，报错：

Forbidden (403)
CSRF verification failed. Request aborted.
Reason given for failure:
Origin checking failed - https://www.example.com does not match any trusted origins.

开发环境配置

# settings.py
CSRF_TRUSTED_ORIGINS = [
    'http://localhost:3000',  # React/Vue 开发服务器
    'http://localhost:8080',  # 其他前端开发服务器
    'http://127.0.0.1:3000',
    'http://127.0.0.1:8080',
]

生产环境配置

# settings.py
CSRF_TRUSTED_ORIGINS = [
    'https://example.com',
    'https://www.example.com',
    'https://app.example.com',
]

重要规则

必须包含协议

# ❌ 错误 - 缺少协议
CSRF_TRUSTED_ORIGINS = ['example.com']

# ✅ 正确 - 包含协议
CSRF_TRUSTED_ORIGINS = ['https://example.com']

不要包含端口号（除非非标准端口）

# ✅ 标准 HTTPS 端口（443）- 不需要端口号
CSRF_TRUSTED_ORIGINS = ['https://example.com']

# ✅ 标准 HTTP 端口（80）- 不需要端口号
CSRF_TRUSTED_ORIGINS = ['http://example.com']

# ✅ 非标准端口 - 需要包含端口号
CSRF_TRUSTED_ORIGINS = [
    'http://localhost:3000',
    'https://example.com:8443',
]

域名要精确匹配

# ❌ 不会匹配 www.example.com
CSRF_TRUSTED_ORIGINS = ['https://example.com']

# ✅ 需要分别列出
CSRF_TRUSTED_ORIGINS = [
    'https://example.com',
    'https://www.example.com',
]

7. INSTALLED_APPS

这个设置比较简单，也比较常用，用于增删一个项目(Project)所包含的应用(APP)。只有对列入此项的APP, Django才会生成相应的数据表。

INSTALLED_APPS = [
    'django.contrib.admin',      # 后台管理
    'django.contrib.auth',       # 用户登录注册
    'django.contrib.sessions',   # 记住用户登录状态
    'django.contrib.messages',   # 提示消息（如“登录成功”）
    'django.contrib.staticfiles',# 管理CSS/JS等静态文件
    'myapp',                     # 你自己写的App
]

如何添加自己的App？

python manage.py startapp blog

然后在 INSTALLED_APPS 中加上 'blog', 注意如果不加，django是无法识别到这个app的。

8. AUTH_USER_MODEL

AUTH_USER_MODEL 指定 Django 项目使用哪个模型作为用户模型。

# Django 默认配置
AUTH_USER_MODEL = 'auth.User'

为什么需要自定义用户模型？

Django 默认 User 模型的限制

# Django 内置的 User 模型字段
class User(AbstractBaseUser):
    username        # 用户名（必须，唯一）
    password        # 密码
    email           # 邮箱（可选）
    first_name      # 名（可选）
    last_name       # 姓（可选）
    is_staff        # 是否员工
    is_active       # 是否激活
    is_superuser    # 是否超级用户
    last_login      # 最后登录时间
    date_joined     # 注册时间

问题： - 必须使用 username 字段（不能用邮箱登录）

字段固定，无法添加自定义字段（如手机号、头像等）
删除字段困难

自定义用户模型

方式 1：继承 AbstractUser（推荐）

保留默认字段，添加额外字段

# apps/users/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    """自定义用户模型"""
    phone = models.CharField('手机号', max_length=11, blank=True)
    avatar = models.ImageField('头像', upload_to='avatars/', blank=True)
    nickname = models.CharField('昵称', max_length=50, blank=True)

    class Meta:
        verbose_name = '用户'
        verbose_name_plural = verbose_name

    def __str__(self):
        return self.username

# settings.py
AUTH_USER_MODEL = 'users.CustomUser'

特点：

✅ 保留所有默认字段（username, email, first_name, last_name 等）
✅ 可以添加新字段
✅ 可以修改字段的验证逻辑
❌ 仍然需要 username 字段

方法 2：继承 AbstractBaseUser（完全自定义）

完全自定义到现在没用过，后面弄懂了，再加这部分内容。

9. STATIC_ROOT、STATIC_URL和STATICFILES_DIRS

这两个选项是关于静态文件(如CSS, JS,和图片)的最重要的设置，一般设置如下。STATIC_URL是静态文件URL，设置后可以通过使用{% static 'assets/imges/xxx.jpg' %}方式直接访问/static/文件夹里的静态文件。如果你设置了STATIC_ROOT, 当你运行python manage.py collectstatic命令的时候，Django会将各app下所有名为static的文件夹及其子目录复制收集到STATIC_ROOT。把静态文件集中一起的目的是为了更方便地通过Apache或Nginx部署。

STATIC_ROOT和STATIC_URL核心区别

配置	类型	作用	生产环境必须	开发环境使用
`STATIC_URL`	URL 路径	浏览器访问路径	✅	✅
`STATIC_ROOT`	文件路径	静态文件收集目录	✅	❌

① 开发环境（DEBUG=True）

# settings/development.py
DEBUG = True

# URL 访问路径
STATIC_URL = '/static/'

# 开发环境不需要 STATIC_ROOT
# Django 会自动服务静态文件
# STATIC_ROOT = ...  # 不需要配置

工作原理： - Django 自动在 INSTALLED_APPS 中查找每个 app 的 static/ 目录 - 自动服务静态文件（通过 runserver） - 不需要运行 collectstatic

② 生产环境（DEBUG=False）

# settings/production.py
DEBUG = False

# URL 访问路径
STATIC_URL = '/static/'

# 静态文件收集目录
STATIC_ROOT = BASE_DIR / 'staticfiles'

# 额外的静态文件目录（非 app 内的静态文件）
STATICFILES_DIRS = [
    BASE_DIR / 'static',
]

注意到配置文件中有一个STATICFILES_DIRS, 在整个项目中我们可能会设置一些全局的js、css或者图片，这些目录需要STATICFILES_DIRS告诉django它们的位置。默认值为空。当你设置该选项后，python manage.py collectstatic命令会把static文件夹及静态文件目录STATICFILES_DIRS里的静态文件都复制到一份到STATIC_ROOT。比如下例中Django会将下面两个文件夹内容也复制到STATIC_ROOT。注意里面的路径必需是绝对路径哦。

工作原理：

运行 python manage.py collectstatic
Django 把所有静态文件复制到 STATIC_ROOT
Nginx直接服务 STATIC_ROOT 目录，就不需要在nginx配置文件写各个app下面静态文件目录了
Django 不再处理静态文件请求

项目整体结构

myproject/
├── manage.py
├── static/              # 项目级静态文件
│   ├── css/
│   │   └── global.css
│   └── js/
│       └── common.js
├── staticfiles/         # collectstatic 的目标目录（生产环境）
│   ├── admin/
│   ├── app1/
│   ├── app2/
│   └── css/
│       └── global.css
├── apps/
│   ├── blog/
│   │   └── static/      # app 级静态文件
│   │       └── blog/
│   │           └── css/
│   │               └── style.css
│   └── shop/
│       └── static/
│           └── shop/
│               └── js/
│                   └── cart.js
└── myproject/
    └── settings.py

collectstatic 命令

基本用法

# 收集所有静态文件到 STATIC_ROOT
python manage.py collectstatic

# 输出示例：
# 130 static files copied to '/path/to/project/staticfiles'.

常用选项

# 清空目标目录后再收集
python manage.py collectstatic --clear

# 不提示确认，直接执行
python manage.py collectstatic --noinput

# 忽略某些应用
python manage.py collectstatic --ignore app1 --ignore app2

# 干运行（只显示会做什么，不实际执行）
python manage.py collectstatic --dry-run

# 组合使用
python manage.py collectstatic --clear --noinput

执行流程

# 1. 查找所有静态文件
# - 每个 app 的 static/ 目录
# - STATICFILES_DIRS 中的目录

# 2. 复制到 STATIC_ROOT
# apps/blog/static/blog/css/style.css → staticfiles/blog/css/style.css
# static/css/global.css → staticfiles/css/global.css

# 3. Nginx 配置指向 STATIC_ROOT

模板中使用

app里的原模版

<!-- templates/base.html -->
{% load static %}

<!DOCTYPE html>
<html>
<head>
    <!-- CSS 文件 -->
    <link rel="stylesheet" href="{% static 'css/global.css' %}">

    <!-- app 内的静态文件 -->
    <link rel="stylesheet" href="{% static 'blog/css/style.css' %}">
</head>
<body>
    <!-- JavaScript 文件 -->
    <script src="{% static 'js/common.js' %}"></script>

    <!-- 图片 -->
    <img src="{% static 'images/logo.png' %}" alt="Logo">
</body>
</html>

collectstatic 命令生成的 HTML

<!-- 开发环境（DEBUG=True） -->
<link rel="stylesheet" href="/static/css/global.css">
<script src="/static/js/common.js"></script>

<!-- 生产环境（DEBUG=False） -->
<link rel="stylesheet" href="/static/css/global.css">
<script src="/static/js/common.js"></script>

10. MEDIA_ROOT和MEDIA_URL

media文件夹一般用于放置用户上传的文件。对于此文件夹的权限设置异常重要，因为用户可能会上传可执行的文件，影响网站和服务器的安全。对于此文件夹权限，建议使用sudo chmod 755 media命令设置成755，而不要使用777（可读、可写、可执行)。

MEDIA_URL = '/media/'
MEDIA_ROOT = os.path.join(BASE_DIR, 'media')

11. 国际化(语言与时间)

USE_TZ = True # 默认值True。
TIME_ZONE = 'Asia/Shanghai' # 设置时区
USE_I18N = True # 默认为True，是否启用自动翻译系统
USE_L10N = True # 默认False，以本地化格式显示数字和时间

12. 模板设置

如果你在根目录下建立了一个templates文件夹，专门用于存放属于项目的模板文件，你还需要在settings.py中显示地将模板目录设置为BASE_DIR目录下的templates文件夹。

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [os.path.join(BASE_DIR, 'templates')], # 设置项目模板目录
        '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',
            ],
        },
    },
]

13. DATABASES

Django默认使用轻量级的SQLite数据库，无需进行任何设置开箱即用。如果想要使用MySQL或则postgreSQL，需要先在本地或服务器上安装MySQL或postgreSQL，创建数据库和用户并授权，然后再修改配置文件。

不建议在settings.py直接写入数据库密码，而是采取读取外部配置文件的方式，更安全。下面以MYSQL和SQLite为例介绍了基本配置方式。

# MYSQL
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',   # 数据库引擎
        'NAME': 'mydb',         # 你要存储数据的库名，事先要创建之
        'USER': 'xxs',         # 数据库用户名
        'PASSWORD': 'xxxx',     # 密码
        'HOST': 'localhost',    # 主机
        'PORT': '3306',         # 数据库使用的端口
    }
}

# SQLite
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

总结

本文详细介绍了 Django settings.py 配置文件中的 13 个核心配置项。下面用表格的方式快速回顾每个配置的作用和要点：

配置项总览表

配置项	作用	默认值	开发环境示例	生产环境要点
BASE_DIR	项目根目录路径	无	`Path(__file__).resolve().parent.parent`	必须设置，所有路径的基准
APP路径	自定义 app 目录	无	`sys.path.insert(0, os.path.join(BASE_DIR, 'apps'))`	可选，统一管理 app
DEBUG	调试模式开关	`True`	`True`	必须设为 `False`
ALLOWED_HOSTS	允许访问的域名	`[]`	`['localhost', '127.0.0.1']`	必须设置实际域名
SECRET_KEY	密钥，用于加密签名	无	可硬编码	必须保密，用环境变量
CSRF_TRUSTED_ORIGINS	信任的跨域请求来源	`[]`	`['http://localhost:3000']`	设置实际前端域名
INSTALLED_APPS	已安装的应用列表	Django 内置应用	添加自定义 app	包含所有需要的 app
AUTH_USER_MODEL	用户模型	`'auth.User'`	默认即可	自定义时设置 `'app.CustomUser'`
STATIC_URL	静态文件 URL 前缀	`'/static/'`	`'/static/'`	`'/static/'` 或 CDN 域名
STATIC_ROOT	静态文件收集目录	无	不需要	必须设置，用于 collectstatic
STATICFILES_DIRS	额外静态文件目录	`[]`	`[BASE_DIR / 'static']`	项目级静态文件目录
MEDIA_URL	媒体文件 URL 前缀	无	`'/media/'`	`'/media/'`
MEDIA_ROOT	媒体文件存储路径	无	`BASE_DIR / 'media'`	用户上传文件目录
TIME_ZONE	时区设置	`'UTC'`	`'Asia/Shanghai'`	`'Asia/Shanghai'`
USE_I18N	启用国际化	`True`	`True`	根据需求设置
DATABASES	数据库配置	SQLite	SQLite 或 MySQL	PostgreSQL 推荐

配置分类

🏠 基础配置（必须设置）

BASE_DIR、DEBUG、ALLOWED_HOSTS、SECRET_KEY、INSTALLED_APPS、DATABASES

📁 静态文件配置

STATIC_URL、STATIC_ROOT、STATICFILES_DIRS、MEDIA_URL、MEDIA_ROOT

🔐 安全与认证配置

CSRF_TRUSTED_ORIGINS、AUTH_USER_MODEL

🌍 国际化配置

TIME_ZONE、USE_I18N、USE_L10N、USE_TZ

开发 vs 生产环境对照表

配置项	开发环境	生产环境
DEBUG	✅ True	❌ False
ALLOWED_HOSTS	`[]` 或 `['localhost']`	必须设置域名
SECRET_KEY	可硬编码	必须用环境变量
STATIC_ROOT	不需要	必须设置
DATABASES	SQLite	PostgreSQL/MySQL
collectstatic	不需要执行	必须执行

常见踩坑清单

问题	原因	解决方案
500 错误页面暴露敏感信息	DEBUG=True	生产环境设置 `DEBUG=False`
DisallowedHost 错误	ALLOWED_HOSTS 未设置	设置允许的域名
CSRF verification failed	跨域未配置	配置 CSRF_TRUSTED_ORIGINS
静态文件 404	未运行 collectstatic	执行 `python manage.py collectstatic`
用户登录失败	SECRET_KEY 泄露或变更	重新生成并妥善保管

说明：本文目前只涵盖了 Django 常用配置中的一部分。由于个人经验和理解的限制，还有很多重要配置（如 MIDDLEWARE、CACHES、EMAIL_BACKEND、LOGGING、CORS 等）暂时没有涉及到。这些配置我目前还不是很了解，会在后续的学习和实践中逐步补充完善。

如果你需要了解更多配置，建议参考： - Django 官方文档 - Settings - Django 部署检查清单

版权声明：如无特殊说明，文章均为本站原创，转载请注明出处

本文链接：http://example.com/subject/article/django_setting/

许可协议：署名-非商业性使用 4.0 国际许可协议