每年到了毕业设计选题季，后台私信里问得最多的一类问题就是：Spring Boot有什么项目好做？最好是那种功能不难、工作量够、技术点耳熟能详，但又不至于烂大街到答辩时被老师一眼看穿的题目。“Spring Boot公务员考试知识共享平台”就是这类题目里非常典型的一个。名字听起来很公务员考试，拆开看其实是一个“内容社区 + 在线题库 + 模拟考试”的综合系统，技术栈主流，业务场景清晰，扩展空间也很大，用来做计算机毕业设计源码完全够用。这篇就聊聊我是怎么做这类平台的，从选题定位、表结构设计到几个容易翻车的核心模块，都会讲到。
文里的思路不是教科书式的项目文档，而是按我实际写代码、带项目的习惯来梳理的。如果你正在找毕业设计题目，或者想拿 Spring Boot 练手做一个完整项目，这篇文章应该能给你一个相对完整的落地路径。
1. 选题逻辑：这个项目到底在做什么，为什么值得做
1.1 一个名字普通但业务层次很完整的选题
第一次看到“公务员考试知识共享平台”这个题目的同学，第一反应往往是：这不就是个题库网站吗？把题目整理好，用户登录进来刷题，管理员后台维护数据，完了。这么想不能说错，但把这个业务拆细之后你会发现，它的复杂度恰好落在一个“毕业设计最舒服”的位置——再简单一点撑不起论文工作量，再复杂一点两个月做不完。
完整的业务应该包含四块：内容管理，包括题库、学习资料、知识帖子的发布与分类；用户体系，包括注册登录、角色权限、积分签到；考试引擎，包括组卷、限时答题、自动判分、答题卡；数据统计，包括做题记录、正确率、错题集、学习趋势。这四块分别对应了管理系统的基础操作、社区产品的互动逻辑、在线教育平台的核心玩法、以及报表系统的统计需求。一个项目覆盖四类常见后端能力，基本上把 Spring Boot 生态里最常用的东西都串起来了。
我见过不少同学做这个题目时只做“题库管理 + 模拟考”两块，剩下全是演示功能。这样不是不行，但答辩时老师随便问一句“你这个平台共享了什么”，就很难答。知识共享平台的灵魂是用户能贡献内容、能互动、能积累数据，而不是一个单向的刷题工具。
1.2 对毕设新手和想练手的人来说，优势在哪里
这个选题最大优势是每个模块的边界非常清楚。题库归题库、考试归考试、社区归社区，模块之间通过用户和积分松散关联，不会出现改了一个表导致全盘崩溃的情况。对于时间紧的同学，可以先完成“基础用户体系 + 题库管理 + 模拟考”这个最小闭环，之后再根据进度补知识帖子、评论、积分这些外围功能，迭代压力小。
从技术展现角度讲，它也有足够多的“亮点位”。比如考试模块可以做并发控制、防重复交卷，统计模块可以做缓存预热和定时任务，文件上传可以用本地存储或对象存储。这些单独拆出来都能作为答辩时的技术亮点，不至于被问到“你遇到过什么技术难点”时哑口无言。
2. 技术栈与数据库设计：先把底子打好，后面才不返工
2.1 选型思路：主流、稳定、资料多三原则
技术栈我推荐一套非常写实的组合：Spring Boot 2.7 + MyBatis-Plus + MySQL 8.0 + Redis 5.x + Spring Security + JWT，前端用 Vue 3 + Element Plus 做管理后台和用户端。全套都是当前中小型项目的主流方案，网上案例多，遇到问题搜得到，面试被追问也有话讲。
为什么不用 Spring Cloud 那套微服务？因为毕业设计是单机项目，微服务只会在环境配置上消耗大量时间，对业务实现没有任何实质帮助。也不要一上来就上 Sa-Token 或 Shiro，Spring Security 虽然学习曲线陡一些，但它和 JWT 的组合非常经典，写一次之后对过滤器和拦截器的理解会上一个台阶，答辩时这就是一个可聊的话题。
Redis 在这个项目里不是摆设，它要承担三件事：登录令牌的服务端校验、模拟考试过程中的临时答题状态、热点题目和知识帖子的缓存。至少这两处用它，写到论文里也有实际数据支撑，不会流于“引入了Redis做缓存”这种空话。
2.2 核心数据表的设计与字段细节
这里讲表结构设计，是很多同学最容易忽略但也是最重要的一步。我把关键表列出来并说明每张表的核心字段设计思路。
user 用户表：id 主键，username 唯一，password 存 BCrypt 加密结果，nickname 昵称，avatar 头像地址，role 字段用 tinyint，0 普通用户、1 管理员，status 0禁用1正常，points 积分字段，create_time、update_time。逻辑删除 delete_flag 也建议加上，后头统一处理。
question_category 题目分类表：按行测和申论往下细分，一层分类存 parent_id，做成树形结构。分类表设计成自关联，支持无限层级，这样后续要扩展事业单位考试或资格证考试也不用改表。
question 题目表：category_id 关联分类，type 字段区分单选题、多选题、判断题，difficulty 用1到5代表难度，content 存题干，analysis 存解析，correct_answer 存答案，score 存分值。多选题的答案建议用 JSON 数组字符串存，比如["A","B","C"]，不要用逗号拼接，因为 JSON 在后端解析方便，出题时校验也更严谨。
exam_paper 试卷表：paper_name，paper_type 区分模拟卷、真题卷，duration 分钟，total_score，status 上架下架。
exam_paper_question 试卷题目关联表：paper_id、question_id、sort_order 排序字段、score 单题分值。
exam_record 考试记录表：user_id、paper_id、start_time、submit_time、total_score、correct_count、wrong_count、duration_seconds、status 字段区分进行中、已交卷、已超时。
answer_detail 答题明细表：record_id、question_id、user_answer、is_correct，一张试卷所有答题明细都存在这里。
article 知识帖子表、article_comment 评论表，这俩就是标准的社区表，不做特殊处理。resource 公共资料表可以放用户上传的学习资料，包括标题、文件路径、下载积分、上传者。
2.3 为什么试卷题目一定要用关联表
见过有同学图省事，在 exam_paper 表里加一个 JSON 字段，把题目ID和分值直接塞进去，诸如[{"questionId": 12, "score": 2}]。这种做法写入时很舒服，但从“模拟考试自动判分”那一刻起就全是坑：你要读出题目ID去题库里查内容，每次都要反序列化，统计单题正确率得挨个解析试卷再遍历答案，分页、排序、批量操作全部受阻。
用 exam_paper_question 关联表，代价只是写试卷时多 insert 几条记录，但换来的查询能力比 JSON 方案强了几个数量级。数据库表设计遵循一个原则：你预估未来会围绕哪些字段做查询和统计，就给这些字段正规化成一个可被SQL直接引用的结构。JSON 不应该承担核心业务关系，它只适合存储不会参与条件检索的附属信息。
字段类型和索引也要提前规划。answer_detail 表要建立 (record_id, question_id) 联合唯一索引，这样既能防止同一题在一条考试记录里重复写入，也能在查看答题卡时一次查出全部明细。exam_record 表对 (user_id, status) 建复合索引，判断“这个人有没有正在进行的考试”时走索引，不要全表扫描。
3. 题库、模拟考、知识社区：三大核心模块的实现拆解
3.1 题库管理模块：从录入到刷题的完整链路
题库模块承担整个平台最核心的数据生产。管理端要支持单题录入和批量导入两类方式，我建议把批量导入设计成 Excel 模板上传，后台用 EasyExcel 解析入库。模板里需要包含分类、题型、难度、题干、选项、答案、解析这些列，多选答案用分号分隔，导入时校验数据是否合法，不合法就记录失败行号返回给前端提示。
用户端的刷题页面要考虑筛选体验：按分类、难度、题型三个维度组合筛选，题目逐题展示，用户选择答案后立即显示正确与否并展示解析。这里正向的交互是：用户点击提交答案后，后端只判断对错并返回结果，不直接把正确答案塞给前端。正确答案只在用户答完这道题之后才返回，避免前端源码里泄露所有答案。
题库的加分项是“错题本”功能。用户答错的题目自动写入错题表，之后用户可以从错题本进入专项练习，重做后如果答对了就可以移出错题本。这个功能逻辑不难，但很提升使用体验，论文里也好写，值得加上。
这个模块的代码量会占整个项目三分之一左右，因为它涉及页面多、接口多。但我建议你不要为了数量而省略质量，做题判分、错题记录、刷题历史这些接口都要做，因为它们是后续统计模块的数据来源，缺一个统计就少一块。
4. 权限与考试场景：最容易翻车的两个硬骨头
4.1 Spring Security + JWT 的用户认证与权限控制
用户认证这块，我直接说结论：用 Spring Security 过滤器链 + JWT 无状态令牌。用户登录后，后端签发一个 JWT，里面带上 userId 和 role，之后每次请求在请求头里带上Authorization: Bearer token，后端在过滤器中解析 token 并放入 SecurityContext。
为什么不用传统的 Session？因为毕业设计一般是前后端分离部署，如果走 Session，前端每次请求都要带 Cookie，跨域情况下处理相对繁琐，还要额外维护 Session 存储。JWT 把用户身份信息直接编码在令牌里，前端只需要保存 token，后端无状态，部署和联调都省心不少。
但 JWT 有一个银行里也不会跟你说的坑：服务端无法主动让 token 失效。用户退出登录后，如果 token 泄露，在过期之前一直有效。我的处理方式是把 token 的 jti（唯一ID）在登录时同步存进 Redis，设置和 token 一样的过期时间，然后在过滤器里校验 Redis 中是否存在这个 jti。这样退出登录时删除 Redis 中的记录，可以达到实质上“服务端注销”的效果。虽然牺牲了一点无状态性，但换来了可管控的安全度，答辩时说这是权衡之后的结果，老师是不会挑毛病的。
控制层权限用注解实现。管理员接口统一加上@PreAuthorize("hasRole('ADMIN')")，开启方法级安全后，普通用户调用这些接口会被拦截。注意角色的写法，Spring Security 会自动给角色加ROLE_前缀，自定义时别搞混。
4.2 模拟考试的并发与防作弊设计
模拟考试是整个项目技术含量最高的模块，也是最容易翻车的地方。先说并发问题：用户点“开始考试”时，系统要生成一份试卷并创建一个进行中的考试记录。如果用户连续点了两次开始，就会产生两条进行中的记录。解决方法是给 exam_record 表加 (user_id, status) 的普通索引还不够，必须用代码逻辑判断：开始考试接口先查询 status=进行中 的记录，有的话直接返回“请先完成上一场考试”，没有才创建。两个请求同时进来时，单机情况下这行查询会在数据库层面串行执行，配合事务可以防住绝大多数场景。
答题状态为什么不直接写 MySQL？如果用户每答一题就 insert 一条 answer_detail，交卷时再更新判分结果，一场30道题的考试会引发几十次数据库写操作，在线用户多了以后数据库压力非常大。我的做法是把答题过程放到 Redis 里，用 hash 结构存储recordId -> {questionId: userAnswer}，用户每答一题更新 Redis 中的 hash，交卷时一次性取出全部答案，批量判分后统一写入 answer_detail 表。这样考试期间的数据库写入只有创建考试记录和交卷两个动作，性能压力小很多，而且交卷后还能一次性清掉 Redis 中的临时数据。
防作弊的另一个点是倒计时。前端倒计时肯定靠前端定时器来实现，可以做，但最终还是要以后端时间为准。用户交卷时，后端拿当前时间和考试记录里的 start_time 计算实际用时时长，超过试卷设定时长就强制按超时处理，未答题目记错。这样即使用户在浏览器里改系统时间，也无法突破后端的时间计算。同时，前端倒计时到零时主动调交卷接口也是一种兜底。
“自动判分”的实现逻辑是把 answer_detail 里每一题的用户答案和 question 表的 correct_answer 对比，逐题判断后汇总分数。这里特别提醒多选题判分规则要想清楚：是“选对且无多选漏选才得分”，还是“漏选得一半分”，这个规则要在判分方法里写清楚，并且在前端答题卡上给出明确的提示，否则用户会觉得自己明明选对了却得了零分。
5. 解密“隐形”加分项：缓存一致性与统计分析的落地
5.1 缓存更新：题目修改了，用户为什么还能看到旧题
你在做这个项目时，一定会遇到这样的问题：管理员在后台改了一道题的解析，但用户刷新页面，看到的还是旧内容。这是典型的缓存一致性问题。
我的缓存策略是“先更新数据库，再删除缓存”。管理员修改题目后，先执行 update 语句更新 MySQL，然后删除 Redis 中对应的题目缓存，下次用户请求题目时，缓存未命中，会查数据库并把新数据写回缓存。这个顺序在绝大多数情况下能保证一致性。
为什么不先删缓存再更新数据库？因为在两个操作之间如果正好有用户请求，他会把旧数据重新写进缓存，导致删除操作白做了。先更新数据库但删除缓存失败时，可以通过消息队列补偿删除，但毕业设计里不需要做到那么重，直接删除后如果失败记录日志，由定时任务统一补偿即可。能讲清楚这个方案为什么选“先更新数据库再删缓存”，比单纯完成功能要深刻得多。
考试过程中涉及的大量题目读取，正好是缓存发挥作用的地方。考生点开始考试后，系统把试卷对应题目的题干和选项加载到 Redis，后续答题过程中前端调获取题目详情接口，都优先从缓存读，交卷后再清理。这也是我前面说答题状态放 Redis 的延续逻辑，整个考试环节彻底和 MySQL 解耦，接口响应速度会明显优于直接查库。
5.2 学习统计：不做预聚合，报表查询会很痛苦
知识共享平台的数据统计功能，如果只是简单地“查记录然后数数”，前期数据量小还撑得住，但题库刷题的用户只要积累几千条答题记录，统计接口就会开始变慢。我的做法是建一张 user_statistics 统计表，字段包括 user_id、total_answer_count、correct_count、wrong_count、accuracy_rate、study_days 等，每次用户交卷后，在一个事务里更新这张表。
交卷时先批量插入答案明细，再更新 user_statistics 里的累计值，两个动作放在同一个事务里要么都成功要么都失败，不会出现答题记录写入了但统计没更新的情况。学习趋势图要展示“最近7天每天做了多少题、正确率多少”时，再单独建一张 daily_study_record 表，每天用户答完第一道题时创建当天记录，后续作答只更新累计值，这样统计趋势查询只需要分组查这张日表，速度快得多。
定时任务在 Spring Boot 里用@Scheduled注解就能写，比如每天凌晨统计所有用户的学习天数，把连续签到的数据刷进 Redis，方便前端展示排行榜。排行榜用 ZSet 存储用户ID和积分，取前十名就是一条 ZSet 操作，秒出结果。统计模块适合最后做，但设计表的时候就要把 user_statistics 的更新逻辑留好，否则后面加功能区要动已完成的模块，容易出低级bug。
6. 答辩与项目包装：源码跑通只是及格线，思路才是高分项
6.1 项目结构怎么组织才显功底
源码结构上，我建议用标准的分层架构：controller、service、mapper、entity、dto、vo、config、common。common 里统一放返回值封装类、异常处理类、常量类；config 里放 Redis 配置、Security 配置、MyBatis-Plus 配置、跨域配置。dto 和 vo 分开是我特别想强调的一点：前端传给后端的数据结构用 dto，后端返回前端的数据结构用 vo，不要让 entity 直接暴露给前端。
用实体类直接做接口返回类型虽然快，但会有两个问题：一是数据库字段可能包含不想暴露的信息，比如密码；二是接口字段和前端展示字段不匹配时，要在实体里堆很多无关字段。dto 和 vo 分离之后，接口文档也更清晰，算是一个很加分的工程习惯。
另外尽量把接口文档做出来，不一定非要用 Swagger 或 Knife4j，至少把所有 controller 的接口路径、请求参数、返回结构整理清楚。答辩时老师大概率会抽查几个接口看逻辑，文档整理得好，会让他觉得这个项目是完整的产品而不是临时拼凑的 demo。
6.2 常见追问的应对思路
答辩时老师最喜欢问的问题不外乎四类：为什么用这个技术、这个功能怎么实现的、数据量大了会怎样、遇到了哪些坑。提前准备答案，比临场编要游刃得多。
比如“为什么用 Redis 存考试状态，而不是直接写数据库”，回答要点是：答题是高频操作，写库会造成频繁 IO，Redis 内存操作快得多，而且可以用过期策略兜底处理异常退出。回答完可以补一句“但 Redis 可能丢数据，所以交卷时的落库操作必须保证原子性”，会显得你考虑过数据安全问题。
“你这个权限控制是怎么做的”，回答框架是：登录签发 JWT，过滤器解析 token，Spring Security 断言角色，管理员接口通过 @PreAuthorize 注解限制访问。如果继续问“用户越权访问别人的考试记录呢”，就答“查询接口里强制拼接 userId 条件，数据范围控制在当前登录用户内”。这两层叠加就是“认证 + 鉴权 + 数据权限”三层模型，是一个很完整的安全设计思路。
问到“你的误差风险在哪、能继续怎么扩展”，可以从三个方向准备：一是答题数据量大可以做分库分表或引入消息队列异步判分；二是视频课程、直播辅导这类在线教育玩法还没有覆盖；三是知识推荐可以基于用户做题标签做机器学习模型。不必深入细节，但每一条都要能说出大概思路，这会是整个答辩里最出彩的部分。
回到开头那个问题：Spring Boot 公务员考试知识共享平台是不是一个好做的毕业设计题目？在我看，它确实是个稳妥且有余地的选择。它的下限是“管理端 + 用户端 + 刷题判分”的传统套路题，上限是“在线评测引擎 + 知识社区 + 数据统计”的产品级系统，做深做浅全看你自己怎么取舍。这也正是它反复出现在各种毕业设计推荐清单里的根本原因——业务逻辑足够真实，技术点足够通用，源代码结构又能清晰展示你的工程能力。
最后再分享一个我自己的纪律：做这类带“共享”二字的项目，最容易犯的错是过分关注题目库的数量和页面样式，却忽略了数据闭环。题库导入了几千道题，用户答题记录却没有统计，错题本与答题记录对不上，积分规则只在注册时发一次——功能之间断开是非常明显的破绽。宁可题目少一点，也要保证“发帖-评论-积分-用户等级-排行榜”或者“刷题-判分-错题本-统计”这条业务链路是完整打通的。闭环在，项目的可信度就在，这个故事就能自圆其说，比堆一百个孤立的页面更能打动人。
