小程序 + Django 支教管理系统设计与实现全解析

小程序 + Django 的大学生支教管理系统，这个组合在最近的毕业设计和实际项目里出现频率很高。我接触过不少类似的项目，有的做成了纯粹的报名工具，有的做成了后台管理面板，真正把“支教全流程”跑通的其实不多。

这个项目标题里有两个关键词值得注意：一是“小程序”，说明前端形态锁定在微信生态里；二是“Django”，后端框架选择了 Python 系最成熟的重量级方案。整套系统要解决的核心问题，是把大学生支教从报名、审核、课程安排到反馈总结的完整链路线上化，让管理员、支教学生、受援学校三方在同一个平台里协作。

如果你是正在做毕业设计、或者想给学校社团搭建一套支教管理工具，这篇文章可以给你提供一套能够直接复用的设计与实现方案。我会从技术选型、数据模型、核心功能实现、部署上线这几个维度拆开讲，全程结合真实踩坑经验。

1. 项目整体设计与技术选型思路

1.1 为什么用 Django 做后端

Django 在 Python Web 框架里的地位类似“全家桶”，它自带 Admin 后台、ORM、认证体系、表单处理、分页组件，这对支教管理系统这种典型的管理类应用来说，性价比非常高。

先说 ORM。支教管理系统的数据模型不算复杂，但关联关系很多：一个支教项目关联多个志愿者，一个志愿者报名多个项目，每个项目又包含多节课程安排。如果用原生 SQL 硬写，光是多表联查就能写到手软。Django 的 ORM 可以直接用 Student.objects.filter(project__status='ongoing') 这种双下划线语法跨表查询，代码简洁，还能避免手动拼接 SQL 带来的注入风险。

再说 Admin 后台。大学生支教管理系统的大部分操作都是增删改查，Django Admin 可以零代码生成一个完整的管理界面。我在实际开发中一般是先让管理员用 Admin 录入基础数据，等接口写完后再切到自定义前端页面。这样项目的开发周期能压缩三分之一以上。

Django 自带的后台管理系统，你不用白不用，它能让项目在早期快速跑通业务闭环。

第三是认证体系。Django 的 django.contrib.auth 提供了用户注册、登录、Session 管理、权限分组，这些都是现成的。对于支教系统来说，需要区分超管、学院负责人、支教学生、受援学校老师等角色，直接基于 Django 的 Group 和 Permission 扩展就行，不用自己从零写一套权限系统。

1.2 为什么用微信小程序做前端

支教学生的使用场景非常碎片化：在宿舍用手机报名、在支教路上查看日程、用手机提交课程反馈。微信小程序“即用即走”的特性天然适配这种移动场景，学生不用下载 App，扫码就能用。

小程序端的技术选型有两条路：原生开发，或者使用 uni-app / Taro 等跨端框架。我个人的建议是：如果只针对微信小程序一个平台，用原生开发就够了。原生小程序的 WXML + WXSS 结构清晰，微信开发者工具里的调试体验也最好。如果后续想同时上线支付宝小程序或抖音小程序，再考虑换成 uni-app。

需要注意的是，小程序和 Django 后端的通信没有“跨域”问题，这一点和 Web 前端完全不同。小程序通过 wx.request 直接请求域名接口即可，但要求该域名必须已经备案，并且在小程序后台配置为 request 合法域名。这个环节是新手最容易卡住的地方，后面我会单独讲。

1.3 系统模块与角色设计

支教管理系统从业务上看，可以拆成几个核心模块：

• 用户管理：学生注册、登录、身份认证、个人信息维护；
• 支教项目管理：发布支教项目、设置招募时间、人数上限、项目地点与周期；
• 报名与审核：学生提交报名申请，管理员审核通过后纳入项目成员；
• 课程与排课管理：支教期间的上课安排、课程表生成与调整；
• 签到与考勤：支教出勤记录，用于后期志愿时长认定；
• 反馈与总结：支教结束后提交个人总结、支教心得，管理员可以进行评分归档；
• 数据统计：按学院、按时间统计报名人数、支教时长等数据。

从角色权限上看，我把系统分成四类用户：

小程序端不需要承担所有功能，它主要负责学生端的高频操作，管理类的功能还是放到 Django Admin 或者自建的 Web 管理端更高效。

2. 核心模型设计与数据库方案

2.1 数据模型设计

数据模型是整个系统的基础，设计不好后面改起来非常痛苦。支教管理系统的核心模型我建议这样设计：

python复制from django.db import models
from django.contrib.auth.models import AbstractUser

class UserProfile(AbstractUser):
    """扩展用户模型"""
    USER_TYPE_CHOICES = (
        ('admin', '管理员'),
        ('student', '学生'),
        ('teacher', '受援学校老师'),
    )
    user_type = models.CharField('用户类型', max_length=20, choices=USER_TYPE_CHOICES, default='student')
    phone = models.CharField('手机号', max_length=11, blank=True)
    student_no = models.CharField('学号', max_length=20, blank=True)
    school = models.CharField('所属院校', max_length=50, blank=True)
    college = models.CharField('学院', max_length=50, blank=True)
    
    class Meta:
        verbose_name = '用户信息'
        verbose_name_plural = verbose_name

class TeachingProject(models.Model):
    """支教项目表"""
    STATUS_CHOICES = (
        ('recruiting', '招募中'),
        ('ongoing', '支教中'),
        ('finished', '已结束'),
    )
    title = models.CharField('项目名称', max_length=100)
    location = models.CharField('支教地点', max_length=200)
    description = models.TextField('项目介绍')
    start_date = models.DateField('开始日期')
    end_date = models.DateField('结束日期')
    quota = models.IntegerField('招募人数')
    current_count = models.IntegerField('已报名人数', default=0)
    status = models.CharField('状态', max_length=20, choices=STATUS_CHOICES, default='recruiting')
    created_at = models.DateTimeField(auto_now_add=True)
    
    class Meta:
        verbose_name = '支教项目'
        verbose_name_plural = verbose_name

class VolunteerApplication(models.Model):
    """报名申请表"""
    STATUS_CHOICES = (
        ('pending', '待审核'),
        ('approved', '已通过'),
        ('rejected', '已拒绝'),
    )
    project = models.ForeignKey(TeachingProject, on_delete=models.CASCADE, verbose_name='支教项目')
    student = models.ForeignKey(UserProfile, on_delete=models.CASCADE, verbose_name='报名学生')
    motivation = models.TextField('报名动机')
    self_intro = models.TextField('个人简介')
    status = models.CharField('审核状态', max_length=20, choices=STATUS_CHOICES, default='pending')
    applied_at = models.DateTimeField(auto_now_add=True)
    reviewed_by = models.ForeignKey(UserProfile, on_delete=models.SET_NULL, null=True, blank=True, related_name='reviewed_applications')
    
    class Meta:
        unique_together = ('project', 'student')
        verbose_name = '报名申请'

这段代码里有两个容易忽略的细节：

UserProfile 继承 AbstractUser，这是 Django 推荐的自定义用户方式。你需要在 settings.py 里设置 AUTH_USER_MODEL = 'your_app.UserProfile'，并且必须在第一次 migrate 前完成设置，否则后面改起来会牵扯到数据库迁移，非常麻烦。

VolunteerApplication 里用 unique_together 约束了同一个学生对同一个项目只能报名一次，数据库层面做了唯一性校验，避免用户重复提交。这是我在实际开发中吃过亏后补上的，初期没有这个约束，有学生连点了两次报名按钮，生成了两条重复记录。

2.2 课程与课时安排的建模

支教课程表是一个典型的“一个项目多节课”结构，但这里有个设计上的坑：课程表的周期是固定的，还是可以由支教学生自己上传安排？

我建议做成两种模式兼容。项目发布时可以指定一个“按周排课”的固定课表模式，也可以开放“自定义课时”模式，由支教队长上传每日课程安排（包括上课时间、年级科目、对应讲师）。模型可以这样建：

python复制class CourseSlot(models.Model):
    """课时表"""
    project = models.ForeignKey(TeachingProject, on_delete=models.CASCADE, related_name='course_slots')
    course_name = models.CharField('课程名称', max_length=50)
    course_date = models.DateField('上课日期')
    start_time = models.TimeField('开始时间')
    end_time = models.TimeField('结束时间')
    teacher = models.ForeignKey(UserProfile, on_delete=models.SET_NULL, null=True, blank=True, related_name='teaching_courses')
    location = models.CharField('上课地点', max_length=100)
    note = models.CharField('备注', max_length=200, blank=True)
    
    class Meta:
        ordering = ['course_date', 'start_time']

课时表的意义不仅仅是排课，它还能作为后面“签到”和“志愿时长统计”的关联依据。每个课时可以继续扩展一个 AttendanceRecord 模型，记录学生是否到场、签到时间、代签标记等。

2.3 数据库迁移与初始化数据

模型设计完成后，几个操作顺序很重要：

1. 先在 settings.py 里配置好数据库连接（开发环境用 SQLite 就够，生产环境建议切到 MySQL）；
2. 执行 python manage.py makemigrations 生成迁移文件；
3. 执行 python manage.py migrate 生成数据表；
4. 执行 python manage.py createsuperuser 创建管理员账号；
5. 进入 Admin 后台录入测试数据。

如果用了 MySQL，建议在 settings.py 里额外设置 CONN_MAX_AGE=60，减少频繁建立数据库连接的开销。另外，字符集一定要配置成 utf8mb4，否则用户在小程序里输入 emoji 表情会直接报错：

python复制DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'teaching_db',
        'USER': 'root',
        'PASSWORD': 'your_password',
        'HOST': '127.0.0.1',
        'PORT': '3306',
        'CONN_MAX_AGE': 60,
        'OPTIONS': {
            'charset': 'utf8mb4',
        },
    }
}

3. 小程序端核心功能实现

3.1 微信登录：从 wx.login 到自定义登录态

小程序登录是支教系统用户身份识别的第一步。微信的登录流程本身不复杂，但很多初学者会在这里摔跟头，尤其是遇到“获取登录后的微信用户失败”这类报错时容易一头雾水。

整个登录链路是这样的：

1. 小程序端调用 wx.login() 获取一个临时凭证 code；
2. 小程序把 code 发送到 Django 后端；
3. 后端拿着 code 向微信接口 jscode2session 换取 openid 和 session_key；
4. 后端用 openid 查找或创建用户，生成本站的 token 返回给小程序；
5. 小程序把 token 存到 storage，后续请求都带上这个 token。

Django 端的核心代码可以这样实现：

python复制import requests
import hashlib
from django.conf import settings
from django.http import JsonResponse
from django.views.decorators.csrf import csrf_exempt
from .models import UserProfile

@csrf_exempt
def wx_login(request):
    """微信小程序登录接口"""
    if request.method != 'POST':
        return JsonResponse({'code': 405, 'msg': '请求方式错误'})
    
    code = request.POST.get('code')
    if not code:
        return JsonResponse({'code': 400, 'msg': '缺少code参数'})
    
    # 向微信接口换取 openid
    appid = settings.WX_APPID
    secret = settings.WX_APPSECRET
    url = f'https://api.weixin.qq.com/sns/jscode2session?appid={appid}&secret={secret}&js_code={code}&grant_type=authorization_code'
    
    resp = requests.get(url).json()
    openid = resp.get('openid')
    if not openid:
        return JsonResponse({'code': 500, 'msg': f'微信登录失败: {resp.get("errmsg")}'})
    
    # 使用 openid 查找或创建用户
    user, created = UserProfile.objects.get_or_create(
        username=f'wx_{openid[:20]}',
        defaults={'user_type': 'student'}
    )
    
    # 生成自定义 token（这里用 openid 的哈希值+随机盐）
    token = hashlib.sha256(f'{openid}{settings.SECRET_KEY}'.encode()).hexdigest()
    request.session[token] = user.id
    
    return JsonResponse({'code': 0, 'data': {'token': token, 'is_new': created}})

这里有一个重要的安全细节：** session_key 永远不要返回给小程序端，也不要存储到数据库只用于前端展示**。session_key 是微信用于解密用户手机号、UnionID 等敏感数据的密钥，一旦泄露到前端，攻击者可以利用它获取到用户的敏感数据。正确做法是在后端使用完就丢弃，不落库。

另外，get_or_create 用 username 作为查找条件是刻意为之。因为微信的 openid 差不多有 28 个字符，直接做用户名会超长，所以我截取前 20 个字符再加前缀。但这样做有问题：如果同一个 openid 前缀相同，可能碰撞。更稳妥的做法是给模型加一个 openid 字段，用 openid 做唯一键，而不是为了省事拼到 username 里。这块我在后期重构时改掉了，建议你直接一步到位。

3.2 请求封装与登录态失效处理

小程序的 wx.request 有太多重复代码，如果不加封装，每个页面都要写一遍 header 和 url 前缀，维护成本极高。我习惯在 utils/request.js 里统一封装：

javascript复制const BASE_URL = 'https://your-domain.com/api'

function request(path, method = 'GET', data = {}) {
  return new Promise((resolve, reject) => {
    const token = wx.getStorageSync('token')
    wx.request({
      url: BASE_URL + path,
      method: method,
      data: data,
      header: {
        'content-type': 'application/json',
        'Authorization': token ? `Token ${token}` : ''
      },
      success: (res) => {
        // 判断 token 是否过期
        if (res.statusCode === 401) {
          wx.removeStorageSync('token')
          wx.navigateTo({ url: '/pages/login/login' })
          reject(res.data)
          return
        }
        if (res.data.code !== 0) {
          wx.showToast({ title: res.data.msg, icon: 'none' })
          reject(res.data)
          return
        }
        resolve(res.data.data)
      },
      fail: (err) => {
        wx.showToast({ title: '网络异常', icon: 'none' })
        reject(err)
      }
    })
  })
}

module.exports = { request, BASE_URL }

所有接口统一走这个请求封装，好处是：登录态失效统一跳转登录页、错误提示不用每个页面重复写、接口地址统一管理。后续如果要加接口签名或者防重放机制，只需要改这一处。

3.3 单选框、表单校验与用户信息采集

支教报名表单是个典型的小程序表单场景：有输入框、有下拉选择、有单选框、有多行文本。这里有个使用原生组件时的细节：picker 组件在 iOS 和 Android 上的表现略有差异，特别是点击“取消”时返回的 change 事件要判断一下：

xml复制<picker mode="selector" range="{{colleges}}" bindchange="onCollegeChange">
  <view class="picker-value">{{selectedCollege || '请选择学院'}}</view>
</picker>

javascript复制onCollegeChange(e) {
  // 注意 e.detail.value 在取消时是 undefined，需要做兜底
  if (e.detail.value !== undefined) {
    this.setData({ selectedCollege: this.data.colleges[e.detail.value] })
  }
}

再强调一下，小程序的 picker 组件 bindchange 事件，当用户点击取消时也会触发，此时 e.detail.value 是 undefined。如果不判断，表单会出现“用户没选学院但显示了一个学院”的诡异问题。

支教报名表单里经常需要用户填写“可支教科目”“支教时间意向”等信息，这些用单选框和 checkbox 表现比较直观。提交前做表单校验也很关键，可以在小程序端写一个 validateForm 方法统一校验必填项，减少无效请求对服务器的压力。

3.4 消息推送：订阅消息的最佳实践

支教系统里有一个高频需求：管理员审核通过学生报名后，要通过微信通知到学生。微信小程序的消息能力是“订阅消息”，和公众号模板消息完全不同——小程序必须先让用户主动订阅，才能给用户下发消息，而且一次订阅只能下发一次。

这意味着你在设计功能时，不能只在后端“想发就发”，必须在前端引导用户完成订阅动作。比如在报名提交成功的回调里弹出一个订阅请求：

javascript复制wx.requestSubscribeMessage({
  tmplIds: ['YOUR_TEMPLATE_ID'],
  success(res) {
    // res['YOUR_TEMPLATE_ID'] === 'accept' 表示用户同意订阅
    if (res['YOUR_TEMPLATE_ID'] === 'accept') {
      // 后端记录该用户已订阅，后续审核结果可以推送
    }
  }
})

后端发送订阅消息时，需要先获取 access_token：

python复制def get_access_token():
    """获取微信全局access_token（需缓存）"""
    url = f'https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid={settings.WX_APPID}&secret={settings.WX_APPSECRET}'
    resp = requests.get(url).json()
    return resp.get('access_token')

access_token 有效期 7200 秒，且每天有获取次数限制，绝对不能每次发送都请求一次微信接口。我见过有人把 access_token 单独存数据库表，每次先查库再用，这个思路是对的，但实现上更优雅的方案是存 Django 的缓存中：

python复制from django.core.cache import cache

def get_access_token():
    token = cache.get('wx_access_token')
    if token:
        return token
    # 重新获取并写入缓存，过期时间设为 7000 秒
    token = request_wx_token()
    cache.set('wx_access_token', token, 7000)
    return token

订阅消息的发送本质上是把用户的 openid、模板 ID、页面跳转路径、数据组装好 POST 到微信接口。这里有一个长期存在的问题：用户如果订阅了但没有报名成功，或者报名了但已失效，推消息时就会报“用户拒绝接收消息”或“模板状态不正确”，这类失败得在后端做异常兜底，不要让报错影响主流程。

4. Django 后端接口与查询优化

4.1 接口风格选择：FBV 还是 CBV

Django 开发接口有函数视图（FBV）和类视图（CBV）两种风格，新手往往纠结怎么选。我的经验是：接口数量少、逻辑简单用 FBV，代码直观；接口数量多、且 CURD 模式明显用 CBV，可以继承 Django 自带的 ViewSet 减少样板代码。

如果是在 Django 里配合小程序做纯接口，不引入 Django REST Framework（DRF），我一般这样写路由和视图：

python复制from django.urls import path
from . import views

urlpatterns = [
    path('api/projects', views.project_list, name='project_list'),
    path('api/projects/<int:project_id>', views.project_detail, name='project_detail'),
    path('api/apply', views.apply_project, name='apply_project'),
]

python复制def project_list(request):
    """获取支教项目列表（分页）"""
    page = int(request.GET.get('page', 1))
    page_size = int(request.GET.get('page_size', 10))
    start = (page - 1) * page_size
    end = page * page_size
    
    projects = TeachingProject.objects.filter(status__in=['recruiting', 'ongoing']).order_by('-created_at')[start:end]
    total = TeachingProject.objects.filter(status__in=['recruiting', 'ongoing']).count()
    
    data = [{
        'id': p.id,
        'title': p.title,
        'location': p.location,
        'start_date': p.start_date.strftime('%Y-%m-%d'),
        'end_date': p.end_date.strftime('%Y-%m-%d'),
        'quota': p.quota,
        'current_count': p.current_count,
        'status': p.status,
    } for p in projects]
    
    return JsonResponse({'code': 0, 'data': {'list': data, 'total': total, 'page': page}})

如果不考虑引入 DRF，你可以用 JsonResponse 手动序列化数据，字段控制更精细。但如果项目里接口数量超过 30 个，强烈建议引入 DRF，它的序列化器、权限类、分页器能帮你省下大量时间。

4.2 删除对象时，请先想清楚 on_delete

Django 的 models.ForeignKey 必须指定 on_delete 参数，这个参数直接决定删除关联数据时的行为。支教系统里最常见的两个使用场景：

• on_delete=models.CASCADE：删除项目时，连同报名记录、课表一起删除。适合“项目废弃后不保留任何痕迹”的场景。
• on_delete=models.SET_NULL：删除用户时，保留他名下的课时记录，但把 teacher 字段置空。适合“学生退出支教后，课程表里不再显示其信息但保留课程记录”的场景。

我踩过一个坑：某次测试删除了一个支教项目，结果发现关联的学生报名表数据被连坐清空了，导致统计报表里的历史数据全部丢失。后来我把核心“操作日志”相关的外键统一改成了 PROTECT，删除时会主动抛错，需要先处理下游数据才能删除父表数据。对于支教管理系统，PROTECT 比 CASCADE 更安全，它能防止误删。

4.3 常用查询的优化技巧

支教系统有几个高频查询，它们会成为性能瓶颈，需要特别优化：

第一个是列表页的 N+1 查询问题。比如查询项目列表时，需要显示“每个项目报名了多少人”，如果在 ORM 里没有预取关联数据，很容易出现一次查询项目列表后，又对每个项目单独执行一次 count 查询。正确做法是使用 annotate：

python复制from django.db.models import Count

projects = TeachingProject.objects.annotate(
    apply_count=Count('volunteerapplication')
).order_by('-created_at')

这样一条 SQL 就搞定了，不会产生 N+1 次查询。

第二个是时间范围的筛选。支教课程表需要按日期范围查询，Django 的 __date 和 __range 非常方便：

python复制# 查询 2025 年 3 月 1 日到 3 月 7 日的课程
CourseSlot.objects.filter(
    course_date__range=['2025-03-01', '2025-03-07']
)

需要注意：__range 边界是包含的，也就是 >= '2025-03-01' AND <= '2025-03-07'，如果要排除当天，可以用 course_date__gte 和 course_date__lt 组合。

第三个是全文搜索。项目名称或地点的模糊搜索用 icontains，但它无法利用索引，数据量大了以后查询很慢。数据量超过 10 万条时，建议引入全文搜索引擎或者用 PostgreSQL 的 SearchVector。对于支教系统这个量级，前期用 icontains 没有大问题。

5. 部署上线与常见问题排查

5.1 宝塔面板部署 Django 项目

开发环境跑通后，部署上线是另一个大坑。我用宝塔面板部署过多个 Django 项目，可以给你一套成熟的路径。

第一步，准备服务器环境。在宝塔面板里安装 Python 3.8+、Nginx，以及 MySQL 或 SQLite 的运行时。宝塔的“Python 项目管理器”可以直接创建 Python 项目，选择 Python 版本后自动创建虚拟环境。

第二步，把项目代码上传到服务器，安装依赖：

bash复制pip install -r requirements.txt
python manage.py collectstatic
python manage.py migrate

这里特别提醒：collectstatic 必须执行，并且 settings.py 里要正确配置 STATIC_ROOT，否则 Django Admin 的样式文件会全部 404，后台管理页面会变成光秃秃的纯 HTML。

第三步，配置 WSGI。Django 项目用 gunicorn 作为生产服务器，宝塔里可以在 Python 项目管理器里直接配置启动命令：

bash复制gunicorn core.wsgi:application --bind 0.0.0.0:8000 --workers 2 --timeout 60

workers 的数量一般设置为 CPU 核心数×2+1，比如 2 核 CPU 就用 5 个 worker，不过对支教管理系统这个访问量级别，2 个 worker 完全够跑。

第四步，在 Nginx 里配置反向代理：

nginx复制server {
    listen 80;
    server_name your-domain.com;

    location /static/ {
        alias /www/wwwroot/your_project/static/;
    }

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

这个配置最核心的是 proxy_pass 指向 gunicorn 监听的端口，以及 location /static/ 指向 collectstatic 收集的静态文件目录。如果静态文件配置不对，打开 Django Admin 时所有 CSS 都会丢失。

5.2 小程序上线前的必要检查

小程序上线前，有几个环节是很多开发者容易漏掉的：

第一，request 合法域名必须配 HTTPS。小程序请求的接口地址必须是 HTTPS 域名，不能用 IP，不能有端口号（默认 443 可以），而且域名必须已经完成 ICP 备案。你需要在微信公众平台的小程序后台，进入“开发管理”->“开发设置”->“服务器域名”，把接口域名加到 request 合法域名列表里。

第二，注册和登录的开放能力。如果小程序里需要获取用户的手机号，这个能力需要企业主体的小程序才能申请，个人主体小程序无法调用 getPhoneNumber。支教系统的学生身份如果依赖手机号绑定，个人开发者要谨慎设计认证逻辑。

第三，真机测试与模拟器的差异。开发工具模拟器里的表现不能 100% 代表真机，特别是网络请求的 TLS 版本、定位授权、相册权限这些。建议在提审前用预览版在至少两台不同品牌手机上跑一遍核心流程。

5.3 上线前要不要做压力测试

小程序压力测试这个话题，我的答案是：分阶段看。

如果你这个支教系统只是校内社团用，并发量可能就几十人，压力测试不是必须的。用 locust 或者 wrk 简单压一下接口，确认系统在 100 并发以下不崩，就够了。如果你的系统要面向全校几千人同时报名，那压力测试必须做，而且要重点压“报名接口”和“课程列表接口”。

我用一个简单的 locust 脚本压过这种系统：

python复制from locust import HttpUser, task, between

class TeachingSystemUser(HttpUser):
    wait_time = between(1, 3)
    
    @task(3)
    def get_projects(self):
        self.client.get('/api/projects')
    
    @task(1)
    def apply_project(self):
        self.client.post('/api/apply', json={
            'project_id': 1,
            'motivation': '测试报名'
        })

压测的结果重点是看两个指标：接口的 P95 响应时间 和错误率。如果 P95 响应时间超过 1 秒，就要考虑加数据库索引、加缓存或者升级服务器配置。对 Django 后端来说，最简单的抗压手段是给查询频繁且数据变更不频繁的接口加缓存：

python复制from django.core.cache import cache
from django.views.decorators.cache import cache_page

@cache_page(60 * 15)
def project_list(request):
    # ...

cache_page 可以把整个列表页缓存 15 分钟，对报名高峰期的接口压力能显著缓解。缓存过期后需要接受请求回源，所以有一个权衡：希望数据实时性高，就不适合长缓存。

5.4 常见问题速查表

我把支教系统开发中遇到的高频问题整理成一个速查表，方便你排查：

5.5 开发环境的调试妙招

开发阶段建议在 settings.py 里加一个环境判断，开发时打开日志到控制台：

python复制LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
        },
    },
    'root': {
        'handlers': ['console'],
        'level': 'DEBUG',
    },
}

这样在本地跑 runserver 时，每次请求都会在终端打印出 SQL 语句和请求信息，方便排查 ORM 查询问题。Django 的 connection.queries 里也保存了当前请求执行的所有 SQL，配合 Debug Toolbar 简直不要太舒服。

另外，小程序开发者在调试接口时，可以用微信开发者工具里的“不校验合法域名”开关，避免部署域名还没配置好时反复在手机上测试。但注意这只是本地调试用的，真机预览或提审时必须关闭。

最后分享一个我的个人经验

支教管理系统这个项目做完之后，最大的收获不是因为用了 Django 和小程序这两个技术栈，而是明白了“简单业务也要有复用的思维”。支教系统的核心实体就是“项目—报名—课程—反馈”这条线，很多校内管理系统都能抽象出类似的结构。你把它做透了，下一套社团活动管理系统、志愿服务活动管理系统，改改模型和字段基本就能跑起来。

开发的过程中，我最深的感受是：不要让“看起来简单”的业务骗了你。报名审核、课表安排、状态流转，每个环节都有边界情况要处理。多花时间画清楚业务流程图、理清状态机，比急着写代码更重要。后端 Django 的成熟稳定，加上小程序端的分发便捷，是这类校园管理系统的绝佳组合，也特别适合作为新手完整掌握前后端全栈开发的练手项目。