简介本资源是William S. Vincent所著《Django for Professionals》中文版PDF电子书面向具备Python基础、正从Django入门迈向生产级开发的中高级Web开发者。全书系统讲解如何构建可部署、高安全、易维护的专业网站覆盖Docker容器化部署、PostgreSQL生产数据库集成、自定义用户模型与邮箱验证认证流程、全面测试策略单元/模板/HTML、环境变量管理、静态资源优化及Django Crispy Forms等关键实践。资源为1个25.89MB的PDF文件内容结构清晰含7大核心章节从Docker起步到用户注册进阶每章均配实操代码、Git管理建议与测试范例便于边学边练。目前已有61人学习下载适合希望摆脱玩具项目、掌握Django社区主流生产规范的工程师系统精读与工程复用。1. Django生产级网站不是“跑起来就行”DockerPostgreSQL自定义用户模型三道坎跨不过去就别谈上线你用django-admin startproject建过项目也写过几个ListView和ModelForm本地runserver跑得飞起——但真要部署到服务器上第二天就被运维叫去查日志数据库连接超时、静态文件404、用户注册邮件发不出、DEBUGTrue被扫出来一堆敏感路径……这不是玄学是《Django for Professionals》开篇就点破的现实生产级网站和玩具项目的分水岭不在功能多寡而在环境隔离性、数据持久性、身份可信性这三根支柱是否立得住。这本书不是教你怎么写视图而是手把手带你把Docker容器当开发沙盒、把PostgreSQL当唯一数据源、把AbstractBaseUser当用户系统地基——每一步都卡在真实部署场景的痛点上。适合谁适合已经能写CRUD但一碰ALLOWED_HOSTS就懵、看到psycopg2.OperationalError就重启服务器、改个SECRET_KEY还得翻Git历史找旧值的中级开发者。如果你正卡在“本地能跑线上报错功能完整不敢上线”的临界点这篇安装笔记就是为你写的血泪经验复盘。2. Docker环境搭建从Hello World到Django容器化版本选错直接翻车Docker不是锦上添花的工具而是这本书所有后续章节PostgreSQL、环境变量、静态文件收集的运行底座。它解决的核心问题是让开发、测试、预发布、生产四套环境共享同一套镜像定义彻底消灭“在我机器上是好的”这类黑匣子问题。书中第1章明确要求使用Docker DesktopmacOS/Windows或Docker EngineLinux而非Docker Toolbox等已淘汰方案。我们按2024年稳定实践来落地。2.1 安装Docker避开ARM64与旧版兼容性陷阱提示Mac M系列芯片用户务必确认安装的是Docker Desktop for Mac (Apple Silicon)版本而非Intel版。后者在运行postgres:15-alpine镜像时会因架构不匹配导致容器启动失败报错类似exec /bin/sh: exec format error。macOSApple Silicon下载地址https://desktop.docker.com/mac/main/arm64/Docker.dmg安装后打开Docker Desktop等待右上角鲸鱼图标变蓝终端执行docker --version # 输出应为Docker version 24.0.7, build afdd53b docker run hello-world # 成功输出Hello from Docker!即通过Ubuntu 22.04 LTS推荐用官方仓库安装避免snap包带来的权限和路径问题# 卸载可能存在的旧版 sudo apt remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt update sudo apt install -y \ ca-certificates \ curl \ gnupg \ lsb-release # 添加Docker官方GPG密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加稳定版仓库 echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update # 安装Docker Engine sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 将当前用户加入docker组免sudo sudo usermod -aG docker $USER # 重启shell或执行newgrp dockerWindows 11WSL2必须启用WSL2并安装Ubuntu 22.04发行版非Debian或Alpine再在WSL内执行上述Ubuntu安装步骤。严禁在Windows原生CMD/PowerShell中直接安装Docker Desktop——会导致docker-compose无法正确挂载Windows路径到容器内后续manage.py migrate必报错。2.2 构建第一个Django容器Dockerfile详解与常见参数取舍书中第1章的Django Hello, World不是简单docker run python:3.11-slim django-admin startproject而是要求你手写Dockerfile这是生产级思维的第一课。以下是本书配套实践的最小可行Dockerfile基于Python 3.11 Django 4.2 LTS# 使用官方Python基础镜像slim版不含编译工具体积小、攻击面小 FROM python:3.11-slim # 设置工作目录必须与后续volume挂载路径一致 WORKDIR /app # 复制requirements.txt优先利用Docker layer缓存 COPY requirements.txt . # 安装Python依赖-q静默--no-cache-dir避免镜像膨胀 RUN pip install -q --no-cache-dir -r requirements.txt # 复制项目源码此时才复制避免每次改代码都重装pip包 COPY . . # 暴露端口仅声明不实际绑定由docker run -p控制 EXPOSE 8000 # 启动命令使用gunicorn替代runserver符合生产规范 CMD [gunicorn, --bind, 0.0.0.0:8000, --workers, 4, mysite.wsgi:application]关键参数说明python:3.11-slim不选alpine。虽然体积更小但psycopg2在Alpine上需额外编译gcc和postgresql-dev极易因musl libc兼容性导致ImportError: libpq.so.5。slim基于Debian预编译wheel支持完美。--no-cache-dirDocker构建层不可变pip缓存无意义且增大镜像。gunicornrunserver仅用于开发生产必须用WSGI服务器。本书第16章性能优化会深入对比gunicorn/uwsgi。2.3 docker-compose.yml定义服务拓扑让Django和PostgreSQL“说同一种语言”单靠Dockerfile只能跑Django但生产环境必然需要数据库。docker-compose.yml是本书第2章的核心它把Django、PostgreSQL、Nginx后续章节组织成可协同工作的服务网络# docker-compose.yml version: 3.9 services: # Django应用服务 web: build: . command: python manage.py runserver 0.0.0.0:8000 volumes: - .:/app # 本地代码实时映射到容器 ports: - 8000:8000 environment: - DEBUG1 - SECRET_KEYdjango-insecure-xxx # 开发临时密钥 - DATABASE_URLpostgresql://postgres:postgresdb:5432/postgres depends_on: - db # 关键与db服务在同一自定义网络DNS解析可用 networks: - django-net # PostgreSQL数据库服务 db: image: postgres:15-alpine restart: always environment: - POSTGRES_DBpostgres - POSTGRES_USERpostgres - POSTGRES_PASSWORDpostgres volumes: - postgres_data:/var/lib/postgresql/data/ # 持久化数据卷 networks: - django-net # 自定义网络确保服务间DNS可达web可ping通db networks: django-net: driver: bridge # 持久化数据卷独立于容器生命周期 volumes: postgres_data:为什么必须用depends_onnetworks因为Django启动时会立即尝试连接数据库。若无此配置web服务常因db未就绪而崩溃退出。depends_on仅控制启动顺序真正的健康检查需配合healthcheck本书第8章环境变量后补充。2.4 避坑Docker常见问题排查现象→原因→解决现象docker-compose up后web容器反复重启日志显示django.db.utils.OperationalError: could not connect to server: Connection refused原因web服务启动快于db初始化完成PostgreSQL首次启动需初始化数据目录耗时5~10秒。depends_on不检查服务内部健康状态。解决在web服务中添加启动前等待脚本。创建wait-for-db.sh#!/bin/sh while ! nc -z db 5432; do sleep 1 done修改docker-compose.yml中web.command为sh -c sh wait-for-db.sh python manage.py runserver 0.0.0.0:8000现象Mac上docker-compose up后浏览器访问http://localhost:8000空白Django日志无输出原因Docker Desktop for Mac的文件系统挂载机制导致/app目录权限异常manage.py无法读取settings.py。解决在docker-compose.yml的web.volumes下添加权限修正volumes: - .:/app:cached # macOS必须加:cached提升性能并修复权限现象Ubuntu上执行docker run hello-world报错Cannot connect to the Docker daemon原因Docker服务未启动或当前用户未加入docker组。解决sudo systemctl start docker sudo systemctl enable docker # 开机自启 sudo usermod -aG docker $USER # 退出终端重登或执行newgrp docker现象docker-compose build卡在Step 4/6 : RUN pip install ...长时间无响应原因国内网络访问PyPI超时。解决在Dockerfile的RUN pip install前添加清华源RUN pip install -q --no-cache-dir -i https://pypi.tuna.tsinghua.edu.cn/simple/ -r requirements.txt3. PostgreSQL集成不只是换数据库而是重构Django的数据契约Django默认SQLite虽方便但生产环境必须用PostgreSQL——这不是性能焦虑而是数据完整性、并发控制、JSONB字段、全文检索等能力的硬性门槛。本书第2章强调PostgreSQL不是Django的“插件”而是整个数据层的契约制定者。从psycopg2驱动安装到DATABASE_URL解析每一步都在重塑Django与数据的对话方式。3.1 安装psycopg2-binary绕过编译地狱的务实选择psycopg2是Python连接PostgreSQL的官方驱动但源码编译需libpq-dev、python3-dev等系统依赖极易因版本不匹配失败。本书明确推荐psycopg2-binary第2章P41这是官方提供的预编译wheel包省去所有编译环节# requirements.txt 中写入注意-binary后缀不可省略 psycopg2-binary2.9.7提示psycopg2-binary在开发/测试环境完全安全。生产环境若对二进制包有审计要求可切换回源码版但需在Dockerfile中显式安装依赖RUN apt-get update apt-get install -y \ libpq-dev \ python3-dev \ rm -rf /var/lib/apt/lists/* RUN pip install psycopg22.9.73.2 配置Django数据库从settings.py到DATABASE_URL的演进书中第2章P39的Settings部分核心是教会你用环境变量驱动数据库配置而非硬编码。这是生产安全的基石SECRET_KEY、数据库密码绝不进Git。以下是本书推荐的settings/base.py数据库配置模式# mysite/settings/base.py import dj_database_url # 需安装 django-heroku 或单独 pip install dj-database-url # 从环境变量 DATABASE_URL 解析格式postgres://user:passhost:port/dbname DATABASES { default: dj_database_url.config( defaultsqlite:///db.sqlite3, # 开发兜底 conn_max_age600, # 连接池最大存活时间秒 ssl_requireFalse # 生产环境设为True见第17章安全 ) }dj_database_url的作用是将字符串postgres://postgres:postgresdb:5432/postgres自动转换为Django所需的字典结构无需手动拆解URL。其conn_max_age600参数至关重要——它启用连接池复用避免高并发下频繁创建/销毁数据库连接这是本书第16章性能优化的前提。3.3 初始化数据库migrate、createsuperuser与Docker Volume持久化验证Docker容器删除后若数据未持久化migrate结果将丢失。本书第2章P43的New Database强调postgres_data卷是数据的生命线。验证步骤如下# 1. 启动服务首次会初始化postgres_data卷 docker-compose up -d db # 2. 进入db容器验证数据库存在 docker-compose exec db psql -U postgres -c \l # 应看到名为postgres的数据库 # 3. 启动web服务并执行migrate docker-compose up -d web docker-compose exec web python manage.py migrate # 4. 创建超级用户密码输入两次 docker-compose exec web python manage.py createsuperuser # 5. 验证数据持久化停止并删除容器 docker-compose down # 6. 重新启动检查migrate记录和superuser是否还在 docker-compose up -d docker-compose exec web python manage.py showmigrations # 所有migration应显示 [X]已应用 docker-compose exec web python manage.py shell -c from django.contrib.auth import get_user_model; print(get_user_model().objects.count()) # 应输出 1即刚才创建的superuser若第6步showmigrations显示全为[ ]说明postgres_data卷未生效——检查docker-compose.yml中db.volumes路径是否拼写错误如/var/lib/postgresql/data/末尾斜杠缺失。3.4 避坑PostgreSQL连接与权限的典型故障现象→原因→解决现象docker-compose exec web python manage.py migrate报错django.db.utils.OperationalError: FATAL: password authentication failed for user postgres原因db服务的POSTGRES_PASSWORD环境变量与DATABASE_URL中的密码不一致。Docker Compose中environment变量作用域仅限该服务web服务里的DATABASE_URL必须与db的密码严格匹配。解决统一在.env文件中定义docker-compose.yml引用# .env 文件 POSTGRES_PASSWORDmysecretpassword DATABASE_URLpostgresql://postgres:mysecretpassworddb:5432/postgres# docker-compose.yml services: db: environment: - POSTGRES_PASSWORD${POSTGRES_PASSWORD} web: environment: - DATABASE_URL${DATABASE_URL}现象psql -U postgres -h localhost在宿主机可连但在web容器内psql -U postgres -h db连不上原因db服务暴露的端口是5432但Docker网络中服务名db解析为容器IP-h db正确而宿主机localhost指向本机非容器网络。解决永远在容器内用服务名db而非localhost连接其他服务。这是Docker网络设计原则也是本书所有配置的基石。现象migrate成功但Django Admin登录时提示relation auth_user does not exist原因migrate未应用auth、contenttypes等Django内置app的migration。解决检查INSTALLED_APPS是否包含django.contrib.auth等默认Django项目已包含但若手动删减过需补全。现象PostgreSQL容器日志刷屏LOG: incomplete startup packet原因Django应用频繁建立短连接如未配置连接池或健康检查探针配置不当。解决在docker-compose.yml中为db服务添加健康检查并确保Django配置CONN_MAX_AGEdb: healthcheck: test: [CMD-SHELL, pg_isready -U postgres -d postgres] interval: 30s timeout: 10s retries: 54. 自定义用户模型从AbstractUser到AbstractBaseUser为什么必须重写Django默认的User模型django.contrib.auth.models.User为快速开发而生但生产网站几乎必然要扩展邮箱作为唯一登录凭证、手机号验证、用户角色分级、头像存储路径……本书第3章P54直击要害不重写用户模型等于把用户数据的主权拱手交给框架后续所有认证、权限、Profile扩展都将陷入打补丁的泥潭。这不是过度设计而是技术债的止损点。4.1 选择AbstractBaseUser还是AbstractUser一个影响三年的决定AbstractUser继承AbstractBaseUserPermissionsMixin自带username、first_name、last_name、email、is_staff等字段。适合只需扩展字段如加phone_number、保留用户名登录的场景。AbstractBaseUser仅提供密码哈希、token生成等核心认证逻辑所有字段包括邮箱、姓名需自行定义。本书第3章采用此方案因其强制你思考用户标识到底是什么是邮箱手机号还是第三方ID这是生产级身份设计的起点。本书实践选择AbstractBaseUser创建users/models.py# users/models.py from django.contrib.auth.models import AbstractBaseUser, BaseUserManager, PermissionsMixin from django.db import models class UserManager(BaseUserManager): 自定义用户管理器覆盖create_user和create_superuser def create_user(self, email, passwordNone, **extra_fields): if not email: raise ValueError(Email is required) email self.normalize_email(email) user self.model(emailemail, **extra_fields) user.set_password(password) # 加密存储 user.save(usingself._db) return user def create_superuser(self, email, passwordNone, **extra_fields): extra_fields.setdefault(is_staff, True) extra_fields.setdefault(is_superuser, True) return self.create_user(email, password, **extra_fields) class User(AbstractBaseUser, PermissionsMixin): email models.EmailField(uniqueTrue) # 唯一标识 first_name models.CharField(max_length30, blankTrue) last_name models.CharField(max_length30, blankTrue) is_active models.BooleanField(defaultTrue) is_staff models.BooleanField(defaultFalse) date_joined models.DateTimeField(auto_now_addTrue) objects UserManager() # 关联自定义管理器 USERNAME_FIELD email # 登录凭证字段 REQUIRED_FIELDS [first_name, last_name] # createsuperuser时必填字段 def __str__(self): return self.email注意USERNAME_FIELD email是关键开关它告诉Django认证系统“用邮箱而非用户名登录”。REQUIRED_FIELDS定义了createsuperuser命令的交互式输入项。4.2 配置AUTH_USER_MODELsettings.py中的一行决定项目生死在settings/base.py中添加必须在任何model导入前设置# mysite/settings/base.py AUTH_USER_MODEL users.User # app_name.ModelName这一行必须放在INSTALLED_APPS之后、所有models.py被导入之前。若在INSTALLED_APPS之前设置Django启动时会因找不到usersapp而崩溃若在某个model之后设置则makemigrations会报错LookupError: No installed app with label users。4.3 迁移与Admin适配从零开始重建用户生态重写用户模型后所有migration必须从头开始。这是本书第3章P60强调的“不可逆操作”# 1. 删除所有已有migration文件除__init__.py rm users/migrations/0*.py rm mysite/migrations/0*.py # 2. 生成初始migration此时Django还不知道User模型 python manage.py makemigrations users # 3. 强制标记为已应用因数据库已存在默认User表需跳过 python manage.py migrate --fake-initial # 4. 创建超级用户此时用新User模型 python manage.py createsuperuser # 输入邮箱、密码等不再有username字段Admin适配users/admin.py需重写# users/admin.py from django.contrib import admin from django.contrib.auth.admin import UserAdmin as BaseUserAdmin from .models import User admin.register(User) class UserAdmin(BaseUserAdmin): # 列表页显示字段 list_display (email, first_name, last_name, is_staff, date_joined) # 搜索字段 search_fields (email, first_name, last_name) # 过滤器 list_filter (is_staff, is_superuser, is_active, date_joined) # 编辑页布局 fieldsets ( (None, {fields: (email, password)}), (Personal Info, {fields: (first_name, last_name)}), (Permissions, {fields: (is_active, is_staff, is_superuser, groups, user_permissions)}), (Important dates, {fields: (last_login, date_joined)}), ) # 创建用户时的字段无password字段由set_password处理 add_fieldsets ( (None, { classes: (wide,), fields: (email, first_name, last_name, password1, password2), }), ) # 默认排序 ordering (email,)4.4 避坑自定义用户模型的致命陷阱现象→原因→解决现象python manage.py makemigrations报错SystemCheckError: System check identified some issues: ERRORS: ?: (auth.E001) AUTH_USER_MODEL refers to model users.User that has not been installed原因usersapp未加入INSTALLED_APPS或AUTH_USER_MODEL设置位置错误在INSTALLED_APPS之前。解决检查settings.py中INSTALLED_APPS是否包含users且AUTH_USER_MODEL设置在INSTALLED_APPS之后。现象createsuperuser后登录Admin提示Please enter the correct email and password...但邮箱密码确认无误原因UserManager.create_superuser()中未调用user.set_password(password)或set_password被覆盖。解决严格按本书代码create_superuser必须调用create_user已含set_password或手动添加user.set_password(password)。现象迁移后Admin页面显示User: 空字符串原因User.__str__()方法返回None或空字符串。解决确保__str__()返回非空字符串如return self.email。现象python manage.py migrate报错django.db.migrations.exceptions.InconsistentMigrationHistory原因数据库中已存在auth_user表来自旧User模型但新migration试图创建同名表。解决必须先清空数据库docker-compose down -v删除postgres_data卷再执行makemigrations和migrate。这是重写用户模型的代价也是本书强调“生产前规划”的原因。5. django-allauth集成从基础登录到邮箱验证、社交登录的工业级认证Django内置的auth系统解决了“用户是谁”但生产网站还需回答“用户如何证明自己”、“如何找回密码”、“能否用微信/Google一键登录”。本书第7章P137引入django-allauth它不是简单替换login视图而是提供一套可插拔、可定制、符合OAuth2/OpenID Connect标准的认证协议栈。跳过它意味着你要手写邮箱验证码、密码重置Token、社交登录OAuth Flow——这些全是安全敏感的黑匣子。5.1 安装与基础配置INSTALLED_APPS与MIDDLEWARE的精确排布django-allauth需在settings/base.py中精确配置顺序错误将导致认证失效# settings/base.py INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, # allauth required django.contrib.sites, # 必须用于多站点支持 # allauth apps allauth, allauth.account, allauth.socialaccount, # 如需社交登录 # allauth.socialaccount.providers.google, # 示例Google Provider # 你的app users, pages, ] 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, # allauth middleware必须在AuthenticationMiddleware之后 allauth.account.middleware.AccountMiddleware, ] # allauth required settings SITE_ID 1 # 对应django_site表的idallauth依赖 LOGIN_REDIRECT_URL / # 登录后跳转 LOGOUT_REDIRECT_URL / # 登出后跳转 ACCOUNT_LOGOUT_ON_GET True # 点击登出链接即登出无需确认页 ACCOUNT_EMAIL_REQUIRED True # 注册时必须填邮箱 ACCOUNT_USERNAME_REQUIRED False # 不需要用户名与自定义User模型一致 ACCOUNT_AUTHENTICATION_METHOD email # 用邮箱认证 ACCOUNT_EMAIL_VERIFICATION mandatory # 强制邮箱验证注意django.contrib.sites和SITE_ID 1是allauth的硬性依赖缺一不可。ACCOUNT_AUTHENTICATION_METHOD email必须与User.USERNAME_FIELD email保持一致。5.2 URL路由覆盖Django默认auth接管所有认证入口在mysite/urls.py中用allauth的URL覆盖Django内置auth# mysite/urls.py from django.contrib import admin from django.urls import path, include from django.views.generic import TemplateView urlpatterns [ path(admin/, admin.site.urls), # allauth URLs必须放在最前确保覆盖 path(accounts/, include(allauth.urls)), # 其他app path(, include(pages.urls)), ]allauth.urls自动注册以下路径/accounts/login/→ 登录页/accounts/logout/→ 登出/accounts/signup/→ 注册页带邮箱验证/accounts/password/reset/→ 密码重置/accounts/confirm-email/→ 邮箱验证确认页5.3 邮箱后端配置从console到SMTP生产环境必须实名开发阶段用console后端看邮件内容但生产必须用真实SMTP。本书第9章P175强调邮箱是用户身份的延伸不可伪造。配置settings/base.py# EMAIL_BACKEND django.core.mail.backends.console.EmailBackend # 开发用 # 生产环境以腾讯企业邮箱为例 EMAIL_BACKEND django.core.mail.backends.smtp.EmailBackend EMAIL_HOST smtp.exmail.qq.com EMAIL_PORT 465 EMAIL_USE_SSL True EMAIL_HOST_USER noreplyyourdomain.com # 发件邮箱 EMAIL_HOST_PASSWORD your_app_password # 应用专用密码非邮箱密码 DEFAULT_FROM_EMAIL Your Site noreplyyourdomain.com提示EMAIL_HOST_PASSWORD必须是邮箱服务商提供的“应用专用密码”App Password开启SMTP服务后生成。绝不可使用邮箱登录密码这是安全红线。5.4 自定义模板覆盖allauth默认UI融入项目品牌allauth提供默认模板但生产网站必须定制。创建目录结构templates/ ├── account/ │ ├── base.html # 所有account页面继承 │ ├── login.html # 登录页 │ ├── signup.html # 注册页 │ ├── email_confirm.html # 邮箱确认页 │ └── password_reset.html # 密码重置页templates/account/base.html示例精简!-- templates/account/base.html -- {% extends base.html %} {% block content %} div classcontainer mt-5 div classrow justify-content-center div classcol-md-6 {% if messages %} {% for message in messages %} div classalert alert-{{ message.tags }} alert-dismissible fade show rolealert {{ message }} button typebutton classbtn-close>!-- templates/account/login.html -- {% extends account/base.html %} {% block inner_content %} h2Login/h2 form methodpost {% csrf_token %} {{ form.as_p }} button typesubmit classbtn btn-primaryLogin/button /form pa href{{ signup_url }}Dont have an account? Sign up/a/p {% endblock %}5.5 避坑allauth集成的高频故障现象→原因→解决现象访问/accounts/login/报错Reverse for account_login not found原因urls.py中include(allauth.urls)的路径未匹配或INSTALLED_APPS中allauth.account未启用。解决确认INSTALLED_APPS包含allauth.account且urls.py中path(accounts/, include(allauth.urls))路径正确。现象注册后收不到验证邮件console后端也无输出原因ACCOUNT_EMAIL_VERIFICATION mandatory要求邮箱验证但EMAIL_BACKEND未正确配置或DEFAULT_FROM_EMAIL格式错误必须含email。解决检查EMAIL_BACKEND配置用python manage.py sendtestemail adminexample.com测试。现象登录成功后跳转到/accounts/profile/404而非LOGIN_REDIRECT_URL原因allauth检测到用户有accountapp的UserProfile模型试图跳转。解决删除accountapp相关配置或在settings.py中显式设置LOGIN_REDIRECT_URL。现象/accounts/signup/页面显示This field is required.邮箱字段原因User模型的email字段未设blankFalse或UserManager.create_user未校验邮箱。解决确保User.email models.EmailField(uniqueTrue)且UserManager.create_user有if not email:校验。6. 环境变量与Docker Compose进阶从.env到健康检查构建可交付的部署包生产环境没有DEBUGTrue的宽容也没有SECRET_KEY明文写在代码里的侥幸。本书第8章P167和第17章P320反复强调环境变量是生产与开发的楚河汉界而Docker Compose是这条界线的物理实现。本章将带你把.env、docker-compose.prod.yml、健康检查、多阶段构建全部串起来产出一个可直接交付运维的部署包。6.1 .env文件隔离敏感信息让Git仓库真正安全创建项目根目录下的.env文件务必加入.gitignore# .env - 开发环境变量 DEBUG1 SECRET_KEYdjango-insecure-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DATABASE_URLpostgresql://postgres:postgresdb:5432/postgres EMAIL_BACKENDdjango.core.mail.backends.console.EmailBackend # 生产环境变量另存为 .env.prod不提交 # DEBUG0 # SECRET_KEYyour-production-secret-key-here # DATABASE_URLpostgresql://produser:prodpassprod-db:5 p a hrefhttps://download.csdn.net/download/weixin_31569663/90830803 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p