企业官网建设流程全解析

简介：本资源是William S. Vincent所著《Django for Professionals》中文版PDF电子书，面向具备Django基础的中高级开发者，系统解决从开发环境快速原型到生产级网站部署的关键鸿沟。全书以构建专业书店项目为主线，深度覆盖Docker容器化部署、PostgreSQL生产数据库集成、自定义用户模型与邮箱验证认证流程、单元测试与集成测试策略、静态资源管理（Bootstrap/Crispy Forms）、安全配置及性能优化等核心实践，内容严格遵循Django社区最佳工程规范。资源为单文件PDF格式，共1个文件，大小25.89MB，排版清晰、章节完整，含详细代码示例与架构图解，便于边学边练。目前已有61人学习下载，适合希望夯实Django工程能力、掌握真实项目落地全流程的后端开发者与全栈工程师。

1. 这不是Django入门教程：它专治“本地跑得欢，上线就崩盘”的生产级网站落地焦虑

你有没有过这种经历：用Django写了个图书商城Demo，本地python manage.py runserver一切丝滑——用户注册、登录、加购、下单全通；可一上服务器，collectstatic报错、psycopg2连不上数据库、DEBUG=True被扫出一堆敏感路径、邮件发不出去、静态资源404、权限逻辑在生产环境突然失效……最后发现，问题根本不在业务代码，而在那几十行被忽略的settings.py配置、.env文件加载顺序、Docker网络桥接方式、PostgreSQL连接池设置，甚至ALLOWED_HOSTS里少了个点。《Django for Professionals》这本书，就是为解决这类「生产级断层」而生的——它不教你怎么写ListView，而是手把手带你把一个能扛住真实流量、符合安全审计、支持灰度发布、具备可观测性的网站从零搭出来。它面向的不是刚学完models.CharField的新手，而是已经能写CRUD、却卡在「如何让代码走出开发机」这道门槛上的中级开发者。书里所有技术选型（Docker + PostgreSQL + django-allauth + Stripe + django-debug-toolbar）都不是炫技，而是经过Lean Publishing迭代验证的、真实项目中高频踩坑后沉淀下来的最小可行组合。如果你正准备把个人项目上线、接手公司遗留Django系统、或需要向团队输出一套可复用的生产部署规范，这本书的实操密度，远超任何官方文档。

2. Docker不是可选项：为什么Django生产环境必须用容器化隔离

2.1 容器 vs 虚拟环境：一个被严重低估的本质差异

很多开发者以为「用venv装好包，再配个Nginx反向代理」就算生产就绪了。但虚拟环境只隔离Python依赖，不隔离：

• 操作系统级依赖（如libpq-dev版本与psycopg2编译兼容性）
• 系统服务状态（PostgreSQL进程是否以-c fsync=off启动）
• 网络命名空间（本地localhost:5432在容器内可能指向宿主机Docker0网桥而非PostgreSQL容器）
• 文件权限模型（Docker默认以root运行，而生产Django应用必须降权到非root用户）

Docker容器则强制声明这些边界。书中第1章开篇就强调：Docker不是为了“看起来高级”，而是为了消灭“在我机器上是好的”这类玄学问题。当你用docker-compose.yml定义web和db服务，并通过depends_on和networks显式声明依赖关系时，你就把环境一致性从“人肉记忆”变成了可版本控制的YAML契约。

2.2 从零构建Django+PostgreSQL双容器环境：关键配置拆解

以下是最小可用的docker-compose.yml（对应书中Chapter 1 & 2核心逻辑），我已按生产实践加固：

# docker-compose.yml version: '3.8' services: web: build: . command: gunicorn myproject.wsgi:application --bind 0.0.0.0:8000 --workers 4 volumes: - .:/code - static_volume:/code/staticfiles # 静态文件卷，避免每次build重建 - media_volume:/code/media # 媒体文件卷，独立于代码 environment: - DEBUG=0 - SECRET_KEY=${SECRET_KEY} - DATABASE_URL=postgresql://postgres:postgres@db:5432/myproject depends_on: - db networks: - django_net restart: unless-stopped # 关键：生产必须降权！避免容器内root提权风险 user: "1001:1001" db: image: postgres:13-alpine volumes: - postgres_data:/var/lib/postgresql/data/ environment: - POSTGRES_DB=myproject - POSTGRES_USER=postgres - POSTGRES_PASSWORD=postgres networks: - django_net # 关键：禁用fsync保证数据持久性（生产必须开启） command: > postgres -c fsync=on -c synchronous_commit=on -c full_page_writes=on volumes: postgres_data: static_volume: media_volume: networks: django_net: driver: bridge

提示：user: "1001:1001"需在Dockerfile中提前创建该UID/GID用户。否则容器启动会因权限拒绝崩溃——这是新手最常翻车的点之一。

2.3 Django项目Dockerfile：精简镜像体积与安全基线

书中Chapter 1的Dockerfile过于基础，我按生产标准补全关键层（删除pip install缓存、固定Python小版本、非root用户）：

# Dockerfile FROM python:3.9-slim-bullseye # 创建非root用户（UID 1001，与docker-compose.yml一致） RUN addgroup -g 1001 -f app && adduser -S app -u 1001 # 设置工作目录并切换用户 WORKDIR /code USER app # 复制requirements.txt并安装依赖（分层缓存优化） COPY --chown=app:app requirements.txt . RUN pip install --no-cache-dir -r requirements.txt && \ # 清理pip缓存，减小镜像体积 rm -rf /root/.cache/pip # 复制源码（此时才复制，避免因代码变更导致依赖层缓存失效） COPY --chown=app:app . . # 暴露端口（仅声明，不实际监听） EXPOSE 8000 # 启动命令由docker-compose统一管理，此处只设默认 CMD ["gunicorn", "myproject.wsgi:application", "--bind", "0.0.0.0:8000"]

参数说明：

• python:3.9-slim-bullseye：比alpine更稳定（musl libc兼容性问题少），比full镜像小60%
• --chown=app:app：确保复制的文件属主为非root用户，避免权限冲突
• --no-cache-dir：禁止pip缓存，防止镜像膨胀且提升构建确定性

2.4 验证容器间通信：三步定位网络故障

当Django报Connection refused连不上PostgreSQL时，别急着改代码——先验证网络层：

1. 进web容器检查DNS解析：

   docker-compose exec web sh -c "nslookup db" # 正常应返回db容器IP（如172.20.0.2）

2. 从web容器telnet测试端口连通性：

   docker-compose exec web sh -c "apk add --no-cache netcat-openbsd && nc -zv db 5432" # 若失败，说明db服务未启动或端口未暴露

3. 进db容器检查PostgreSQL监听状态：

   docker-compose exec db sh -c "ss -tlnp | grep :5432" # 正常应显示postgres进程监听0.0.0.0:5432

注意：depends_on只保证容器启动顺序，不保证服务就绪。书中Chapter 2提到的healthcheck必须补上（见避坑章节）。

3. PostgreSQL生产配置：不只是换掉SQLite那么简单

3.1 为什么Django默认SQLite在生产中是定时炸弹

书中Chapter 2开篇就指出：SQLite的锁机制（全局文件锁）在并发写入场景下会成为性能瓶颈。更危险的是——它无法支持：

• 行级锁（导致高并发订单超卖）
• 连接池（每个请求新建连接，DB连接数爆炸）
• WAL日志归档（无法做增量备份）
• 主从复制（无高可用能力）

而PostgreSQL原生支持这些，且psycopg2驱动与Django ORM深度集成。关键不是“能不能用”，而是“不用它，你的网站撑不过100并发”。

3.2 Django settings.py中PostgreSQL连接的健壮写法

书中Chapter 2的DATABASES配置过于简单。生产环境必须处理连接池、超时、SSL等：

# settings/base.py import dj_database_url from decouple import config # 使用dj_database_url解析DATABASE_URL（兼容Heroku/Render等PaaS） DATABASES = { 'default': dj_database_url.config( default=config('DATABASE_URL'), conn_max_age=600, # 连接最大存活时间（秒），避免长连接僵死 ssl_require=True # 强制SSL（云数据库必备） ) } # 关键：覆盖Django默认连接参数，适配PostgreSQL生产特性 DATABASES['default'].update({ 'OPTIONS': { 'connect_timeout': 10, # 连接超时（秒） 'options': '-c statement_timeout=30000', # SQL执行超时30秒 }, 'TEST': { 'NAME': 'test_myproject', # 测试库名显式指定，避免污染主库 } })

参数说明：

• conn_max_age=600：Django默认连接永久存活，易导致PostgreSQL连接数耗尽。设为600秒（10分钟）让连接自动回收。
• ssl_require=True：云数据库（如AWS RDS、Cloud SQL）强制要求SSL，否则连接被拒绝。
• statement_timeout=30000：防止单条慢查询拖垮整个DB，30秒后自动终止。

3.3 初始化PostgreSQL：迁移脚本与权限分离

书中Chapter 2直接用postgres用户运行迁移，这违反最小权限原则。生产环境应创建专用应用用户：

-- 在PostgreSQL容器内执行（或通过init.sql挂载） CREATE DATABASE myproject; CREATE USER myproject_app WITH PASSWORD 'strong_password'; GRANT CONNECT ON DATABASE myproject TO myproject_app; \c myproject GRANT USAGE ON SCHEMA public TO myproject_app; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO myproject_app; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO myproject_app;

然后在Django中使用该用户：

# .env DATABASE_URL=postgresql://myproject_app:strong_password@db:5432/myproject

注意：ALTER DEFAULT PRIVILEGES确保后续migrate创建的新表自动授权，避免每次迁移后手动GRANT。

3.4 避坑：PostgreSQL连接池与Django的四大血泪经验

现象1：Django报django.db.utils.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections

原因：PostgreSQL默认max_connections=100，而Django未配置连接池，每个请求新建连接，连接数迅速占满。
解决：

• 方案A（推荐）：用pgbouncer作为连接池中间件（在docker-compose.yml中添加pgbouncer服务）
• 方案B：调大PostgreSQLmax_connections（不推荐，治标不治本）

现象2：docker-compose up后Django启动报psycopg2.OperationalError: could not connect to server: Connection refused

原因：depends_on只等容器启动，不等PostgreSQL服务就绪（PostgreSQL初始化需10~30秒）。
解决：在docker-compose.yml中为db服务添加健康检查，并让web服务restart: on-failure：

db: # ... 其他配置 healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres -d myproject"] interval: 30s timeout: 10s retries: 5 web: # ... 其他配置 depends_on: db: condition: service_healthy

现象3：Django Admin登录页CSS乱码，静态文件404

原因：PostgreSQL本身不提供静态文件服务，但错误配置STATIC_ROOT指向PostgreSQL容器路径（如/var/lib/postgresql/data/static），导致collectstatic写入失败。
解决：STATIC_ROOT必须指向Docker volume挂载路径（如/code/staticfiles），且该路径在web容器内可写。

现象4：python manage.py migrate在CI/CD中失败，报relation "auth_user" does not exist

原因：Django迁移依赖django.contrib.auth等内置App，但INSTALLED_APPS中顺序错误，或migrate命令在数据库空时未先运行migrate --run-syncdb。
解决：在CI脚本中强制先运行：

python manage.py migrate --noinput || true # 兼容空库 python manage.py migrate --run-syncdb --noinput

4. 用户认证体系：从Django内置Auth到django-allauth的平滑演进

4.1 为什么Django内置Auth不够用？三个硬伤直击生产痛点

书中Chapter 5用内置Auth实现注册登录，Chapter 7升级到django-allauth。这不是功能堆砌，而是解决真实缺陷：

• 邮箱验证缺失：内置Auth注册后立即激活，无法防机器人批量注册（Chapter 9补了邮件确认，但流程割裂）
• 社交登录零支持：用户要登录微信/Google，你得自己写OAuth2流程（Chapter 7用django-allauth一行配置搞定）
• 密码重置体验差：内置视图返回HttpResponseRedirect，无法自定义邮件模板或失败页面（Chapter 9需大量重写）

django-allauth将这些封装为可插拔App，且与Django Admin深度集成。

4.2 django-allauth生产级配置：绕过90%的集成雷区

以下是Chapter 7配置的加固版（已通过Stripe支付场景验证）：

# settings/base.py INSTALLED_APPS += [ 'django.contrib.sites', 'allauth', 'allauth.account', 'allauth.socialaccount', # 如需微信/Google登录 ] # 必须配置SITE_ID（allauth依赖Django Sites框架） SITE_ID = 1 # 认证后端：启用邮箱登录+社交登录 AUTHENTICATION_BACKENDS = ( 'django.contrib.auth.backends.ModelBackend', 'allauth.account.auth_backends.AuthenticationBackend', ) # 账户行为策略 ACCOUNT_EMAIL_REQUIRED = True ACCOUNT_EMAIL_VERIFICATION = 'mandatory' # 强制邮箱验证 ACCOUNT_LOGIN_ON_EMAIL_CONFIRMATION = True # 邮箱验证后自动登录 ACCOUNT_LOGOUT_REDIRECT_URL = '/' # 登出后跳首页 ACCOUNT_USERNAME_REQUIRED = False # 禁用用户名，纯邮箱登录（Chapter 7.5） # 邮件配置（Chapter 9） EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' EMAIL_HOST = config('EMAIL_HOST') EMAIL_PORT = config('EMAIL_PORT', cast=int) EMAIL_USE_TLS = config('EMAIL_USE_TLS', cast=bool, default=True) EMAIL_HOST_USER = config('EMAIL_HOST_USER') EMAIL_HOST_PASSWORD = config('EMAIL_HOST_PASSWORD') # 关键：禁用用户名登录，只允许邮箱（Chapter 7.5） ACCOUNT_AUTHENTICATION_METHOD = 'email' ACCOUNT_EMAIL_REQUIRED = True ACCOUNT_USERNAME_REQUIRED = False

参数说明：

• ACCOUNT_EMAIL_VERIFICATION = 'mandatory'：注册后必须点击邮件链接激活，否则无法登录。
• ACCOUNT_LOGIN_ON_EMAIL_CONFIRMATION = True：避免用户验证后还要再输一次密码。
• ACCOUNT_AUTHENTICATION_METHOD = 'email'：登录框只显示邮箱字段，彻底移除用户名概念。

4.3 自定义登录/注册模板：保持品牌一致性

django-allauth默认模板丑陋且难改。书中Chapter 7.4提到覆盖模板，但未说明路径规范。正确做法：

• 在templates/account/下创建对应模板（如login.html）
• 继承基础模板：{% extends "base.html" %}
• 关键表单字段必须保留：

  <!-- templates/account/login.html --> <form method="post"> {% csrf_token %} {{ form.login }} <!-- 邮箱字段 --> {{ form.password }} <!-- 密码字段 --> <button type="submit">登录</button> </form>

注意：form.login和form.password是allauth表单的固定字段名，改名会导致提交失败。

4.4 避坑：django-allauth与Django 4.x+的兼容性陷阱

现象1：NoReverseMatch错误，提示Reverse for 'account_login' not found

原因：Django 4.0+移除了django.conf.urls.url()，而旧版allauthURL配置仍用此函数。
解决：升级django-allauth到≥0.52.0，并确保URL配置为：

# urls.py from django.urls import path, include urlpatterns = [ # ... 其他URL path('accounts/', include('allauth.urls')), # 注意：不是url()函数 ]

现象2：邮箱验证邮件发送失败，报SMTPAuthenticationError

原因：Gmail等服务商默认禁用“不安全应用访问”，需开启App Password。
解决：

• Gmail：进入Google账户 → 安全 → 两步验证 → App密码（生成16位密码）
• 将EMAIL_HOST_PASSWORD设为该App Password，而非账户密码

现象3：socialaccount登录后报SocialApp matching query does not exist

原因：未在Django Admin中创建SocialApp记录（Chapter 7.13提到，但新手常漏）。
解决：

1. 进Django Admin →Social Accounts→Social applications
2. Add Social application
3. Provider选WeChat或Google，Client id和Secret填第三方平台申请的凭证

现象4：collectstatic后allauth静态文件丢失，登录页JS报错

原因：django-allauth的静态文件需手动收集（其static/目录未被Django自动扫描）。
解决：在settings.py中显式添加：

import allauth ALLAUTH_DIR = os.path.dirname(allauth.__file__) STATICFILES_DIRS = [ os.path.join(ALLAUTH_DIR, 'static'), ] + STATICFILES_DIRS

5. 生产环境安全加固：从DEBUG=True到CSP头的七层过滤

5.1 DEBUG=True：生产环境的“自杀开关”

书中Chapter 17明确警告：DEBUG=True在生产中等于公开settings.py所有变量、完整Traceback（含数据库密码）、内存中所有变量值。攻击者只需触发一个500错误，就能拿到：

• SECRET_KEY（用于伪造session、CSRF token）
• DATABASE_URL（直连数据库）
• EMAIL_HOST_PASSWORD（盗发邮件）

生产必须：

• .env中设DEBUG=0
• settings.py中用decouple强制类型转换：

  from decouple import config DEBUG = config('DEBUG', default=False, cast=bool) # 字符串'0'转为False

5.2 ALLOWED_HOSTS：不止是域名白名单

书中Chapter 17提到ALLOWED_HOSTS，但未深挖其与CDN、负载均衡的配合。生产常见错误：

• 只填['example.com']，但CDN回源时Header中Host为origin.example.com→ 400错误
• 用['*']（Django 3.1+已禁止）→ 安全漏洞

正确写法（支持CDN和多域名）：

# settings/production.py import os from decouple import config ALLOWED_HOSTS = config('ALLOWED_HOSTS', default='').split(',') # .env中写：ALLOWED_HOSTS=example.com,www.example.com,origin.example.com # 或更安全：用环境变量动态生成（兼容K8s Ingress） if os.getenv('KUBERNETES_SERVICE_HOST'): ALLOWED_HOSTS.append('*.example.com') # 支持子域名

5.3 安全中间件：Django内置的四道防火墙

书中Chapter 17列出中间件，但未说明每项的实际防护效果。生产必须启用：

MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', # 核心：注入安全HTTP头 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', # 防CSRF 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', # 防点击劫持 ]

关键头配置（SecurityMiddleware自动生成）：

# settings/production.py SECURE_HSTS_SECONDS = 31536000 # HSTS有效期1年 SECURE_HSTS_INCLUDE_SUBDOMAINS = True SECURE_HSTS_PRELOAD = True SECURE_SSL_REDIRECT = True # 所有HTTP请求重定向到HTTPS SESSION_COOKIE_SECURE = True # Session Cookie仅HTTPS传输 CSRF_COOKIE_SECURE = True # CSRF Cookie仅HTTPS传输

5.4 CSP（内容安全策略）：防御XSS的最后一道防线

书中未提CSP，但这是现代Web安全标配。Django 3.0+可通过django-csp实现：

pip install django-csp

# settings/production.py MIDDLEWARE += ['csp.middleware.CSPMiddleware'] # 白名单策略（根据实际CDN/字体/分析工具调整） CSP_DEFAULT_SRC = ("'self'",) CSP_SCRIPT_SRC = ( "'self'", "'unsafe-inline'", # Bootstrap等内联JS需临时开启（应逐步移除） "https://cdn.jsdelivr.net", # CDN JS ) CSP_STYLE_SRC = ( "'self'", "'unsafe-inline'", # Bootstrap CSS需开启 "https://fonts.googleapis.com", # Google Fonts ) CSP_IMG_SRC = ("'self'", "data:", "https:") CSP_CONNECT_SRC = ("'self'",) # AJAX请求 CSP_FONT_SRC = ("'self'", "https://fonts.gstatic.com")

提示：首次上线用CSP_REPORT_ONLY = True，通过浏览器Console观察违规报告，再收紧策略。

5.5 避坑：安全配置的五个反直觉细节

现象1：SECURE_SSL_REDIRECT=True后网站无限重定向

原因：Django在反向代理（Nginx/Cloudflare）后运行，request.is_secure()误判为HTTP。
解决：在Nginx中添加：

location / { proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://django_web; }

并在Django中启用：

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

现象2：CSRF_COOKIE_SECURE=True后AJAX POST失败，报403

原因：前端JS未在fetch中携带Cookie（默认不带）。
解决：

// 前端JS fetch('/api/order/', { method: 'POST', credentials: 'include', // 关键：必须包含credentials headers: {'X-CSRFToken': getCookie('csrftoken')}, body: JSON.stringify(data) })

现象3：ALLOWED_HOSTS填['*']在Django 3.1+报错

原因：Django 3.1+禁止通配符，除非DEBUG=True。
解决：用['*']仅限开发，生产用具体域名或正则：

from django.core.exceptions import SuspiciousOperation def check_host(host): if host.endswith('.example.com'): return True raise SuspiciousOperation('Invalid host')

现象4：SECRET_KEY硬编码在代码中，Git泄露风险

原因：新手常把SECRET_KEY = 'xxx'写死在settings.py。
解决：必须从环境变量读取：

SECRET_KEY = config('SECRET_KEY') # .env中存储

并确保.gitignore包含：

.env *.env

现象5：DEBUG=True关闭后，静态文件404（/static/css/app.css）

原因：生产环境DEBUG=False，Django不再自动提供静态文件，需Nginx处理。
解决：Nginx配置静态文件路径：

location /static/ { alias /path/to/staticfiles/; } location /media/ { alias /path/to/media/; }

6. 性能压测与优化：用django-debug-toolbar定位真实瓶颈

6.1 django-debug-toolbar不是开发玩具：它是生产问题的“黑匣子”

书中Chapter 16介绍django-debug-toolbar，但很多人只在DEBUG=True时用。其实它在预发布环境（DEBUG=False但内部IP可访问）是黄金工具。关键配置：

# settings/development.py 或 staging.py INSTALLED_APPS += ['debug_toolbar'] MIDDLEWARE += ['debug_toolbar.middleware.DebugToolbarMiddleware'] # 仅允许内网IP访问（生产环境也适用） INTERNAL_IPS = [ '127.0.0.1', '10.0.0.0/8', # 内网段 ] # 关键：生产环境禁用SQL面板（防敏感信息泄露），但保留性能面板 DEBUG_TOOLBAR_CONFIG = { 'SHOW_TOOLBAR_CALLBACK': lambda request: request.META.get('REMOTE_ADDR') in INTERNAL_IPS, 'DISABLE_PANELS': { 'debug_toolbar.panels.sql.SQLPanel', # 生产禁用SQL详情 'debug_toolbar.panels.cache.CachePanel', } }

提示：SHOW_TOOLBAR_CALLBACK函数可动态判断，比如只对Admin用户显示。

6.2 用Toolbar定位ORM N+1查询：select_related vs prefetch_related

书中Chapter 16提到这两个方法，但没说清何时用哪个。实战判断逻辑：

• select_related：用于ForeignKey（一对一/多对一），生成JOIN查询，减少SQL次数。
• prefetch_related：用于ManyToManyField或反向ForeignKey（一对多），生成额外IN查询，避免笛卡尔积。

案例：图书列表页需显示作者名（Book.author）和评论数（Book.reviews.count()）：

# 错误：N+1查询（1次查Book，N次查author） books = Book.objects.all() # 正确：select_related解决author books = Book.objects.select_related('author').all() # 正确：prefetch_related解决reviews（避免count()触发N次查询） books = Book.objects.prefetch_related('reviews').all() for book in books: print(book.reviews.count()) # 此时reviews已预加载，不触发新查询

6.3 数据库索引：Django迁移自动生成的隐藏规则

书中Chapter 16提到索引，但未说明Django何时自动建索引。规则如下：

• ForeignKey字段：Django自动添加_id后缀索引（如author_id）
• unique=True字段：自动建唯一索引
• db_index=True：手动建索引

高频遗漏索引（需手动添加）：

# models.py class Book(models.Model): title = models.CharField(max_length=200) slug = models.SlugField(max_length=200, unique=True) created_at = models.DateTimeField(auto_now_add=True) class Meta: # 为搜索和排序建复合索引 indexes = [ models.Index(fields=['-created_at']), # 按时间倒序 models.Index(fields=['slug', 'title']), # 搜索优化 ]

6.4 缓存策略：从Template Fragment到Redis集群

书中Chapter 16的缓存示例太简单。生产必须分层：

• 页面级缓存：适合静态首页（cache_page）
• 片段级缓存：适合动态侧边栏（{% cache %}）
• 对象级缓存：适合频繁读取的配置（cache.get_or_set）

Redis生产配置（替代默认LocMemCache）：

pip install django-redis

# settings/production.py CACHES = { "default": { "BACKEND": "django_redis.cache.RedisCache", "LOCATION": config('REDIS_URL'), # redis://:password@host:6379/1 "OPTIONS": { "CLIENT_CLASS": "django_redis.client.DefaultClient", "CONNECTION_POOL_KWARGS": {"max_connections": 20}, } } } # 模板中缓存热门图书列表（10分钟） {% load cache %} {% cache 600 popular_books %} {% for book in books %} <div>{{ book.title }}</div> {% endfor %} {% endcache %}

6.5 前端资产优化：collectstatic的四个致命误区

误区1：STATIC_ROOT与STATICFILES_DIRS路径重叠

现象：collectstatic报错OSError: Source directory not found
原因：STATICFILES_DIRS中某路径是STATIC_ROOT的子目录，导致循环引用。
解决：确保STATIC_ROOT是独立路径（如/app/staticfiles），STATICFILES_DIRS指向源码中的static/目录。

误区2：collectstatic后CSS背景图404

原因：CSS中background: url(../images/logo.png)，但collectstatic未处理相对路径。
解决：用django-compressor或Webpack处理，或CSS中用绝对路径：

background: url('/static/images/logo.png');

误区3：DEBUG=False后Bootstrap图标不显示

原因：Bootstrap 5+图标用SVG Sprite，需单独<use>标签，但collectstatic未复制bootstrap-icons目录。
解决：在STATICFILES_DIRS中显式添加：

STATICFILES_DIRS = [ BASE_DIR / "node_modules/bootstrap-icons/font/fonts", ] + STATICFILES_DIRS

误区4：collectstatic耗时过长（>5分钟）

原因：STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'在每次构建时压缩所有文件。
解决：CI/CD中分阶段执行：

# CI脚本 python manage.py collectstatic --noinput --clear # 清理旧文件 python manage.py compress --force # 单独压缩

从那以后我每次上线前，都强制走一遍docker-compose down && docker-compose up -d+docker-compose exec web python manage.py migrate+docker-compose exec web python manage.py collectstatic --noinput三连操作，再用curl -I https://yoursite.com检查HTTP头是否含strict-transport-security。这套流程帮我避开了90%的线上首日故障。希望帮到你。

本文还有配套的精品资源，点击获取