培训机构课程报名选课管理系统：微信小程序+Django后台实战

别被“培训机构课程报名选课管理系统”这个标题吓到，拆开看其实就是三件事：课程、选课、报名。但真正动手做的时候会发现，难点根本不在功能多少，而在业务角色怎么分、数据怎么串、以及微信小程序生态里那些绕不开的坑。我前后做了两版，第一版是典型的毕设思维，课程表、订单表、用户表一建就开写，结果一到排课冲突和老师端权限就崩。第二版才想明白，这种系统本质上是“排课 + 报名 + 管理”的三角闭环，小程序只是入口，真正的主战场在后台。

这篇文章就把我第二版的完整思路和实现过程拆开讲，从业务角色设计到数据库表结构，再到小程序端和后台管理端的核心代码，最后是微信支付、订阅消息、部署上线这些容易被忽略的环节。你如果是拿来做毕业设计，可以直接照抄这套架构；如果是机构真实要用，我也会把权限控制、课时统计、退课审核这些生产环境才需要的细节一并说清楚。

1. 项目整体设计与思路拆解

1.1 核心需求从哪里开始拆

培训机构业务，不管是少儿编程、成人职场技能还是艺考培训，日常运转都绕不开这几个人：来咨询报名的学员（或者学员家长）、负责卖课和排课的运营/教务老师、真正讲课的授课老师、以及偶尔要看一下数据报表的机构老板。

大多数人设计这类系统时容易犯一个错误——默认只有“管理员”和“用户”两种角色，把所有管理功能都堆在后台。但真实场景里，前端小程序的使用者不仅有学员，还有授课老师。老师需要用手机查看自己的课表、确认上课、标记学员出勤，这些操作如果都要跑回后台操作，教务老师的日常工作会被频繁打断。

于是我在角色设计上做了一个关键拆分：系统分三个端，学员/家长用微信小程序端完成浏览课程、提交报名、在线支付、查看课表；教务管理用后台管理端完成课程上下架、排课、审核报名、退课处理；授课老师有一个简化版的小程序端入口，只看自己的课表和学生名单，做签到确认。

这个拆分的直接好处是权限边界清晰。一位老师登录后台去改课程价格或者调整另一个老师的排课，这类越权操作从产品设计层面就被杜绝了，代码层面只需要按角色校验接口权限就行。

1.2 为什么选了“课程 + 排课 + 订单”三角模型

我第一版失败的原因，是把“课程”和“排课”当成了一张表。课程基础信息确实相对稳定，比如课程名称、适合年龄段、总课时数，但它一旦绑定到具体的上课时间、上课老师、上课教室，就变成了一条独立的业务记录。

举个例子，一套“Python 入门班”课程标准价是 2999 元，每周六上午两个课时，教务老师安排李老师带这个班，教室是 A03。一周后招生火爆，又开了一个周六下午的新班，还是李老师带，但换成了 A05 教室。如果课程和排课是一张表，数据会冗余得没法维护；分开了就清爽得多：课程表只存课程本身的信息，排课表每条记录 = 课程 + 具体时间段 + 老师 + 教室 + 剩余名额。

订单表则是连接学员和排课记录的桥梁。一个学员可以一次性报一个学期的课，也可以单次报名某一节体验课，订单明细里记录的是“哪个排课班级”，这样退课、转班、补课才有据可依。

这个模型想清楚之后，后面所有接口的设计都顺了。学员端看到课程详情页时，其实展示的是某个排课班级的信息，包括剩余名额、上课时间、授课老师介绍，不再是笼统的课程介绍。

1.3 技术选型没有用“最热”的，而是用“最顺”的

朋友圈里不少人做小程序后端喜欢直接用微信云开发，确实省事，数据库、存储、云函数一步到位。但我建议对这个项目谨慎一点，原因有二：数据模型复杂之后，云开发的数据库查询能力和索引机制在联表查询和统计报表场景下会比较别扭；另外你以后想把系统迁移到自己的服务器，或者接入第三方的教务硬件（比如人脸识别考勤机），云开发迁移成本会很高。

我更推荐常规方案：后端用 Python 写，小程序端用原生微信小程序（或者 uni-app 也可以），数据存储用 MySQL，后端框架用 Django REST Framework 或者 Flask + SQLAlchemy 都可以。我这次用的是 Django REST Framework，理由很实在：Django 自带的 Admin 后台可以直接当教务管理端用，省去一大块后台前端开发工作量；它的 ORM 做课程、排课这类复杂关系查询很顺手；用户认证和权限体系成熟，不需要自己造轮子。

当然，如果你后台管理端想做得更灵活、界面更好看，可以用 Vue + Element Plus 单独搭一个管理后台，Django 只作为 API 服务。我在第二版就是这么做的，后面会讲原因。

2. 核心细节解析与实操要点

2.1 数据库表结构设计是这整套系统的地基

先给出一份我反复调整后的核心表结构设计，比直接列建表 SQL 更有参考价值。

学员用户表（StudentProfile）除了微信用户的 openid、昵称、头像外，关键字段有：学员姓名、年龄、家长手机号、剩余课时数、报名来源。这个“剩余课时数”是冗余字段，从订单和退课记录里理论上可以算出来，但真实场景里课时数被查询的频率太高，每次实时计算会对数据库造成很大压力，所以我在每次报名成功、退课成功、老师标记出勤时都会同步维护这个字段。

课程表（Course）：课程名称、课程分类（编程/美术/舞蹈等）、适合年龄段、课程简介、封面图、总课时数、标准价格、状态。状态字段我习惯命名 status，有两种值，上架和下架。

排课班级表（CourseSchedule）：这表是排课管理的核心。外键关联课程 ID，字段包括班级名称（如“Python 入门周六上午班”）、上课星期、开始时间、结束时间、开课日期、结课日期、授课老师 ID、教室、人数上限、已报名人数、当前状态。注意，上课星期、时间段、教室这些字段不能做成分散表——一个排课班级一周只上一次课，这是绝大多数培训机构的基本设定，不用过度设计成每周多天的复杂模式。

订单表（Order）：订单号、学员用户 ID、关联的排课班级 ID、支付金额、支付状态、支付时间、订单类型（新报名/续费/退课）、退课状态、退课原因、审核人、审核时间。订单号我建议用“日期 + 随机数”的方式生成，别用数据库自增 ID，因为自增 ID 容易被猜到，产生无关的数据暴露风险，而且微信支付回调对订单号也有要求。

选课记录表（Enrollment）：这个表容易被人忽略但它非常关键，记录学员和排课班级之间的状态变化。字段包括学员、排课班级、报名时间、课时数变动、状态（在学/结课/退课）。很多需求里要查“一个学员报过哪些班”“一个班有多少学员在学”，都要靠这张关联表，比直接查订单表语义更清晰。

课时/出勤表（Attendance）：授课老师标记出勤的记录。一个班级的某节课，有哪些学员出勤，谁请假了，谁旷课了。老师在手机端确认这节课上完之后，系统会按出勤情况扣减学员剩余课时。

2.2 微信登录的 code 换 session 流程别踩坑

小程序端登录是几乎所有微信小程序开发的第一步，也是初次接触时最常见的一个“看起来简单但很啰嗦”的环节。流程是固定的：小程序端调用 wx.login 获取一个临时 code，然后把 code 发给后端；后端拿 code 加上小程序的 AppID 和 AppSecret 去微信接口服务换 openid 和 session_key。

用 Django REST Framework 实现的时候，我建议把登录做成一个独立接口，在视图中完成以下逻辑：调用微信接口后拿到 openid，先去数据库查这个 openid 是否已经存在，不存在则自动创建用户；然后把用户主键、openid 和自己签发的 token 一起返回给前端，前端后续请求都带这个 token，不再直接依赖微信的 session_key。

这里有一个实操上的细节值得提醒：微信小程序的 code 只能使用一次，有效期为五分钟，如果前后端调试时出现 code 无效的报错，大概率不是因为逻辑写错了，而是 code 被重复使用，或者后端接口被前端调用了两次。另一个点是 session_key 不要存储到数据库，它是微信侧维护登录态用的敏感数据，后端只需要在每次登录时拿到 openid 即可。后续如果需要解密手机号、获取用户信息，才需要 session_key，而且必须做到用后即弃。

2.3 接口权限控制用 Django 的 Permissions 机制

前面提到角色拆分成学员、老师、教务管理员，这套权限落到代码上，Django REST Framework 的权限类提供了非常顺手的工具。

我的做法是自定义三个权限类：IsStudent、IsTeacher、IsAdmin。在基础用户模型上加一个 user_type 字段，用整数区分角色。视图层在需要限制学员权限的接口上加 permission_classes = [IsStudent]，老师权限的接口加 [IsTeacher]。

实际开发中要注意一点，小程序端的学员用户和后台管理端的登录用户，尽量不要放在同一个 Django User 表里，除非你是前后端一体化的小项目。我的处理是：学员用户走微信登录，用 StudentProfile 模型扩展；后台管理端用户用 Django 自带的 User + Group 管理。两套登录体系互相独立，后台管理员可以查看学员数据，但不需要用学员身份去调小程序的接口。这样权限边界更清晰，也避免微信用户表和管理员表混在一起之后，管理端后台列表页被大量数据污染。

3. 实操过程与核心环节实现

3.1 搭建 Django 项目和数据库结构

环境准备不啰嗦，Python 3.10 + Django 4.x + Django REST Framework + MySQL 8.0，虚拟环境用 venv 或者 conda 都可以。Windows 用户注意，MySQL 的 Python 驱动建议用 pymysql，并且在项目的 init.py 文件里加一段 pymysql.install_as_MySQLdb()，否则 Django 会直接报错找不到 MySQLdb 模块。

创建项目和应用之后，依次创建前面说的几组模型。这里我给出课程的模型代码作为示范，其他模型的写法是同一个套路：

python复制from django.db import models


class Course(models.Model):
    STATUS_CHOICES = (
        (1, '上架'),
        (0, '下架'),
    )
    name = models.CharField('课程名称', max_length=100)
    category = models.CharField('课程分类', max_length=50)
    age_range = models.CharField('适合年龄段', max_length=50, blank=True)
    intro = models.TextField('课程简介', blank=True)
    cover = models.ImageField('封面图', upload_to='course_covers/', blank=True)
    total_period = models.IntegerField('总课时数', default=0)
    price = models.DecimalField('标准价格', max_digits=8, decimal_places=2)
    status = models.IntegerField('状态', choices=STATUS_CHOICES, default=1)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        db_table = 'course'
        verbose_name = '课程'
        verbose_name_plural = verbose_name

有几点值得提。第一，price 字段不要用 FloatField，金额的浮点误差在后续对账时非常头痛，DecimalField 才是金额的标配。第二，数据库表名我习惯用 db_table 显式指定为不含应用前缀的小写单词，因为 Django 默认的表名格式是“应用名_模型名”，比如 course_management_course ，做复杂 SQL 查询或别人接手时看着很乱。其实改成什么风格关键是一致，定了就不要在后期改表名，否则所有外键关联都要跟着动。

定义完模型后执行 makemigrations 和 migrate，把表建出来。建议此时就用 Django 自带的管理后台创建一个超级管理员账号，先登录后台上传几条课程数据，这样后面开发小程序接口时可以直接看到效果。

3.2 排课功能的后端实现

排课是整条业务线复杂度最高的部分，核心难点是排课冲突校验。同一个老师在同一个时间段不能同时上两门课，同一个教室也不能同时被不同班级占用。校验逻辑放在前端没有任何意义，必须由后端在做数据插入更新时严格执行。

我实现的方法是写一个独立的校验方法，在创建和更新排课记录时调用。校验时取出符合条件的已有排课记录，重点判断星期字段和时间区间是否重叠。代码层面的处理方式如下：

python复制def check_schedule_conflict(teacher_id, weekday, start_time, end_time, schedule_id=None):
    schedules = CourseSchedule.objects.filter(
        teacher_id=teacher_id,
        weekday=weekday,
        status=1,
    ).exclude(id=schedule_id)

    conflict = False
    for s in schedules:
        # 判断时间段是否有交集
        if start_time < s.end_time and end_time > s.start_time:
            conflict = True
            break

    if conflict:
        raise ValidationError('该老师在这个时间段已有排课，请更换时间或老师')

    # 同理由对教室做一遍校验
    classroom_schedules = CourseSchedule.objects.filter(
        classroom=classroom,
        weekday=weekday,
        status=1,
    ).exclude(id=schedule_id)
    for s in classroom_schedules:
        if start_time < s.end_time and end_time > s.start_time:
            raise ValidationError('该教室在这个时间段已被占用')

时间段交集的判断逻辑值得展开说一下。两个区间有交集的条件是“一个区间的开始早于另一个区间的结束，并且它的结束晚于另一个区间的开始”，这个判断包含了首尾相接的情况，比如 10:00 到 10:30 和 10:30 到 11:00，它们没有真正的时间重叠，但按这个写法会被判断为冲突，因为 start_time < s.end_time 成立且 end_time > s.start_time 也成立。

实际运营中一个老师连续上两节课（即 10:30 结束紧接着 10:30 开下一班）是完全合理的场景，所以真正实现时要根据业务规则选择开区间或闭区间比较。我在项目里允许首尾相接，判断条件改为 start_time >= s.end_time or end_time <= s.start_time，满足这个条件就不冲突，否则冲突。

排课创建成功后，学员端的课程列表接口会自动把该排课班级的状态展示给用户。前端不需要做过多的判断逻辑，排课班级是“招生中 / 已满员 / 已开班/ 已结课”这几种状态，由后端根据时间自动推进，前端只负责展示。

3.3 选课报名与订单生成的完整链路

学员在小程序端看到排课课程点击报名时，后端执行的操作不是简单插入一条订单记录，而是一个带有事务处理逻辑的完整流程，大概可以拆成这些步骤：

第一步校验学员身份和课程状态。排课班级状态必须是“招生中”，如果已经满员要直接返回友好错误。第二步锁定排课记录。这里我用 Django 的 select_for_update 对排课班级记录加行级锁，这是多用户同时抢报时防止超卖的关键。第三步创建订单，订单状态初始为“待支付”。第四步如果学员余额充足，可以直接用余额扣款，否则转到微信支付。

用 select_for_update 时务必注意它必须在事务内使用，否则不会真正加锁。在 Django 中我习惯用 transaction.atomic 装饰器包裹整个报名方法。还有一个并发场景容易忽视：同一学员同一排课班级重复报名。一定要用唯一约束来兜底联合索引，不能只靠代码逻辑里的 if 判断，因为两个请求同时通过判断时会产生重复数据。我在 Enrollment 表上加过 UniqueConstraint，字段是 student 和 schedule，这是防重复最关键的一道防线。

事务处理伪代码逻辑大致是这样：

python复制from django.db import transaction

@transaction.atomic
def create_enrollment_order(student, schedule_id):
    schedule = CourseSchedule.objects.select_for_update().get(id=schedule_id)
    if schedule.status != 'enrolling':
        raise ValidationError('该班级当前不可报名')

    if schedule.enrolled_count >= schedule.max_students:
        raise ValidationError('该班级名额已满')

    if Enrollment.objects.filter(student=student, schedule=schedule).exists():
        raise ValidationError('你已经报过这个班级了')

    order = Order.objects.create(
        student=student,
        schedule=schedule,
        amount=schedule.course.price,
        order_type='new',
        status='pending',
    )

    schedule.enrolled_count += 1
    schedule.save(update_fields=['enrolled_count'])
    return order

这里有一个细节经常被忽略——enrolled_count 是已报名人数。既然 Enrollment 表里已经可以算出报名人数了，为什么还要维护这个冗余字段？因为课程列表页要按“剩余名额”排序和筛选，这是一个高频操作，如果每次都对 Enrollment 表做 Count 聚合，数据库会非常吃力。这种冗余字段带来的写入开销是可以接受的，查询效率提升却很明显。

3.4 微信小程序端课程列表与课程详情实现

小程序端我用的是原生微信小程序框架，没有引入额外的 UI 组件库（虽然 Vant Weapp、TDesign 这些库很流行，但我希望代码演示起来更直接，减少依赖安装的环节）。页面结构上，课程列表页和课程详情页是最核心的两个页面。

课程列表页通过 wx.request 请求后端接口，接口返回的是排课班级的列表而非课程列表，因为用户真正关心的是“什么时候上课、是否还有名额、谁带课”。页面用 scroll-view 做分类切换，筛选条件如“全部 / 编程类 / 美术类”，筛选工作直接交给后端通过 query 参数实现，不在前端把所有数据拉来本地过滤。

课程详情页的数据通过订单接口的 schedule_id 参数去拉。页面底部放一个固定的报名按钮，按钮文案根据排课状态动态变化：“立即报名 / 已满员 / 已结课”。报名按钮点击后先检查用户是否已经登录，未登录则跳转登录页并引导用户完成微信授权。

以下是小程序端请求封装的精简示例：

javascript复制function request(url, method = 'GET', data = {}) {
  return new Promise((resolve, reject) => {
    wx.request({
      url: API_BASE_URL + url,
      method,
      data,
      header: {
        'Authorization': 'Token ' + wx.getStorageSync('token')
      },
      success: (res) => {
        if (res.statusCode === 200) {
          resolve(res.data);
        } else if (res.statusCode === 401) {
          wx.navigateTo({ url: '/pages/login/login' });
          reject(res.data);
        } else {
          reject(res.data);
        }
      },
      fail: (err) => reject(err)
    });
  });
}

统一封装 request 方法的收益在后端上线后非常明显。我在 headers 里统一加了 Authorization 字段，后端通过 Django REST Framework 的 TokenAuthentication 识别用户，后续几乎不用在每个页面里重复写鉴权代码。遇到 401 时统一跳到登录页，也不会出现某个页面登录过期但其他页面状态正常而导致的混乱。

4. 常见问题与排查技巧实录

4.1 “名额超卖”问题是怎么避免的

做第一版时，用户同时点击报名，我天真地以为只要在事务里先查一下已报名人数再做新增就安全了。后来压测才发现，两个请求同时进来，各自都查询到剩余名额还有 1 个，然后同时写入了两条报名记录，等真要上课时才发现超过人数上限。

后来彻底解决这件事的，就是我前面讲的 select_for_update 加行锁，再加 Enrollment 表上的唯一联合索引，双重保证。教训是：涉及到名额、库存、金额这些敏感数据的并发写入，不要只靠“查-再写”这种两层逻辑，必须依赖数据库层面的锁、唯一约束或条件更新来兜底。

4.2 微信支付回调的掉单处理

订单创建成功但用户支付后小程序端一直显示“待支付”，或者后台查不到支付成功的订单，这是支付对接最常见的故障。微信支付流程里，支付成功后微信服务器会向你的回调地址发一个异步通知，你的后端必须在收到通知后更新订单状态。如果回调地址不可达、代码处理出错后没有返回成功应答，微信会多次重试，稍后又来一次，直到你处理成功。

我做这套流程时的经验是，回调接口一定做成幂等的：不管同一个订单的回调通知来几次，最终数据库里的订单状态都是支付成功，而且只能扣减一次课时。在回调里先用订单号查一次订单，如果订单状态已经是已支付，直接返回成功应答，不重复处理业务。否则一旦断网重试，学员就会发现课时被扣了两次，这种错误非常致命。

微信支付 v3 接口的签名机制比较绕，官网文档习惯先讲概念再给代码，让我绕了不少圈子。这里提供一个简化思路：用官方提供的 wechatpay-python 库，它封装了签名和验签逻辑，比手动拼签名容易得多。确认订单时用订单号调用查单接口，判断订单状态为 SUCCESS 后再更新本地订单。尤其注意不要使用商户密钥直接解密回调报文，v3 的敏感信息用的是 APIv3 密钥做 AES-256-GCM 解密，把密钥配置错误，回调里就什么都看不见。

4.3 数据库事务在报名场景里的使用限制

事务保证了原子性，但事务并不能解决所有并发问题，也不是随便往哪一包就能万事大吉。Django 的 transaction.atomic 必须与 select_for_update 搭配才能实现真正的行锁效果，只包事务不加锁，隔离级别默认情况下仍可能产生幻读，导致多插入一条数据。

另外，select_for_update 锁定的行一定是在事务内第一次查询到的，如果业务逻辑中途又换了条件去查同一条记录，很可能不会被锁住。我曾经在开发中遇到过一次排查了很久的问题：先按 schedule 查了记录，后面又因为业务需要按 course 关联查排课，结果第二个查询查到同一条记录，由于不是 select_for_update，并发时还是出现了重复报名。解决办法是把所有需要保护的查询统一都写成 select_for_update，并且保证它们挂在同一个事务里。

4.4 小程序体验版请求接口报“不在合法域名列表”的解决办法

调试小程序时最常见的报错是“request:fail url not in domain list”。小程序运行在微信客户端时，wx.request 只能请求已经配置到微信公众平台后台 request 合法域名里的地址。开发过程中，在开发者工具里可以勾选“不校验合法域名”，但真机预览或体验版时这个选项无效。

解决方法是把后端的 API 地址配置为 HTTPS 域名，并确保域名有备案。如果你的项目还没上线，只是想快速验证，可在微信公众平台的“开发管理 - 开发设置 - 服务器域名”里把已备案域名先加进去，但要求该域名已经完成 ICP 备案，且必须开通 HTTPS。没有现成域名就用内网穿透工具将本机暴露到公网，但要记得微信不允许使用 IP 地址加端口形式，必须用域名。

你在开发环境用 localhost 调通接口，不代表换成 https 就可以了，接口可能跨域问题、SSL 证书信任问题接踵而至。我的真实经验是，把接口部署到一个便宜的轻量云服务器上，域名加上免费的 SSL 证书，从第一天开发就用这个正式地址，后期会少浪费很多时间。

5. 后台管理端的设计与实现要点

5.1 Django Admin 作为基础管理端的配置思路

如果你的目标是快速完成一个可用系统，我建议不要单独开发管理后台前端，直接用 Django Admin 把数据管理能力做出来即可。Django Admin 对课程表、排课表、订单表、学员表这套结构有天然支持，需要做的无非是注册模型、配置列表展示字段和筛选器。

在 admin.py 里给排课班级注册一段管理展示逻辑：

python复制from django.contrib import admin
from .models import CourseSchedule


@admin.register(CourseSchedule)
class CourseScheduleAdmin(admin.ModelAdmin):
    list_display = ('class_name', 'course', 'teacher', 'weekday', 'start_time', 'end_time', 'enrolled_count')
    list_filter = ('course', 'weekday', 'status')
    search_fields = ('class_name', 'course__name', 'teacher__name')
    raw_id_fields = ('teacher',)

要注意的是，排课列表页的数据量一旦上来，外键关联字段默认以下拉框形式展示会比较卡，配置 raw_id_fields 后在界面上会把下拉框换成 ID 输入框加放大镜按钮，通过弹窗搜索选择数据。后台教务人员用了都说比下拉框好使。

5.2 课时扣减与签到确认的实现逻辑

授课老师签到是业务闭环里容易被遗忘但在真实运营中极其重要的功能。每节课下课后，老师打开自己端的排课班级详情，能看见这节课应到学员名单，然后逐个标记出勤或请假。

这个标记动作在后端由两个核心步骤组成，第一步写 Attendance 记录，第二步更新学员的剩余课时数。出勤则扣 1 个课时，请假不扣（或者根据机构规则扣，这个逻辑可通过配置切换）。因为涉及金额和课时资产变动，同样需要放在事务里执行，并且对同一个学员同一天的同一门课，需要用唯一约束避免重复签到。

课时扣减的规则在不同机构不一样。有的机构按次扣费，一节课扣一次；有的机构按课时包扣费，一节课扣一个固定课时数。我的字段设计里预留了扣减课时数的字段，由后台管理员在排课时设定，代码只负责按设定值扣减，不在业务逻辑里写死。

5.3 排课日历视图能大幅提升教务老师的使用体验

给教务老师做的排课管理页中，最受欢迎的是日历视图。教务排课时最怕“感觉这个时间段没课”，实际一查发现老师和教室都被占了。日历视图让老师在同一个界面上看到每天每个时间段占用情况，从源头降低排课冲突概率。

后端接口返回一个时间段的数据集合，前端以周为单位渲染横向为星期、纵向为时间段的表格。排课冲突校验仍然不能省，因为日历视图只是辅助展示，即使是手动选择的排课操作，在后端落库时还是会执行冲突校验，否则多人同时操作时仍可能产生问题。

6. 部署上线与真实运营避坑指南

6.1 服务端部署的合理路径

对于培训机构这种体量，用一台 2 核 4G 的云服务器完全够撑初期几百个学员的访问量。操作系统选 Ubuntu 或者 CentOS 都行，安装 Nginx、MySQL、Redis、Python 环境。运行方式我建议用 Gunicorn 启动 Django，Nginx 负责反向代理和静态文件，HTTPS 证书用 Let‘s Encrypt 自动续期。

部署时容易遗漏的一个问题是 Django 的 settings.py 里 DEBUG = False 之后，静态文件不会自动由 Django 处理，需要额外执行 collectstatic，并且配置 STATIC_ROOT 和 STATIC_URL。如果你管理后台用了 Django Admin，这一步漏掉，管理后台页面会变成没有任何样式的纯文本页面。

6.2 微信小程序上线前需要检查的配置清单

小程序在体验版和正式发布之间，有一段“提交审核”的流程，不少人是这个阶段发现问题只能反复改代码。为了少走两轮审核来回，上线前一定要做足自查。

第一是隐私协议。如果你在小程序里收集了学员手机号、姓名、头像等信息，微信要求配置用户隐私保护指引，并且在代码里调用相关接口时触发隐私弹窗。第一版往往漏掉这个，结果审核退回。

第二是用户身份信息获取的调整。微信官方这几年持续收紧 wx.getUserInfo 的能力，现在一次性弹出获取昵称头像的方式已经在很多基础库上失效了。正确方式是使用头像昵称填写能力，让用户主动填昵称、选头像，或者通过手机号快速验证组件直接获取手机号。如果你的培训机构需要学员手机号作为后续联系凭证，建议优先用“手机号快速验证组件”，别用传统的 bindgetphonenumber 方式——新版基础库要求必须是企业认证的小程序才能使用。

第三是订阅消息。机构经常要给学员家长发开课提醒、调课通知，这条推送链路依赖小程序的订阅消息。模板消息需要提前在微信公众平台申请模板，拿到模板 ID 后再后端调用。重要的注意点是，订阅消息必须由用户主动触发授权动作，一次性订阅只能推送一条，长期订阅只有特定行业类目才开放。培训机构如果想要稳定的上课提醒服务，最好设计成用户每次报名或查看课表时主动点一次“允许上课提醒”，后面才能把提醒推送补满。这也是为什么我在报名成功页专门加了一个“开启提醒”的按钮。

6.3 真实上线后的数据与运营提醒

微信小程序虽然有云开发这种相对省心的后端方案，但这个系统因为涉及后台管理和复杂数据关联，我最终还是选择自建服务器接口。上线后我开始维护一份运营日报，每天早上看关键数据，当日新增注册学员数、新增报名订单数、支付成功率、退课率、各课程报名转化率。Django Admin 里就能看到大部分数据，但要在管理后台内做可视化报表需要不少前端工作量。初期我用一个简单方案：每日定时脚本统计关键数据，写入一个统计数据表，然后在管理后台里挂一个简单页面展示数字就够了。等机构规模变大、管理者需要趋势图和 Excel 导出时，再开发更复杂的报表模块。

另一个容易被忽视的点是课程数量与用户选择的平衡。系统上线后教务老师习惯性地上架很多课程，但我发现小程序端用户的选择成本反而增加了。首页只能放七八个排课比较合适，超过十个之后，报名转化率会有明显下降。后来干脆把“本周热招”设计成后端可配置的入口，教务老师在后台把重点推的课程置顶。好系统是工具，好运营才算真正盘活整个招生和排课的生意的关键。

7. 我的实战心得与二次开发建议

做完这一整套系统，最大的体会是：别被“微信小程序”这四个字带偏了。这个项目表面在小程序，真正的核心价值在后台业务设计。报名和选课的链路仅仅是前端交互展示，排课、课时、退费、权限这些后台逻辑才决定系统是否能真实落地。

对于毕业设计，建议可先实现：Python 后端搭建课程与排课相关的增删改查接口、微信小程序端课程列表和详情与报名页面、模拟支付流程。能把这些完整跑通，已经是一份优秀且有逻辑闭环的毕设。

对于真实商用，建议在此基础上要补充：企业微信或短信通知渠道、学员合同和发票管理、多校区支持、老师课时工资结算。哪怕每项都先做个简化版本，机构负责人都会觉得这套系统能长线用下去。

最后分享一个实用的小工具建议：Django 的 manage.py shell_plus（需要装 django-extensions）比 manage.py shell 好用非常多。调试排课逻辑或者手动补单时，直接在 shell 里敲模型查询就能立刻看到结果，也可以快速造一批测试数据，比一行行写 SQL 舒服得多。这个工具我从开始做这个系统一路用到现在，没有它调试效率至少下降三成。

数据模型清晰了，事务边界把住了，支付回调的幂等做好了，这个系统基本就稳了。剩下的事，就是让上课的人方便上课、管课的人方便管课、卖课的人方便卖课，整个机构的日常就能顺畅转起来了。