企业官网建设流程全解析

从零搭建一个Django公考刷题平台：架构设计、刷题引擎与部署避坑实录

这几年公考热度一直在线，身边做培训的朋友陆续都在琢磨线上化。刷题平台这类产品看着不复杂——无非是题库、做题、判分、错题本，但真上手做的时候，细节远比想象中多。我最近完整做了一个基于Django的在线刷题学习平台，从需求梳理到部署上线走了一遍，踩了不少坑，也沉淀了不少经验。这篇文章就把整个设计与实现过程拆开来讲，从核心模块、表结构设计、刷题判分逻辑，到性能优化、部署注意事项，一次性说清楚。

无论你是准备做毕业设计、接外包，还是给培训机构做内部系统，这篇文章应该都能给你一个可以直接参考的完整方案。

1. 为什么选Django做这类平台，以及最容易被忽略的提前设计

先聊选型。市面上做Web应用的框架不少，Flask轻量、FastAPI新潮、Spring Boot在企业里也常见，但做刷题学习平台这种典型的"数据模型密集 + 后台管理重 + 权限体系复杂"的业务，Django的优势非常直接。

Django自带Admin后台，这句话在刚入门的阶段可能感受不深，但你真开始录题、管理学员、审核内容的时候就会明白——一个开箱即用的后台意味着你省掉了至少三成的前期开发量。刷题平台的核心资产是题目，而题目的录入不可能依托前台页面去做，必须有一个高效的后台管理界面。Django Admin配合自定义action，可以快速实现批量导入、批量上线下线、按科目筛选等功能。

第二个优势是ORM。刷题平台的表结构天然复杂：用户表、科目表、题目表、刷题记录表、错题本、收藏夹、模考记录、学习统计……这些表之间的关联关系非常多，用原生SQL去维护会崩溃。Django ORM的QuerySet链式查询在这种场景下效率极高，而且迁移管理非常顺手，改模型后makemigrations + migrate就完事。

第三个关键是用户认证体系。Django自带的认证系统虽然不是专门为刷题平台设计的，但它提供了可扩展的AbstractUser模型，把手机号、头像、所属培训班等字段扩展进去，既保留了框架自带session验证、密码加密逻辑，又满足业务需求。

不过选型确定之后，有一件事必须在动手写代码前完成——把平台的角色和权限边界彻底想清楚。这个点我开发到一半时差点返工，必须提醒你注意。

刷题平台至少会涉及四类角色：普通学生（刷题、模考、看解析）、教师（出题、布置作业、看班级统计）、教务管理员（审核内容、安排模考）、系统管理员（维护用户和科目）。如果前期不把角色边界定清楚，后期加权限逻辑会非常痛苦。我的经验是先在文档里画清楚每个角色的用例图，再动代码。项目后端规划时，直接在REST Framework的权限类里针对不同视图设置IsAuthenticated、IsTeacher、IsAdmin等权限组合，绝对比写到一半再回头改要省事得多。

提示：即使你只是做一个毕设级别的Demo，也建议至少把"学生"和"教师"两个角色分开设计。很多毕设答辩时被追问的点，恰恰就是权限控制的粒度。

2. 数据库表结构设计：题目、刷题记录和学习统计的关联关系

刷题平台的表结构是整个系统的地基，这块设计的合理与否直接决定了后面功能的开发效率。我第一条经验就是：不要迷信单一的"题目表"，仔细拆开你会发现题目的字段差异大到必须分表。

2.1 题库层面：科目、知识点与题型拆分

首先是科目体系。公务员考试笔试通常有行测和申论两大类，而行测又分常识判断、言语理解、数量关系、判断推理、资料分析。这其实就是典型的树形结构。我设计了Subject表，包含parent字段自关联，再配合depth字段记录层级深度。前端展示时只需按depth分层渲染即可。

接着是核心的Question表。很多新手会把所有题型字段都塞进一张表里，比如题干、选项A到D、正确答案、解析、所属科目、所属知识点……听着没问题，但一旦遇到多选、判断、不定项、材料题（一拖五），这种扁平结构就用不了了。

我的设计是拆成三张表：

• Question基础表：存放题干、题型、难度、解析、所属科目、所属知识点；
• ChoiceOption表：存放每个题的选项，通过question外键关联，带option_key和option_content；
• QuestionMaterial表：存放材料题的材料内容，一个材料对应多个题目。

单选题的选项存哪？直接存ChoiceOption表。判断对错题没有选项怎么办？题型字段区分，逻辑上跳过选项查询。材料题的一篇材料带五个小题，材料内容单独一张表。这样设计的核心好处是：前台渲染时通过题型字段走不同的模板逻辑，而不是靠"选项为空"来判断，数据和展示彻底解耦。

2.2 用户行为层面：刷题记录与错题本的幂等设计

刷题行为和错题本，这是第二个设计重点。一开始我以为"刷题记录"就是简单的一个表，记录用户、题目、答案、对错、时间就够了。但实际业务里有两个细节必须提前处理。

第一，学习报告是按天聚合的。如果每次刷题都往记录表里插一行，查询"今天做了多少题"时SQL就要对全表进行时间范围过滤，高并发下会越来越卡。我的做法是分两层：刷题明细表PracticeRecord存每次作答的具体记录；每日学习统计表DailyStat按用户+日期维度聚合总数和正确数。明细表负责可追溯的流水，统计表负责报表查询，各干各的。

第二，错题本去重。用户第二次做同一道题做错了，错题本不应该出现两条重复记录。我的方案是给错题本表加unique_together限制（user, question），并自定义update_or_create逻辑：如果新纪录是对的，且该题已在错题本里，则自动移除；如果新纪录是错的且不在错题本，则插入；如果错题已存在，就刷新最近错误时间。这套逻辑写起来不难，但能避免非常多脏数据。

2.3 模考与题库状态的联动

刷题平台通常还带模考功能。模考本质上是一个有时间限制的试卷会话。我设计了ExamSession表，记录用户、试卷、开始时间、结束时间、总得分。与之配套的是ExamAnswer表，记录用户在模考中对每道题的作答。需要注意的一点：模考和普通刷题一个关键区别是，模考开始后题库中的题目状态是"锁定"的——不能边考边查解析。实现上我用一个status字段标记会话状态，只有"进行中"才允许提交答案，提交后统一判分并解锁答案。

3. 刷题引擎的核心逻辑：随机抽题、选项乱序与判分去重

刷题平台说到底是"题"为王的业务，刷题引擎的设计直接决定使用体验。这个模块我实现时拆成了三个独立服务：抽题服务、判分服务、解析展示服务。下面详细拆开讲。

3.1 随机抽题与乱序选项

抽题的核心是"避免重复"。用户刷题时最讨厌的就是反复遇到做过的题，尤其是有正确答案记忆的题。我在PracticePaper生成时实现了严谨的抽题逻辑：

• 根据当前用户已做过的题目ID集合进行排除；
• 再设定每次抽题的科目范围、题型范围、数量；
• 使用Django ORM的exclude(id__in=done_ids).order_by('?')[:count]生成随机题目序列。

order_by('?')在数据量小的时候很好用，但题目量过几万后性能明显下降，因为它会让数据库做全表随机排序。上线前我改成了基于主键范围的随机偏移策略：先count出总题数，再随机生成若干个偏移量，用offset查询取题，性能提升非常明显。

选项乱序也值得做。如果每次刷题选项顺序都固定，用户容易形成"选C就是对的"这种位置记忆。我的实现思路是：在出题时生成一份随机排列的选项ID序列，存入对应session的题目快照表。这里有两个细节：乱序只影响展示层，判分时依然按照题目原始正确选项ID去比对；乱序序列需要和刷题会话绑定存储，不能每次请求时临时随机，否则刷新页面后选项顺序会跳变。

3.2 客观题判分与解析快照

判分逻辑简化下来就是：提交答案对象，服务端比对正确答案。但工程师视角下有几个坑：

第一个坑是题目答案字段的存储格式。单选题答案是选项ID，判断题答案是布尔值，多选是一组ID。如果统一存成字符串形式非常容易出错。我统一将所有答案都序列化为JSON数组，单个选项也是单元素数组。判分时直接比较集合相等，避免"字符串相等判断"这个分支在多选场景下出现顺序不一致的问题。

第二个坑是解析内容的时效性。用户做题时看到的解析，和教研老师过几天修改后的解析，应该是两回事——严格来说，应该以做题当时的解析为准。所以在生成刷题会话时，我把题的题干、选项、解析直接冗余存储了一份快照表。这样即使题库后续变化，历史记录仍然能正确展示。这个设计投入不大，但能保证数据溯源完整。

# 判分服务核心逻辑（简化版） def grade_answer(question_snapshot, user_answer): correct_ans = json.loads(question_snapshot.answer_json) user_ans = json.loads(user_answer) # 用集合比较，而不是字符串比较 return set(correct_ans) == set(user_ans)

3.3 学习报告中的正确率计算

学习数据页的核心是"正确率"和"做题量"的趋势图。正确率的统计口径要想清楚，是按题次算还是按题数算？材料题一题算一次还是算N次？我的口径是：以单道题每次作答为一次计数。模考与日常刷题分开统计，模考正确率单独展示，避免两类数据混在一起导致学员自己都看不懂。

聚合计算的部分，我并没有在查询时实时count，而是用DailyStat表的累加字段。用户每次做完题，事务内同时更新practice_total和practice_correct两个计数。这种"写多读少"的设计非常适合统计场景，报表接口只需做简单的sum聚合。

4. 前后端交互与API设计：车辆管理系统的启示

聊完主体设计，再来说说前后端交互。这一块经验有点特别——我是从之前做过的一个车辆管理系统项目里得到启示的。当时那个系统数据表多、关联深，吃过接口设计混乱的亏，所以这次刷题平台从第一天起就定了三条API铁律：资源语义化、状态驱动、批量优先。

4.1 资源语义化接口设计

写接口最忌讳的是"动词式URL"，比如/getPracticeList、/submitAnswer。我全部改成了资源式URL：GET /api/practice/papers/拉取刷题会话列表，POST /api/practice/records/提交一条刷题记录，GET /api/exams/{session_id}/查询模考会话详情。这样做的直接好处是前端对接时心智负担很小——看到URL就知道操作对象是什么。

配合Django REST Framework的ModelViewSet，每个资源的CRUD几乎零重复代码。自定义action则用来处理批量操作，比如错题本批量移除：

@action(detail=False, methods=['post']) def batch_remove(self, request): question_ids = request.data.get('question_ids', []) # 批量逻辑

4.2 列表接口的性能优化

刷题记录列表、错题本列表、模考历史列表，这三个是典型的"高查询低写入"接口。开发初期性能尚可，数据量涨到一定级别后就明显变慢。我这里处理了三个层面的优化：

第一，select_related和prefetch_related用在刀刃上。错题本列表要展示题目内容，如果用N+1查询，每一行都去查一次题目表，接口响应时间会呈线性暴涨。改成select_related('question')之后，一次join全部取回，效果立竿见影。

第二，分页参数必须标准化。我统一用page和page_size参数，返回结构固定为data + pagination对象，前端分页组件直接对接，不需要为不同接口做适配。

第三，列表接口中避免COUNT大表。Django默认的PageNumberPagination会为了获取总页数而执行COUNT查询。数据量大时这个COUNT会成为瓶颈。我给列表接口单独配置了NoCountPagination，用"下一页是否有数据"代替总页数，牺牲微不足道的体验，换来了明显的性能提升。

4.3 在线刷题场景的长连接与断点续做

刷题平台有一个特殊场景：用户没做完一套卷子，关掉了浏览器，下次打开后应该怎么做？我的设计是"分页保存作答快照"——每做一道题，前端就立即向后端发送一条保存记录请求，而不是等整卷做完统一提交。这样即使中途退出，重新进入时依然能看到之前已答的题目和答案。刷题会话（PracticeSession）表里保存session状态，已完成、进行中、已过期三种，前端根据状态展示不同的按钮组。

注意：实时保存对接口稳定性要求高。前端做防抖和失败重试，后端用幂等设计保证重复提交同一道题的答案不会产生重复计数。这块一定要测试，尤其网络抖动场景。

5. 部署上线与后台运维：从本地到云服务器的完整经验

最后一部分聊聊部署和运维。项目写完后，我在Linux云服务器上完成了从零部署，踩了不少和本地环境不一致的坑，这里挑最有价值的几个说。

5.1 Nginx + Gunicorn + Django的标准部署

部署方案是我比较推荐的经典组合：Gunicorn跑Django应用，Nginx做反向代理和静态文件服务，Supervisor守护进程保证Gunicorn崩溃后自动拉起。

# Gunicorn启动命令配置示例 gunicorn exam_platform.wsgi:application \ --bind 127.0.0.1:8000 \ --workers 3 \ --threads 4 \ --timeout 60 \ --access-logfile /var/log/gunicorn/access.log \ --error-logfile /var/log/gunicorn/error.log

workers数量不是越大越好。常见说法是2N+1，N为CPU核数。我实测在2核4G的云主机上，3个workers加每worker4个线程的配置，QPS和内存占用比较平衡。workers开太多会导致内存超限，服务反而更不稳定。

静态文件这块，很多人部署时容易漏：Django的DEBUG=False后不会再自动提供静态文件服务，必须由Nginx来处理。把collectstatic收集后的static目录映射到Nginx的location块，否则页面样式全丢。

5.2 Django后台管理在刷题业务中的配置要点

Django Admin不是默认配置就能直接用的，按业务调整后效率提升很大。我做了三件比较关键的事：

• QuestionAdmin里配置list_display = ('subject', 'question_type', 'difficulty', 'is_active')，列表页直接可筛选，不用点进详情；
• 配置list_editable字段，支持在列表页直接勾选"是否上线"，教研同事批量操作时体验极好；
• 自定义导入action，用Excel格式批量导入题目，字段校验失败的行单独生成错误报告，而不是中断整个导入。

这套后台简化了教务老师的工作流，测试下来录题效率比直接在数据库里操作提升了不止一个量级。

5.3 线上常见的三个坑及排查路径

第一个坑：时区问题。服务器默认UTC时间，而刷题平台的"每日统计"是按东八区自然日计算的。如果不统一TIME_ZONE配置，"今天做了几道题"会在早晨8点前出现统计归属错位。我的解决方式是Django配置TIME_ZONE='Asia/Shanghai'、USE_TZ=True，同时在所有涉及"跨日"判断的逻辑里，先用timezone.localtime()转换再取日期。

第二个坑：静态文件缓存。前端版本升级后，用户浏览器还在使用旧CSS/JS，页面表现诡异。我后来在Nginx的静态文件请求里关闭了ETag并设置较短的缓存周期，上线高峰期手动清一下Nginx缓存目录，问题基本不再出现。

第三个坑：数据库连接泄漏。长连接模式下，MySQL的wait_timeout默认值较大，但业务高峰期大量空闲连接堆积会让连接池打满，表现为"偶尔的500 + 间歇性超时"。排查链路是：先看Gunicorn日志有没有Timeout，再看MySQL的processlist，最后确认Django的CONN_MAX_AGE配置是否合理。我最终把CONN_MAX_AGE设成了60，并配合定时重连，问题彻底消失。

5.4 数据备份与迁移策略

最后说一下数据安全。题库数据是平台最值钱的资产，我部署了两种备份：每日凌晨全量备份数据库，每周导出一次题目数据的JSON快照存入对象存储。恢复演练我实际做过两次，不要相信"备份文件存在就等于能恢复"这种话，没演练过的备份都是废的。另外，ORM迁移文件是团队协作的生命线，多人开发时不要手动改数据库结构，任何变更都走makemigrations生成迁移文件，并让所有人通过migrate同步。

6. 写在最后：一次真实落地后的复盘与几点诚实的建议

从零把这个平台做完上线，前后大概花了两个月。有些方法论是通用的，最后再用几条实际体会做收尾。

第一，数据模型设计的优先级高于一切。刷题平台这类系统的核心价值就是数据和数据间的引用关系，一上来就写视图、调样式，后面会付出十倍精力来修补表结构的错误。先花三天把关系理清楚，再动代码，收益非常明显。

第二，后台管理界面一定要第一时间做出来。我搭好Django Admin后立刻导入了第一批真实题目数据，后续所有功能联调都基于真实数据走，大大减少了"假数据假逻辑"导致的设计偏差。甚至让用惯了Excel录题的教研同事提前上手，反馈直接变成迭代需求，这和闭门造车的区别很大。

第三，Django后台自带功能不要重复造轮子。权限组直接用Admin的Group，文件上传直接用FieldFile，认证直接用Session机制，日志直接用内置LogEntry。这些成熟内置能力，省下的时间足够你把业务功能打磨得更细致。

最后想提醒一点：如果你也准备用这个项目做毕设，千万别只停留在"能跑起来"。把权限控制、数据聚合、防重复提交这些细节做深一点，答辩时就是完全不同的评价。这套完整设计和实现方案，希望能给你一个经得起推敲的参考。