企业官网建设流程全解析

简介：本资源是William S. Vincent所著《Django for Professionals》的完整PDF电子书，面向具备Django基础、正迈向生产级开发的中高级Python Web开发者。全书系统讲解如何用Django构建可部署、高安全、易维护的专业网站，覆盖Docker容器化部署、PostgreSQL生产数据库集成、自定义用户模型与邮箱验证认证流程、单元测试与集成测试策略、环境变量管理、静态资源优化（Bootstrap/Crispy Forms）、用户注册进阶（django-allauth）等核心实践模块，直击从开发到上线的关键断层。资源为1个25.89MB的PDF文件，内容结构清晰，含7大实操章节与丰富代码示例，每章均包含Git实践、测试编写与部署要点，适合作为项目落地手册反复查阅。目前已有61人学习下载，是少有的聚焦Django生产工程化而非入门语法的深度指南。

1. Django专业网站构建指南：不是教你怎么写python manage.py runserver，而是告诉你从零上线一个能扛住日均万级请求、带权限分级、API与页面共存、CI/CD自动发布的生产级站点，到底要填多少个坑

你手头有个新项目，老板说“用Django做，要快、要稳、要能加功能”，你兴冲冲建好虚拟环境、startproject、startapp，跑通了首页和用户登录——然后卡在第三天：管理员后台怎么限制某类用户只能看自己提交的订单？API接口返回的 JSON 字段名要驼峰但模型是下划线，手动.values()写到吐；前端发来一个带嵌套数组的 POST，后端校验逻辑散落在视图、序列化器、模型 clean 方法里，改一处漏三处；更别说部署时 Nginx 配置 403、静态文件 404、数据库迁移在生产环境死锁、Celery 定时任务莫名消失……这不是 Django 不行，是“专业网站”四个字背后藏着一整套工程链路：它要求你同时是路由规划师、权限架构师、数据契约制定者、部署流水线编排者，而不是只懂ModelForm的表单搬运工。本文面向已能独立完成博客/待办清单类 Demo 的开发者，目标明确：把本地能跑的 Django 项目，变成一个可交付、可维护、可横向扩展的生产系统。不讲 MTV 是什么，不画抽象分层图，只拆解真实项目中每一步必须做的决策、必写的配置、必验的边界——包括那些官方文档里轻描淡写、但会让你凌晨两点还在查日志的玄学问题。

2. 从startproject到结构定型：为什么你的myproject/myapp/目录结构注定撑不过第三个迭代

2.1 拒绝默认结构：manage.py同级建src/是专业项目的第一个分水岭

Django 默认生成的myproject/目录（含settings.py,urls.py）直接暴露在PYTHONPATH根路径下，会导致两个致命问题：一是第三方包（如django-crispy-forms）可能意外覆盖同名模块；二是当项目需要拆出公共库（如shared_utils/）或接入微服务网关时，路径污染让import变成俄罗斯套娃。常见做法是立即重构为src/结构：

# 创建标准 src 布局（执行前确保在项目根目录） mkdir -p src/myproject mv myproject/* src/myproject/ rmdir myproject mv manage.py src/ # 此时目录结构为： # ├── src/ # │ ├── manage.py # │ └── myproject/ # │ ├── __init__.py # │ ├── settings/ # │ │ ├── __init__.py # │ │ ├── base.py # 公共配置 # │ │ ├── development.py # 开发环境 # │ │ └── production.py # 生产环境 # │ ├── urls.py # │ └── wsgi.py # └── requirements/ # ├── base.txt # ├── development.txt # └── production.txt

提示：src/不是 Django 官方推荐，但已是行业事实标准（参考 Cookiecutter-Django、Django-ESI 等成熟模板）。它强制你思考“哪些代码属于项目核心，哪些属于部署胶水”，避免后期因路径混乱导致ImportError: cannot import name 'X'这类血泪经验。

2.2 settings 拆分：base.py里藏了 80% 的线上事故根源

把所有配置塞进一个settings.py是新手最大误区。生产环境需要隔离敏感信息（密钥、数据库密码）、动态适配（DEBUG 开关、缓存后端）、环境特异性（开发用 SQLite，生产用 PostgreSQL）。我一般会建三层配置：

关键操作：在production.py中必须显式导入base并覆盖：

# src/myproject/settings/production.py from .base import * DEBUG = False ALLOWED_HOSTS = ['myapp.com', 'www.myapp.com'] # 数据库密码从环境变量读取（绝不硬编码！） import os DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': os.environ.get('DB_NAME', 'myproject'), 'USER': os.environ.get('DB_USER', 'postgres'), 'PASSWORD': os.environ.get('DB_PASSWORD', ''), 'HOST': os.environ.get('DB_HOST', 'localhost'), 'PORT': os.environ.get('DB_PORT', '5432'), } } # 静态文件必须走 Whitenoise 或 CDN，禁止 DEBUG=False 时用 runserver 服务 STATIC_ROOT = '/var/www/myproject/static/' STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

注意：SECRET_KEY必须通过环境变量注入（os.environ.get('SECRET_KEY')），且生产环境密钥长度建议 ≥50 字符。曾有项目因使用django.core.management.utils.get_random_secret_key()生成的密钥被 Git 提交，导致安全审计直接挂掉。

2.3 应用拆分原则：一个core应用比十个功能耦合的app更易维护

新手常按功能建user_app,order_app,payment_app，结果order_app里要调user_app.models.UserProfile，payment_app又要改order_app.signals，形成循环依赖。专业做法是按职责域拆分：

• core/: 存放全局模型基类（TimeStampedModel）、自定义字段（JSONField兼容封装）、通用管理器（ActiveManager）、基础异常类（BusinessLogicError）
• users/: 仅处理用户生命周期（注册、登录、密码重置）、角色与权限组（Group扩展）、个人资料（UserProfile）
• orders/: 处理订单状态机（OrderStatus枚举）、支付回调验证、物流单号生成，不包含用户地址逻辑（归users/）
• payments/: 专注支付网关对接（支付宝/微信 SDK 封装）、交易流水记录、退款原子性控制，不处理订单状态变更（由orders/信号触发）

这种拆分让orders/models.py中的Order模型可以干净地引用users.models.UserProfile，而payments/views.py通过from orders.models import Order获取订单，无循环依赖。每个应用的apps.py必须显式声明default_auto_field：

# users/apps.py from django.apps import AppConfig class UsersConfig(AppConfig): default_auto_field = 'django.db.models.BigAutoField' # 避免 Django 3.2+ 迁移警告 name = 'users'

3. 权限与认证：绕过@login_required和is_staff，用 Django Groups + Permissions 实现细粒度业务控制

3.1 为什么is_superuser是权限设计的毒药

给运营人员开is_superuser=True账号看似省事，实则埋下雷：一旦该账号被钓鱼或泄露，攻击者可直接修改auth_group表、删除所有用户、清空数据库。专业方案是放弃超级用户，用Group+Permission组合拳：

1. 在users/admin.py中注册GroupAdmin并禁用add_view（防止非管理员创建组）
2. 为每个业务角色创建专属 Group：content_editor（可编辑文章但不可发布）、order_fulfiller（可更新订单状态但不可修改金额）、finance_analyst（可读财务报表但不可导出原始数据）
3. 用django.contrib.auth.models.Permission绑定具体模型操作，而非粗粒度is_staff

# users/management/commands/create_groups.py from django.core.management.base import BaseCommand from django.contrib.auth.models import Group, Permission from django.contrib.contenttypes.models import ContentType from orders.models import Order class Command(BaseCommand): def handle(self, *args, **options): # 创建 order_fulfiller 组 group, _ = Group.objects.get_or_create(name='order_fulfiller') # 绑定 Order 模型的特定权限（非全部） order_content_type = ContentType.objects.get_for_model(Order) permissions = Permission.objects.filter( content_type=order_content_type, codename__in=['change_order', 'view_order'] # 允许查看和修改，禁止删除/新增 ) group.permissions.set(permissions) self.stdout.write(f'Created group: {group.name}')

运行python manage.py create_groups后，在 Admin 后台将用户加入对应 Group 即可。

3.2 自定义权限逻辑：当change_order不够用时，用has_perm()做业务规则拦截

Django 内置权限只到模型级别（change_order），但业务常需更细控制：例如“客服只能修改自己分配的订单”。此时不能靠@permission_required，而要用has_perm()在视图中动态判断：

# orders/views.py from django.contrib.auth.mixins import LoginRequiredMixin from django.http import Http404 from django.views.generic import UpdateView from .models import Order class OrderUpdateView(LoginRequiredMixin, UpdateView): model = Order fields = ['status', 'tracking_number'] def get_object(self, queryset=None): obj = super().get_object(queryset) # 业务规则：仅允许修改自己负责的订单（假设 Order 有 assigned_to 字段） if not (self.request.user.is_staff or obj.assigned_to == self.request.user or self.request.user.has_perm('orders.change_any_order')): raise Http404("No permission to edit this order") return obj def form_valid(self, form): # 记录谁修改了订单（审计日志） form.instance.updated_by = self.request.user return super().form_valid(form)

提示：has_perm()的权限码格式为'app_label.codename'，如'orders.change_any_order'。这个权限需在orders/apps.py中通过ready()方法动态注册：

# orders/apps.py from django.apps import AppConfig class OrdersConfig(AppConfig): name = 'orders' def ready(self): from django.contrib.auth.models import Permission from django.contrib.contenttypes.models import ContentType from .models import Order # 动态添加自定义权限（仅在 migrate 后执行一次） content_type = ContentType.objects.get_for_model(Order) Permission.objects.get_or_create( codename='change_any_order', name='Can change any order', content_type=content_type, )

3.3 API 权限统一网关：DRF 的IsAuthenticatedOrReadOnly不够，用自定义BasePermission

REST Framework 的默认权限类无法满足混合场景（如/api/orders/需登录才能 POST，但/api/orders/123/允许公开 GET）。必须写自定义权限类，且与前端 Token 体系对齐：

# api/permissions.py from rest_framework import permissions from rest_framework.exceptions import PermissionDenied class OrderPermission(permissions.BasePermission): def has_permission(self, request, view): # GET /api/orders/ 允许未登录用户（公开列表） if request.method == 'GET' and view.action == 'list': return True # 其他方法（POST/PUT/DELETE）必须登录 return request.user and request.user.is_authenticated def has_object_permission(self, request, view, obj): # GET 单个订单：允许订单所属用户或客服组成员 if request.method == 'GET': return (obj.user == request.user or request.user.groups.filter(name='order_fulfiller').exists()) # 修改订单：仅订单所属用户或客服组成员 return (obj.user == request.user or request.user.groups.filter(name='order_fulfiller').exists()) # api/views.py from rest_framework.viewsets import ModelViewSet from .permissions import OrderPermission class OrderViewSet(ModelViewSet): queryset = Order.objects.all() serializer_class = OrderSerializer permission_classes = [OrderPermission] # 替代 IsAuthenticated

4. 避坑：Django专业部署中 5 个让你凌晨三点还在查日志的致命问题

4.1 现象：Nginx 返回 502 Bad Gateway，supervisorctl status显示FATAL Exited too quickly

原因：Gunicorn 启动时因settings.production中数据库连接失败、密钥缺失或STATIC_ROOT目录不存在而崩溃退出，Supervisor 检测到进程秒退，反复重启直至超时。
解决：

1. 先手动运行 Gunicorn 测试：gunicorn --bind 127.0.0.1:8000 --workers 3 myproject.wsgi:application --log-level debug
2. 查看输出中的ImportError或OperationalError，重点检查DATABASES配置和环境变量是否注入成功
3. 确保STATIC_ROOT目录存在且www-data用户有写权限：sudo mkdir -p /var/www/myproject/static && sudo chown www-data:www-data /var/www/myproject/static

4.2 现象：Django Admin 后台登录成功，但点击任何模型都报Permission denied: '/static/admin/css/base.css'

原因：DEBUG=False时 Django 不再提供静态文件服务，但 Nginx 配置未正确指向STATIC_ROOT，或STATIC_ROOT路径与 Nginxlocation /static/的alias不匹配。
解决：

1. 运行python manage.py collectstatic --noinput确保静态文件已复制到STATIC_ROOT
2. 检查 Nginx 配置中location /static/的alias必须以/结尾，且路径与STATIC_ROOT完全一致：

   location /static/ { alias /var/www/myproject/static/; # 注意末尾斜杠！ expires 1y; add_header Cache-Control "public, immutable"; }

3. 重启 Nginx：sudo systemctl restart nginx

4.3 现象：Celery 定时任务（@periodic_task）在开发环境正常，生产环境完全不执行

原因：Celery Worker 启动时未指定-Q队列名，或CELERY_TASK_ROUTES配置错误，导致任务被发送到默认队列但 Worker 监听的是其他队列。
解决：

1. 在celery.py中显式设置默认队列：

   # myproject/celery.py app.conf.task_default_queue = 'default' app.conf.task_routes = { 'orders.tasks.send_order_confirmation': {'queue': 'email'}, 'users.tasks.send_weekly_digest': {'queue': 'email'}, }

2. 启动 Worker 时指定队列：celery -A myproject worker -Q default,email -l info
3. 使用celery -A myproject inspect active_queues验证 Worker 是否监听目标队列

4.4 现象：python manage.py migrate在生产环境卡住，ps aux | grep postgres显示多个ALTER TABLE进程阻塞

原因：PostgreSQL 的ALTER TABLE ... ADD COLUMN在大表上会获取ACCESS EXCLUSIVE锁，阻塞所有读写。若表有千万级数据，迁移可能持续数小时。
解决：

1. 永远不要在生产高峰执行ADD COLUMN，改用--fake-initial或分步迁移：
   • 第一步：添加 nullable 字段并--fake（不实际执行 SQL）
   • 第二步：用后台任务批量填充默认值
   • 第三步：ALTER COLUMN ... SET NOT NULL（此时锁时间极短）
2. 使用pg_stat_activity查看阻塞源：

   SELECT blocked_locks.pid AS blocked_pid, blocking_locks.pid AS blocking_pid, blocked_activity.usename AS blocked_user, blocking_activity.usename AS blocking_user, blocked_activity.query AS blocked_statement, blocking_activity.query AS current_statement_in_blocking_process FROM pg_catalog.pg_locks blocked_locks JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid JOIN pg_catalog.pg_locks blocking_locks ON blocking_activity.pid = blocking_locks.pid AND blocked_activity.pid = blocking_locks.pid JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid WHERE NOT blocked_activity.pid = blocking_activity.pid;

4.5 现象：用户上传头像后，{{ user.profile.avatar.url }}返回http://localhost:8000/media/xxx.jpg，但生产环境域名是https://myapp.com

原因：MEDIA_URL在settings.production.py中仍为'/media/'，未配置为完整 URL，导致 Django 生成相对路径，前端拼接时用了开发环境域名。
解决：

1. 在settings.production.py中设置绝对MEDIA_URL：

   # 生产环境必须用完整 URL，否则 CDN 无法识别 MEDIA_URL = 'https://cdn.myapp.com/media/' # 对应 Nginx 配置 media 路径反向代理到 Django media 目录 location /media/ { proxy_pass http://127.0.0.1:8000/media/; proxy_set_header Host $host; }

2. 确保MEDIA_ROOT是绝对路径：MEDIA_ROOT = '/var/www/myproject/media/'
3. 运行python manage.py collectstatic不影响 media，但需确保MEDIA_ROOT目录权限正确：sudo chown -R www-data:www-data /var/www/myproject/media/

5. CI/CD 流水线：用 GitHub Actions 实现从 push 到线上发布的全自动闭环

5.1 流水线设计哲学：拒绝“一键部署”，拥抱“可验证、可回滚、可审计”的三原则

很多团队用fab deploy或 Shell 脚本实现部署，但缺乏版本追溯（哪次 commit 触发了这次发布？）、缺乏前置验证（测试没过就推到生产？）、缺乏回滚机制（出问题如何秒级切回上一版？）。专业 CI/CD 必须满足：

• 可验证：每次 PR 必须通过单元测试 + 集成测试 + 静态检查（Black + Flake8）
• 可回滚：发布产物（Docker 镜像或代码压缩包）带 Git Commit Hash 标签，回滚即拉取旧镜像重启
• 可审计：所有步骤日志留存，发布记录写入数据库（DeploymentLog模型），含操作人、commit、时间、环境

5.2 GitHub Actions 工作流：.github/workflows/deploy.yml

以下是一个生产可用的最小可行流水线，支持开发分支（dev）自动部署到预发环境，主分支（main）自动部署到生产环境：

# .github/workflows/deploy.yml name: Deploy to Server on: push: branches: [dev, main] paths-ignore: - '**.md' - 'docs/**' env: PYTHON_VERSION: '3.11' PROJECT_NAME: 'myproject' # 从 Secrets 注入服务器凭证（GitHub Settings → Secrets → Actions） SERVER_IP: ${{ secrets.SERVER_IP }} SERVER_USER: ${{ secrets.SERVER_USER }} SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }} jobs: test-and-lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: ${{ env.PYTHON_VERSION }} - name: Install dependencies run: | python -m pip install --upgrade pip pip install -r requirements/development.txt - name: Run unit tests run: python manage.py test --keepdb # 使用 --keepdb 加速 - name: Run static analysis run: | pip install black flake8 black --check . --exclude migrations/ flake8 . --exclude=migrations/ deploy-to-staging: needs: test-and-lint if: github.head_ref == 'dev' || github.base_ref == 'dev' runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Deploy to Staging uses: appleboy/scp-action@v0.1.6 with: host: ${{ env.SERVER_IP }} username: ${{ env.SERVER_USER }} key: ${{ env.SSH_KEY }} source: "src/,requirements/,manage.py" target: "/var/www/staging/" - name: Run remote commands uses: appleboy/ssh-action@v0.1.8 with: host: ${{ env.SERVER_IP }} username: ${{ env.SERVER_USER }} key: ${{ env.SSH_KEY }} script: | cd /var/www/staging source venv/bin/activate pip install -r requirements/production.txt python manage.py collectstatic --noinput python manage.py migrate --noinput supervisorctl restart myproject_staging deploy-to-production: needs: test-and-lint if: github.head_ref == 'main' || github.base_ref == 'main' runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Build Docker image run: | docker build -t ${{ secrets.DOCKER_REGISTRY }}/myproject:${{ github.sha }} . - name: Push to registry run: | echo "${{ secrets.DOCKER_PASSWORD }}" | docker login ${{ secrets.DOCKER_REGISTRY }} -u ${{ secrets.DOCKER_USERNAME }} --password-stdin docker push ${{ secrets.DOCKER_REGISTRY }}/myproject:${{ github.sha }} - name: Deploy to Production uses: appleboy/ssh-action@v0.1.8 with: host: ${{ env.SERVER_IP }} username: ${{ env.SERVER_USER }} key: ${{ env.SSH_KEY }} script: | cd /var/www/production # 拉取新镜像并启动（--rm 确保旧容器清理） docker run -d \ --rm \ --name myproject-prod-${{ github.sha }} \ --network host \ -e DJANGO_SETTINGS_MODULE=myproject.settings.production \ -e SECRET_KEY=${{ secrets.SECRET_KEY }} \ -v /var/www/production/static:/app/static \ -v /var/www/production/media:/app/media \ ${{ secrets.DOCKER_REGISTRY }}/myproject:${{ github.sha }} # 停止旧容器（保留最近 2 个版本用于回滚） docker ps -a --format "{{.Names}}" | grep myproject-prod- | head -n -2 | xargs -r docker stop

注意：此工作流依赖Dockerfile（见下节）和 GitHub Secrets 预置的服务器凭证、Docker Registry 凭据。docker run命令中-v挂载确保静态/媒体文件持久化，--network host避免容器网络复杂化。

5.3 Dockerfile：为什么不用FROM python:3.11-slim而用FROM continuumio/miniconda3

Python 官方镜像在编译 C 扩展（如psycopg2-binary、Pillow）时经常因缺少系统库（libpq-dev,libjpeg-dev）失败，导致pip install超时。更可靠的做法是用 Conda 镜像，它自带科学计算生态和编译工具链：

# Dockerfile FROM continuumio/miniconda3:23.11.0 # 设置工作目录 WORKDIR /app # 复制 requirements 并安装（Conda 优先安装，pip 补充） COPY requirements/production.txt . RUN conda install --yes --file requirements/production.txt && \ pip install --no-cache-dir -r requirements/production.txt # 复制源码（注意 .dockerignore 排除 .git、__pycache__） COPY src/ . # 创建非 root 用户（安全最佳实践） RUN useradd -m -u 1001 -g root appuser USER appuser # 暴露端口 EXPOSE 8000 # 启动命令（Gunicorn + Whitenoise） CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "3", "--access-logfile", "-", "--error-logfile", "-", "myproject.wsgi:application"]

配套.dockerignore文件必须包含：

.git __pycache__ *.pyc *.pyo *.pyd .Python env venv pip-log.txt .coverage .tox nosetests.xml coverage.xml *.log .gitignore README.md

5.4 回滚机制：当main分支发布出问题，30 秒内切回上一版

回滚不是“重新跑一遍流水线”，而是利用 Docker 镜像的不可变性，直接拉取上一版镜像启动：

# 登录生产服务器，执行回滚脚本 # rollback.sh #!/bin/bash # 获取当前运行的容器 ID（最新版） CURRENT_CONTAINER=$(docker ps -q --filter "name=myproject-prod-" | head -1) if [ -z "$CURRENT_CONTAINER" ]; then echo "No running container found" exit 1 fi # 获取上一版镜像标签（假设镜像名格式为 registry/myproject:commit_hash） PREV_IMAGE=$(docker images --format "{{.Repository}}:{{.Tag}}" | grep myproject | sort -r | sed -n '2p') if [ -z "$PREV_IMAGE" ]; then echo "No previous image found" exit 1 fi echo "Rolling back to $PREV_IMAGE" # 停止当前容器 docker stop $CURRENT_CONTAINER # 启动上一版镜像（复用相同参数） docker run -d \ --rm \ --name myproject-prod-rollback-$(date +%s) \ --network host \ -e DJANGO_SETTINGS_MODULE=myproject.settings.production \ -e SECRET_KEY=$SECRET_KEY \ -v /var/www/production/static:/app/static \ -v /var/www/production/media:/app/media \ $PREV_IMAGE

将此脚本放入服务器/usr/local/bin/rollback.sh，赋予执行权限，出问题时sudo rollback.sh即可。

6. 最后一道防线：用 Django Debug Toolbar + Sentry + Prometheus 构建可观测性铁三角

6.1 Debug Toolbar：仅限开发环境的性能显微镜，但配置不当会拖垮整个页面

django-debug-toolbar是开发期神器，但若在DEBUG=True时未限制 IP，会暴露数据库查询、缓存命中率等敏感信息。必须做三重防护：

# settings/development.py INSTALLED_APPS += ['debug_toolbar'] MIDDLEWARE += ['debug_toolbar.middleware.DebugToolbarMiddleware'] # 仅允许本地和公司内网访问（禁止公网暴露） INTERNAL_IPS = [ '127.0.0.1', '192.168.1.0/24', # 公司内网段 ] # 关键：禁用模板渲染面板（它会重复渲染整个页面，导致 200ms 延迟） DEBUG_TOOLBAR_CONFIG = { 'SHOW_TOOLBAR_CALLBACK': lambda request: ( request.META.get('REMOTE_ADDR') in INTERNAL_IPS and request.META.get('HTTP_X_FORWARDED_FOR', '').split(',')[0] in INTERNAL_IPS ), 'DISABLE_PANELS': { 'debug_toolbar.panels.templates.TemplatesPanel', # 禁用模板面板 'debug_toolbar.panels.redirects.RedirectsPanel', # 禁用重定向面板 }, }

提示：Toolbar 的 SQL 面板能直观显示 N+1 查询（红色高亮），看到SELECT * FROM auth_user被执行 50 次，立刻去select_related()或prefetch_related()优化。

6.2 Sentry：捕获生产环境所有未处理异常，并关联用户与 Release

django-sentry不是简单pip install就完事，关键在 Release 关联和用户上下文注入：

# settings/production.py import sentry_sdk from sentry_sdk.integrations.django import DjangoIntegration sentry_sdk.init( dsn=os.environ.get('SENTRY_DSN'), integrations=[DjangoIntegration()], # 关联 Git Commit，便于定位问题版本 release=os.environ.get('GIT_COMMIT', 'unknown'), # 环境标识，区分 staging/prod environment=os.environ.get('ENVIRONMENT', 'production'), # 过滤敏感数据（自动过滤 password、token 等字段） send_default_pii=True, ) # 在中间件中注入用户信息（需登录用户） class SentryUserContextMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): if hasattr(request, 'user') and request.user.is_authenticated: sentry_sdk.set_user({ "id": request.user.id, "username": request.user.username, "email": request.user.email, }) return self.get_response(request)

在MIDDLEWARE中插入此中间件，Sentry 报告中就能看到“哪个用户、在哪个版本、触发了什么异常”。

6.3 Prometheus + Django Metrics：监控不是“有没有”，而是“慢在哪、谁在拖”

光有 Sentry 只知道“崩了”，不知道“为什么崩”。用django-prometheus暴露关键指标：

# settings/production.py INSTALLED_APPS += ['django_prometheus'] MIDDLEWARE = [ 'django_prometheus.middleware.PrometheusBeforeMiddleware', # ... 其他中间件 'django_prometheus.middleware.PrometheusAfterMiddleware', ] # urls.py from django.urls import path, include urlpatterns = [ # ... 其他路由 path('metrics/', include('django_prometheus.urls')), # 暴露 /metrics 端点 ]

然后在 Nginx 中反向代理该端点供 Prometheus 抓取：

# Nginx 配置片段 location /metrics { proxy_pass http://127.0.0.1:8000/metrics; proxy_set_header Host $host; # 仅允许 Prometheus 服务器访问（通过 IP 白名单） allow 192.168.2.100; # Prometheus 服务器 IP deny all; }

Prometheus 配置scrape_configs：

- job_name: 'django' static_configs: - targets: ['myapp.com:80'] # Nginx 暴露的 metrics 端点

关键指标看板（Grafana 查询）：

我坚持在每个新项目上线前，先搭好这三套监控：Toolbar 确保开发期不埋雷，Sentry 确保线上问题秒级感知，Prometheus 确保性能瓶颈可量化。没有监控的 Django 项目，就像没有仪表盘的飞机——你不知道油量还剩多少，直到引擎停转。希望帮到你。

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