企业官网建设流程全解析

1. 项目整体设计与核心需求拆解

1.1 这个抽奖系统到底解决什么问题

先说结论：这个系统解决的是校园活动里最让人头疼的“现场抽奖怎么搞”的问题。我见过太多活动主办方的操作方式——要么用纸质抽奖箱，人工抽号，效率低还容易被质疑公平性；要么直接拿第三方抽奖工具凑合，但那些工具没法管理复杂的奖品分级、多轮抽奖和用户身份验证。做一个校园活动抽奖系统，核心目标就是用微信小程序作为入口，让活动主办方可以快速创建一场抽奖活动，设置奖品、规则，参与者扫码进场后自动获得抽奖资格，开奖结果实时推送到小程序里，整个过程轻松、透明、可追溯。

从标题能看出技术选型很明确：后端用 Python Django，前端用微信小程序。这个组合在校园场景里特别合适——学生群体几乎人人都有微信，小程序无需下载安装，扫码即用，不存在适配成本。Django 自带的 Admin 后台让活动主办方（哪怕是学生干部，不一定懂技术）也能很方便地管理奖品和活动数据。整体复杂度适中，一个人从零开发到联调部署，两三周可以跑通。

1.2 技术选型背后的取舍逻辑

为什么是 Django 而不是 Flask 或者 Spring Boot？在这个场景下，Django 自带的 ORM、Admin 后台、认证系统都是现成的。抽奖系统最怕的是用户越权操作——比如学生尝试调接口把自己的中奖概率改掉。Django 的权限框架可以给不同角色分配不同权限，Admin 后台天然隔离了管理端和用户端。同时 Django 的 ORM 在处理并发写操作时比裸写 SQL 更安全（事务控制方便），而校园抽奖场景下，开奖那一瞬间会有大量用户同时请求，并发控制做好了才能避免“超发奖品”这种事故。

微信小程序选的是原生小程序框架，而不是用 uni-app 或者 Taro。原因很简单：这个项目逻辑不复杂，页面就那几个（活动列表、活动详情、抽奖结果、个人中奖记录），原生小程序完全够用，还省掉了跨端框架带来的编译问题。如果未来要扩展到 App 端，再迁移也不迟。

1.3 核心流程与角色划分

这个系统涉及三类角色：

• 活动主办方（管理员）：创建活动、设置奖品、配置抽奖规则、查看中奖名单、导出数据
• 参与者（学生）：查看活动、报名参与、参与抽奖、查看中奖结果
• 系统后台（开发视角）：处理微信登录、校验用户身份、维护活动状态、执行抽奖算法

核心业务闭环是：管理员创建活动 → 设置奖品及中奖概率 → 分享小程序码 → 学生扫码进入活动页 → 授权登录并报名 → 活动开始 → 管理员点击“开奖”或到达开奖时间自动开奖 → 系统执行抽奖算法 → 中奖结果实时推送 → 参与者在小程序里查看结果并在现场领取奖品。

这个流程最关键的节点就是“开奖那一刻”。校园活动经常有领导讲话超时、节目时间不可控的情况，所以抽奖系统必须支持手动开奖和定时开奖两种模式。手动开奖适合现场灵活控制节奏，定时开奖适合提前设定好某个时间点自动抽。我在设计时把这两个模式都做成可配置的，这样无论活动现场怎么变，主办方都能应对。

2. 数据库设计与活动模型

2.1 数据表结构规划

数据库是这个项目的灵魂。我踩过不少坑，比如一开始设计表结构的时候少考虑了几个字段，后续加需求导致频繁迁移数据库。这里把最终稳定的表结构整理出来，直接照着设计就可以。

第一张核心表是Activity（活动），字段包括：活动标题、活动描述、开始时间、结束时间、开奖方式（手动/定时）、状态（筹备中/进行中/已结束）、参与人数上限、发布状态、封面图URL、创建时间。还有一个容易忽略的字段——activity_code，用于生成专属小程序码，方便推广区分不同活动。

第二张重要表是Prize（奖品），字段包括：所属活动ID、奖品名称、奖品等级（特等奖/一等奖/二等奖/三等奖/幸运奖）、奖品数量、剩余数量、奖品图片、中奖概率配置、单人中奖上限。这里有个关键设计：奖品数量和单人中奖上限要拆开，避免出现一个人把某个奖项全包的情况。

第三张表是Participant（参与者），核心是记录学生的身份信息。字段包括：openid（微信唯一标识）、昵称、头像、学号（可选项）、学院、班级、电话（可选项）、报名时间、来源渠道（小程序码/分享链接）。openid 是唯一的，作为用户主键关联所有行为记录。

第四张表是DrawRecord（抽奖记录/中奖记录），这是整个系统最核心的业务流水表。字段包括：参与者ID、活动ID、奖品ID、抽奖时间、中奖状态、奖品领取状态（未领取/已领取）、领取时间、开奖批次号。每一条记录都不可删除，这样便于审计，万一活动现场奖品发错也能追溯。

第五张表是DrawRule（抽奖规则表），用于配置不同奖品的抽奖策略。字段包括：活动ID、奖品ID、轮次名称、中奖条件（比如必须是已报名用户）、抽奖基数（从所有参与用户中抽取或者是排除已中奖用户）、是否允许重复中奖。这张表把业务规则从代码里抽离出来，主办方通过 Admin 后台就能自己调整规则，不需要改代码。

2.2 表关系与业务约束

表之间的关系不复杂：一个活动对应多个奖品，一个活动对应多个参与者，一个参与者可以有多条抽奖记录，一个奖品属于一个活动。难点不在于关系，在于业务约束条件。

比如：参与者是否允许重复中奖？大多数校园抽奖活动默认不允许一个人中多个奖，但有些活动希望回馈更多学生，会限制“每人最多中一次”。这个逻辑如果在抽奖算法里硬编码，遇到规则调整就要改代码。我的做法是在DrawRule表里加一个allow_multiple字段，抽奖算法统一读取这个字段做校验，这样换规则只需要在后台改配置。

再比如：中奖概率怎么设置？如果活动方希望某个奖品的总中奖人数控制在10人，但报名人数未知，那就不能直接用固定概率。这里设计成两种模式：固定概率模式（每抽一次有固定比例）和固定总数模式（总共抽出N个即停）。主办方根据活动需要灵活选择，后台通过统一接口配置。

2.3 一个关键设计：开奖批次号

抽奖系统有个容易被忽略的问题，就是多轮开奖的批次管理。一场晚会可能有五轮抽奖，每轮奖品不一样，每轮参与资格也可能不同。如果抽奖记录表里没有批次标识，后面统计“某一轮中奖名单”会变得非常困难。

我专门加了batch_no（开奖批次号），每一轮开奖时生成一个唯一的批次号，系统会把该批次所有中奖记录关联起来。查询某一轮中奖名单，只需要按批次号过滤即可。同时，批次号也能用于并发控制——同一批次的抽奖操作必须串行执行，防止两个请求同时往批里写记录导致超抽。这个字段在设计初期就被很多人当成“无用的编号”，实际到后期统计数据和排查问题时，它帮了大忙。

3. 核心功能模块与抽奖算法实现

3.1 微信小程序登录与会话管理

小程序端最基础也最关键的功能是“静默登录”。用户打开小程序进入活动页，前端调用wx.login()获取临时code，然后通过后端接口把code传给 Django；Django 再向微信接口（jscode2session）发起请求，换取用户的openid和session_key。这里注意：session_key绝不能返回给小程序端，也不能在日志里打印，它属于用户敏感数据，只应在后端临时使用。换取到openid后，后端生成自己的会话令牌（Token），后续所有业务请求都携带这个 Token，不再依赖微信会话。

实际开发中这里遇到的坑：wx.login()的code有效期只有5分钟，而且一个code只能使用一次。如果后端处理出错需要重试，必须重新调用wx.login()获取新code。我一开始没注意，导致偶发性的登录失败，后来加了一个判断：如果后端返回“code无效或过期”，前端自动重新执行登录流程。

3.2 活动报名与资格校验

用户进入小程序后看到活动卡片列表，点击进入某个活动详情页。如果活动状态是“筹备中”，只能看到信息不能报名；如果是“进行中”，点击“立即报名”按钮。

实现报名资格校验时需要注意两个隐性门槛：活动是否设置了报名人数上限，以及该用户是否已经报名。我用 Django 的select_for_update()做行级锁来防止并发报名超限。举个实际场景：活动现场 500 人同时扫码进入页面，疯狂点击报名按钮，如果没有锁机制，很容易出现最终报名人数超过设定上限几百人的情况。锁定对应的Activity记录行，在事务里做“当前报名数加一”的操作，才能保证数据的准确性。

3.3 抽奖算法的三种模式与实现细节

这是项目的技术重点，我重点讲透。

第一种模式：按权重抽奖。系统把所有奖品按权重放到一个池子里，权重越大越容易被抽中。实现方式是用 Python 的random.choices函数，传入奖品列表和对应权重，一次调用直接返回一个中奖结果。比如某个活动中，一等奖权重是3，二等奖权重是7，三等奖权重是15，那么random.choices会按照权重比例选中奖品。这种模式适合奖品等级多、每轮抽奖奖品各不相同的情况。

第二种模式：固定总数抽奖。设置一个奖品总数为10，系统不断生成随机参与者，直到中奖人数达到10则停止。这个模式的实现要点在于“排除已中奖用户”（如果规则限制不重复中奖）。每抽出一个中奖者后，将其 ID 放进一个已中奖集合，下一轮随机时不从这个集合里取样。

第三种模式：实时滚动抽奖。这是现场大屏幕滚动抽奖时用的，系统不是提前算出中奖者，而是由管理员点击“开始滚动”后，屏幕不断刷新随机头像，点击“停止”时才通过后端接口计算出中奖名单。后端在停止时刻生成随机数，从符合资格的参与者中抽取。这种模式特别考验接口响应速度，Django 每处理一次/api/draw/stop/请求，必须保证在毫秒级返回，否则现场观众会感觉有延迟。

这里必须做并发控制。我用 Redis 的SETNX命令实现了一个简单的分布式锁：在开奖批次开始时设置一个 key，如果 key 已存在说明有人在执行开奖流程，其他请求直接拒绝。校园活动场景下虽然并发量不如电商大促，但现场几百人同时点击“我要抽奖”还是很容易并发的，直接操作数据库很容易产生超抽或者重复中奖。Redis 锁可以让整个开奖流程在单线程下执行，从原理上杜绝了并发问题。

3.4 防止刷奖与作弊的思路

校园抽奖系统防作弊是必选题，否则现场某个学生通过技术手段把自己变成“锦鲤”，活动就失去意义了。

第一层防护：基于 openid 的用户唯一性限制。同一微信号只能注册一个参与者身份，后台对 openid 做了唯一索引。如果用户尝试用不同微信账号登录，那本质上就是不同参与者了，这种不在防作弊范围内——除非主办方在规则里限制一个学生只能用一个微信号。技术上能做的，是在后台记录设备指纹（通过 wx.getDeviceInfo 获取设备型号和系统版本，拼接成指纹），如果一个设备在极短时间内注册了超过一个账号，就触发风控标记。

第二层防护：抽奖资格校验。只有状态为“已报名”且活动状态为“进行中”的用户才能参与抽奖。这个校验放权后在 Django 视图函数里做，不能只在小程序端做——小程序端代码是可以被反编译和篡改的，后端再次校验才是安全的。

第三层防护：中奖记录不可篡改。每一条中奖记录在写入数据库时都会计算一个 Hash 值，等于把记录的所有核心字段拼接后做 SHA-256 摘要，存入record_hash字段。如果任何人试图从数据库层面篡改中奖记录，Hash 校验就会失败，后台会在“数据完整性检查”任务中标记异常。这个做法不是必须的，但加上了就多一层安心，成本也很低。

3.5 后端接口设计速览

接口路径按照 Django REST Framework 的风格设计，整体保持统一。

• POST /api/auth/login/：微信登录换取 Token
• GET /api/activities/：获取活动列表
• GET /api/activities/{activity_id}/：获取活动详情
• POST /api/activities/{activity_id}/register/：报名活动
• POST /api/activities/{activity_id}/draw/：参与抽奖
• GET /api/draw/records/：我的中奖记录
• POST /api/draw/publish/：管理员发布开奖结果（手动模式）
• GET /api/admin/activities/{activity_id}/stats/：后台统计接口

接口设计上除了返回数据本身，还统一包含一个code字段，约定 0 表示成功、非 0 表示具体错误码。例如 10001 表示“活动未开始”，10002 表示“活动已结束”，10003 表示“已报名”，10004 表示“无抽奖资格”。小程序端只需要根据错误码做对应的页面提示即可，不用关心后端处理细节。

还有一个比较容易被忽视的点：接口的幂等性设计。POST /api/activities/{id}/draw/这个抽奖接口必须做幂等处理，防止用户连续点击两次导致重复参与抽奖。我在DrawRecord表里加了一个唯一约束(participant_id, activity_id, batch_no)，即同一个用户在同一个开奖批次中只能保存一条抽奖记录。这样即使前端发送了两次请求，数据库层面的唯一索引也会把第二次请求拦下来。

4. 实操过程与关键功能实现

4.1 项目环境准备与初始化

开发环境选择：

• Python 3.10+
• Django 4.2 LTS
• Django REST Framework 3.14+
• Redis 7.0（缓存与分布式锁）
• MySQL 8.0（或 PostgreSQL，本项目用 MySQL 足够）
• 微信开发者工具（用于小程序调试）

初始化项目时直接用 Django 命令创建项目骨架：

django-admin startproject campus_lucky cd campus_lucky python manage.py startapp activity python manage.py startapp user_auth python manage.py startapp draw

分三个应用的原因是把用户认证、活动管理、抽奖逻辑解耦。后续如果要扩充功能（比如增加积分系统），不会互相牵连。

然后在settings.py里配置数据库连接、Redis 连接、微信小程序 AppID/Secret 的读取方式（统一用环境变量，不硬编码进配置文件）。

4.2 核心代码片段实现

先展示奖品配置的数据模型代码，这是抽奖算法的基础：

class Prize(models.Model): LEVEL_CHOICES = [ ('special', '特等奖'), ('first', '一等奖'), ('second', '二等奖'), ('third', '三等奖'), ('lucky', '幸运奖'), ] activity = models.ForeignKey(Activity, on_delete=models.CASCADE, related_name='prizes') name = models.CharField(max_length=64, verbose_name='奖品名称') level = models.CharField(max_length=16, choices=LEVEL_CHOICES) total_count = models.PositiveIntegerField(default=0) remaining_count = models.PositiveIntegerField(default=0) weight = models.PositiveIntegerField(default=10, help_text='权重值，越大越容易被抽中') image_url = models.URLField(blank=True) def save(self, *args, **kwargs): # 初始创建时剩余数量等于总数 if not self.pk: self.remaining_count = self.total_count super().save(*args, **kwargs)

这个模型里最重要的字段是weight。它直接参与抽奖权重的计算，可不是随意填的。我的建议是：主办方要根据奖品数量和学生人数合理配置权重。如果一等奖只有一个，但权重设置为50，二等奖有10个权重也是50，那么从概率上看每一轮抽奖抽中一等奖的概率其实是 50/（50+500）≈9%，而不是“大奖很难抽”的直觉感受。所以我在后台里做了个权重预览功能，主办方配置完奖品就能看到每个奖品的预估中奖百分比，这样就避免了“拍脑袋填权重导致大奖中出率过高”的问题。

再看抽奖算法的核心执行函数：

import random def perform_draw(activity_id, batch_no, exclude_winners=True): """按权重抽取指定活动的一批中奖者""" # 查询所有候选参与者 candidates = Participant.objects.filter(activity_id=activity_id, status='registered') if exclude_winners: # 排除已中奖用户 winners = DrawRecord.objects.filter(activity_id=activity_id, is_winner=True).values_list('participant_id', flat=True) candidates = candidates.exclude(id__in=list(winners)) candidate_list = list(candidates) if not candidate_list: raise DrawException('候选人数不足') # 查询符合条件的奖品（仍有剩余数量的） prizes = Prize.objects.filter(activity_id=activity_id, remaining_count__gt=0) prize_list = list(prizes) weights = [p.weight for p in prize_list] # 按权重选择奖品 chosen_prize = random.choices(prize_list, weights=weights, k=1)[0] # 随机选择一个参与者 participant = random.choice(candidate_list) # 创建中奖记录（此处需要通过事务确保奖品剩余数量扣减与记录写入原子完成） # 事务控制在视图层通过 with transaction.atomic(): 完成 return participant, chosen_prize

这段代码的核心逻辑是关键路径上先筛掉已中奖用户，再抽取奖品。为什么要先筛用户再抽奖品？如果先抽奖品再筛用户，有可能抽到一个用户已经中过奖，就必须重新抽，这样会产生无效的抽取次数，还会让奖品实际被抽中的概率偏离配置的权重。先筛用户，保证了每次抽奖操作都生效。

注意，random.choices默认是有放回抽样，每次抽完后remaining_count要减一。如果奖品数量还有多个，下一轮抽奖仍然可能抽到同一个奖品，这是正常的轮次抽奖行为。

4.3 视图层的事务与锁机制实现

抽奖接口的完整实现，涉及数据库事务和 Redis 锁，直接看代码：

def draw_view(request, activity_id): participant = request.user.participant_profile with redis_client.lock(f'draw_lock:{activity_id}', timeout=10): with transaction.atomic(): lock_row = Activity.objects.select_for_update().get(id=activity_id) if lock_row.status != 'ongoing': return error_response(10001, '活动不在抽奖时间') # 检查该用户是否已中奖 if not lock_row.allow_multiple_winners: existing = DrawRecord.objects.filter(participant=participant, activity_id=activity_id, is_winner=True).exists() if existing: return error_response(10003, '您已经中过奖啦') # 执行抽奖算法 winner, prize = perform_draw(activity_id, current_batch_no()) # 创建中奖记录并扣减库存 DrawRecord.objects.create(...) Prize.objects.filter(id=prize.id).update(remaining_count=F('remaining_count') - 1) return success_response(...)

这个实现里有几个关键点值得琢磨。

第一，为什么用一个 Redis 锁把整个事务包起来？前面提到过，这是为了保证同一时间只有一个抽奖请求在执行，避免并发刷接口导致超抽。锁的timeout设为10秒，正常情况下抽奖算法只需要几十毫秒，10秒足够宽裕，即使发生意外也不会永久卡住。

第二，select_for_update()配合事务原子性，双重保险。虽然 Redis 锁已经保证了串行，但数据库行级锁是对数据的最后一层确认。如果有多个 Django 实例同时运行（负载均衡部署），Redis 锁能跨实例生效，而select_for_update()保证在同一数据库层面数据不会被覆盖写。

第三，读取奖品剩余数量时用了F('remaining_count') - 1而不是先查出来减一再写回去。因为F表达式是在数据库层面执行原子操作，不存在“读改写”之间的竞态窗口。

4.4 微信小程序端核心页面逻辑

小程序端最关键的两个页面：活动列表页和抽奖结果页。

活动列表页的逻辑比较简单，调用wx.request请求后端接口，渲染卡片，点击后进入详情页。注意这里要处理Token过期的情况：请求返回 401 时，小程序自动重新静默登录，再重放请求。这个逻辑适合封装在request工具函数里，避免每个页面重复实现。

抽奖现场页面是最有仪式感的部分，通常做成一个可以滚动展示参与人头像的转盘或大屏列表。前端逻辑是：点击“开始抽奖”后，前端每隔50毫秒切换一次随机头像展示，制造“滚动”的视觉效果；点击“停止”，此时小程序先触发一个震动反馈（wx.vibrateShort），再向后端发送停止指令，拿到最终中奖名单后，页面聚焦展示中奖者头像，同时播放一个简单的弹窗动画。

需要提醒的是，这种“滚动 -> 停止”的视觉体验，纯粹是前端交互设计，后端抽奖结果在点击“停止”的瞬间才真正产生，其实在用户看来，停止前的前端“滚动”画面并没有决定谁能中奖，决定权在后端。也就是常说的“先摇画面，后定结果”，现场效果和公平规则可以兼顾。

4.5 Django Admin 后台定制

管理员后台是让不懂技术的同学也能快速操作的关键。默认的 Django Admin 展示太简陋，如果直接给活动主办方用，体验非常差。我做了以下定制：

• 在ActivityAdmin中增加“发布活动”按钮，点击后直接把活动状态从“筹备中”改为“进行中”，避免主办方去学习状态字段的含义。
• 在PrizeAdmin中按活动过滤奖品列表，只显示当前活动对应的奖品，避免误操作其他活动的数据。
• 增加一个只读的“当前参与人数”和“已中奖人数”统计字段，管理员打开页面就能一眼看到活动热度。
• 在DrawRecordAdmin中支持按活动、按奖品等级、按中奖状态筛选，方便现场快速打印中奖名单。

这里最需要注意的是权限设置。Django Admin 默认给超级用户所有权限，但给活动主办方开账号时，一定不要给超级权限，只给activity.can_change和draw.can_view之类的模型级权限，否则主办方误删数据，现场就炸了。具体配置在后台的“用户权限”里选“每个模型的增删改”而不是“全局所有权限”。

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

5.1 微信登录一直失败

这是开发阶段遇到频率最高的问题。常见原因有两个：一是小程序的 AppID 和 Secret 配置错误或者不匹配，尤其是开发者工具中用的是“测试号”时，后端必须同步配置测试号对应的 AppID；二是服务器出口 IP 不在微信白名单里，微信接口会拒绝调用。排查方法非常直接：在后端日志里打印出微信接口返回的原始错误信息，看清楚errcode是多少。比如 40013 表明 AppID 无效，40125 表明 Secret 错误。根据错误码去微信官方文档里对照原因，比盲目改代码效率高得多。

5.2 抽奖时奖品剩余数量变成负数

出现这种情况基本可以断定并发控制没起作用。之前我提过 Redis 锁，但是如果部署环境没有 Redis 或者 Redis 连接失败，Django 会直接抛异常，这个时候如果代码里没有优雅降级，锁就形同虚设。另一种可能性是直接越过了后续部署流程，没有使用 Redis，仅靠select_for_update()做并发控制——理论上行级锁也能防并发，但前提是必须配合事务，如果视图函数没有整体上用transaction.atomic()包起来，行级锁就会在语句执行完立即释放，起不到保护作用。

排查方法：打开 MySQL 的慢查询日志和普通查询日志，查看同一时间段是否有两条UPDATE prize SET remaining_count = remaining_count - 1的并发执行记录。如果有，说明日志里的锁等待和事务提交顺序有问题。修复方式是检查整个视图函数是否有 Transaction 装饰器，以及是否有明确的保存点。

5.3 现场网络差，小程序接口超时

校园活动现场的网络状况往往比开发环境差得多。几百人同时连一个 Wi-Fi，运营商信号时好时坏，接口请求超时就会发生。应对措施：小程序端引入超时重试机制，接口请求超时后自动重试1-2次；后端把小程序静态资源和服务接口分开部署，接口使用独立域名，避免活动图片上传下载占用通道。同时，后端接口响应时间必须优化到200毫秒以内。我的做法是给参与人数统计、活动列表等高频接口加 Redis 缓存，抽奖接口本身不能缓存，但抽奖前的“活动状态校验”和“用户资格校验”结果可以缓存15秒，大大减少数据库压力。

5.4 中奖记录与现场实际领奖对不上

这种情况多半不是抽奖系统的问题，而是现场流程管理的问题。比如中奖用户现场没来领奖、代领奖品的同学签错了名字，导致记录和纸质签字表对不上。我在系统里增加了一个“领奖登记”功能，工作人员在小程序后台扫描中奖者的核销码，核销后记录状态变为“已领取”并记录核销时间。这样领奖流程完全数字化，事后统计时清清楚楚。核销码是由后端生成的动态二维码，有效期5分钟，防止截屏盗用。

5.5 学生反馈“为什么我抽不中”

大多数时候这不是 bug，而是概率问题。但学生会觉得是系统有暗箱操作。针对信任问题，我在活动结果页做了一个“抽奖公示”按钮，点击后可以看到本场活动所有中奖记录的公开列表（按编号脱敏显示，比如学号后四位+姓名首字母），同时生成一个“本场中奖名单”PDF，导出后由主办方盖章公示。虽然本质上无法完全证明随机性，但至少从流程上体现了公开透明的态度。

6. 部署上线与运维建议

6.1 后端部署要点

生产环境推荐使用 Linux + Nginx + Gunicorn 的组合。Django 的runserver绝不能用于生产环境，这是老生常谈但确实总有人以身试法。Gunicorn 的进程数和线程数配置需要根据服务器硬件调整，我一般用 2 个 worker、2 个线程起步。如果一台服务器同时跑 Redis 和 MySQL，建议至少给到 2C4G 的配置，否则活动高峰期响应就会明显变慢。

项目的静态文件处理要特别注意。Django 在 Debug=False 模式下不会自动提供静态文件和媒体文件，需要 Nginx 单独配置一个 location 指向这些目录。活动封面图、奖品图片都放在媒体目录，通过 Nginx 直接服务，不经过 Django 应用层，这样能明显降低应用服务器压力。

6.2 HTTPS 与小程序合法域名

微信小程序的首要部署硬性要求是：所有接口请求域名必须是 HTTPS 且已经备案。在开发者工具中测试时可以勾选“不校验合法域名”，但真机体验必须配置合法域名。常规流程是：先在微信公众平台中配置服务器域名（request 合法域名、uploadFile 合法域名），再部署 SSL 证书。证书申请推荐免费证书方案，校园场景的成本管控还是很重要的。证书到期前必须设置自动续期提醒，否则到期当天所有小程序用户都无法访问接口，活动直接瘫痪。

6.3 上线前的数据备份与演练

正式活动前至少做一次全流程演练。我会提前准备一批测试账号，模拟从报名到抽奖到领取核销的全流程操作，确认每一条记录都写入正确。演练结束后，清空测试数据，同时保留一份完整的数据备份。确保万一现场出问题，可以快速恢复到开赛前某个时间点。

备份策略不复杂：每天凌晨用 crontab 执行 MySQLmysqldump全量备份，保留最近7天的备份文件。活动当天，在活动开始前手动额外备份一次（因为这天的数据改动最频繁），并把这个备份文件下载到本机。实际上即使活动数据出现问题，有备份就能迅速回到活动开始前的状态，把影响降到最低。

7. 后续功能拓展方向

系统跑通之后，可以在这个框架上做不少延伸。

首先是增加“抽奖活动热度分析”。通过记录每个活动的参与人数曲线、报名转换率、中奖用户活跃度等数据，用简单的图表（ECharts 或 Django Admin 内嵌图表）展示，主办方可以直观看到哪个活动人气高、哪种奖品更受欢迎，为后续活动选品和规则优化提供参考。

第二个方向是接入“消息订阅”。微信小程序支持一次性订阅消息，用户报名活动后可以主动订阅“开奖结果通知”。开奖完成后，系统通过微信服务端接口向所有订阅过的用户发送一条抽奖结果通知。这个功能很实用，尤其适合那些没办法全程盯现场大屏幕的学生。实现上一方面要用户主动点击“接收开奖通知”并同意授权，另一方面后端需要在开奖流程中调用微信的订阅消息发送接口。注意订阅消息的模板要提前在公众平台申请并且通过审核，否则无法发送。

第三个方向是做成“多活动平台”模式。当前系统是单活动管理的思维，如果要把系统开放给学院内不同部门使用，需要增加“组织”“角色”的概念。比如某个学院的学生会可以创建自己的活动，某个社团只能查看自己的数据。这个相对复杂，需要在现有 Activity 表上增加一个organizer_id外键，同时新增一个组织成员表。建议等基础版本稳定后再迭代，不要一上来就做得过于庞大。

我在实际推进这个项目的过程中，体会很深的一点是：技术实现本身并不复杂，真正的难点全在需求理解、边界条件的处理、以及现场突发情况的应对策略上。比如抽奖时网络延迟、学生重复报名、同一账号多人使用，这些看似边缘的事情，恰恰是决定一场活动体验好坏的关键。如果你也是学习 Django 或者准备做微信小程序项目，建议先不要急着堆砌功能，把核心链路跑通、把异常情况想清楚，这个项目就成功了一大半了。