前段时间帮朋友看毕业设计选题清单一眼扫过去十个里有六个是XX管理系统——图书馆、停车场、宿舍、实验室换了个业务名词技术结构几乎一模一样。我当时就建议想从一堆管理系统里跳出来不如考虑做面试刷题平台这类带有明显业务闭环的项目。用JavaSpringBoot整合SSM这套技术组合来实现一个面试刷题平台系统既能覆盖数据建模、接口设计、权限管理这些基本功又涉及随机组卷、答题判分、错题收敛、统计报表这些有真实业务味道的功能做完之后无论写在简历里还是拿去答辩都有实实在在的东西可以讲。我自己在动手之前把市面上几个公开的刷题网站都研究了一遍又找了好几位正在春招的同学聊需求最后落地的方案是一个前后端分离的Web应用用户端负责注册登录、浏览题库、刷题练习、记录错题、查看学习统计管理端负责维护题目、管理分类、运营用户数据。整篇文章我会把从立项到调试部署的完整过程拆开讲重点放在那些让我熬夜排查的问题上给准备做类似项目或者学习SpringBoot的同学一份可以直接参考的实操笔记。1. 立项思考为什么选面试刷题平台而不是普通管理系统这个题目不是拍脑袋定的。在确定之前我列了一堆候选对比之后发现刷题平台有几个天然优势业务场景真实、功能边界清晰、技术点覆盖全面而且用户能直观感受到系统的价值。下面说清楚我到底怎么拆解需求以及这个系统比普通管理系统多出来的设计亮点。1.1 从真实场景出发刷题这件事有哪些人、哪些事要做任何一个合格的选题第一步不是画原型而是先把角色和场景盘清楚。我梳理了刷题平台涉及的两类核心角色每个角色都有明确的痛点。对于求职者来说他打开一个刷题网站要完成的核心动作是找到一套题、开始作答、提交看结果、把不会的题记下来、隔段时间回来重新做。这里面隐含的需求是题目要足够多、分类要清楚、能随机抽题、能自动判分、能记录历史、能统计薄弱点。如果只是把题目堆在页面上让用户自己翻那和买一本习题集没有任何区别也就失去了做平台的意义。对于管理员或者说内容运营者来说他关心的是题目怎么录进去、怎么分类、怎么看用户量、用户刷得怎么样。所以管理端必须有题库管理、分类管理、用户管理、基础数据统计这些能力。1.2 相比传统管理系统的差异化设计点普通管理系统做的是什么用户表、权限表、业务表的增删改查本质上是一个数据管理后台。面试刷题平台的不同在于它有一条完整的业务链路用户进入系统 → 选择题目 → 提交答案 → 系统判分 → 错题入库 → 再次练习 → 形成学习曲线。每个环节都要有对应的数据结构和业务逻辑去支撑。这条闭环里最有意思的三个点第一是随机组卷不能每次都出同样的题否则题库就失去了练习价值第二是自动判分主观题和客观题的判分逻辑完全不同不能简单用一个if else糊弄过去第三是错题管理用户做错的题如何进入错题本、如何支持后续的重做和移除这直接体现了系统有没有用心设计。这些点加在一起整个项目就不再是管理系统的换皮而是有真实业务价值的学习工具。1.3 适合拿来练手的人群和学习目标如果你正在准备Java方向的毕设、课设或者想巩固SpringBoot和SSM技术栈这个题目的难度曲线非常友好。它没有微服务、没有分布式、没有消息队列那些复杂概念但又能让你把SpringBoot整合MyBatis的完整流程、JWT无状态认证、AOP日志、统一异常处理、事务管理等高频知识点全部过一遍。做完之后你对一套Web系统的整体认知会清晰很多面试时聊项目也更有底气。2. 系统功能全景用户端、管理端与刷题闭环功能设计阶段我把整个系统的功能清单拆成了三层用户端、管理端、公共支撑层。下面这张表是我在需求分析阶段整理出来的最终版本后面所有开发工作都围绕它展开。模块子功能说明用户端注册登录用户名密码登录支持JWT无状态认证用户端题库浏览按分类/难度筛选题目支持分页用户端刷题练习随机组卷、顺序练习、模拟测试用户端答题判分客观题自动判分主观题自评模式用户端错题本错题自动收录支持移除与重做用户端学习统计答题数量、正确率、分类短板分析管理端题目管理题目的增删改查、批量导入管理端分类管理题目分类的维护与排序管理端用户管理用户列表、状态启用禁用、角色分配管理端数据看板注册人数、刷题次数等基础运营指标公共支撑统一认证基于拦截器与JWT的接口鉴权公共支撑日志与异常AOP记录操作日志全局异常处理器2.1 用户端核心流程注册到完成一次有效刷题用户端的流程我反复画了好几版最终收敛成一条简洁的主链路。用户注册登录之后进入首页首页不做花哨的营销内容直接展示题库分类入口和个人学习概览。用户点进某个分类可以选择随机练习或者模拟测试。随机练习每次出10题做完单题立即判分模拟测试按配置好的题量统一出题全部答完才统一提交更接近真实面试场景。答题页面有一个细节值得强调题目区域要同时展示题干、选项和答题区用户提交之后立刻显示正确答案和解析。我把解析做成可展开的折叠面板没提交前不显示提交后才打开。这个交互虽然简单但很符合用户刷题的实际心理——先自己思考再查看答案这比题目旁边直接挂着解析体验好很多。2.2 管理端设计内容治理比想象中重要管理端一开始我只规划了简单的增删改查但随着题目数量变大我发现纯手工录入根本撑不住。后来补了批量导入功能支持通过Excel模板一次性导入100条题目。导入逻辑里做了三个校验题干不能为空、选项数量不能少于两个、答案必须在选项范围内。校验失败的行会标注错误原因返回给前端用户修正后可以重新导入。题目管理列表也做了优化。题目多了之后管理端列表页必须要能组合筛选按分类筛、按难度筛、按题型筛、按关键字搜索。这些筛选条件在后端用一个动态SQL方法拼接查询条件MyBatis的Provider特性在这里非常适用避免了拼接SQL串的代码地狱。2.3 权限模型三类角色的职责边界怎么划分系统需要区分管理员和普通用户我采用了简单的RBAC角色模型没有引入复杂的权限框架而是自定义了基于JWT的角色校验。用户表里存一个role字段值为USER或者ADMIN。登录成功后JWT的payload里带上角色信息后端拦截器解析Token后把用户信息放进ThreadLocal业务方法里用自定义注解标记是否需要管理员权限。这套方案的优点是轻量、好理解、学习价值高。实际开发中我没有引入Shiro或者Spring Security因为Spring Security的过滤器链和认证体系对这个项目来说有点重且学习成本高。抱着练手和展示技术深度的目标自定义拦截器加注解反而能把认证原理讲得更清楚。3. 技术选型SpringBoot与SSM的组合逻辑很多同学看到SpringBootSSM这个说法会困惑其实这里要澄清一个概念。SSM原本指的是SpringSpringMVCMyBatis三件套而SpringBoot本身就已经内置了SpringMVC能力所以真正落地的时候这套技术栈指的是SpringBoot作为基础框架整合MyBatis作为ORM使用SpringMVC的注解方式来写接口。也就是说并不存在SpringBoot之外再单独配一套SSM的做法而是SpringBoot把SSM中的Spring和SpringMVC已经包进去了我们主要补充处理MyBatis的整合部分。3.1 为什么这样选技术栈的优势与适用范围这套组合在中小型Web项目中几乎是最稳的选择。SpringBoot负责自动化配置和快速启动MyBatis负责灵活的SQL控制SpringMVC负责HTTP层的路由和参数绑定。相比JPA的自动建表和抽象查询MyBatis的映射文件能精确控制每一条SQL对于刷题平台这种查询条件复杂、表关联多的场景手写SQL反而更直观。另外这套技术栈对初学者非常友好。因为SpringBoot的starter机制绝大部分配置都是约定大于配置不需要手动搞一大堆XML文件。项目结构清晰排查问题的时候能顺着Controller→Service→Mapper这条线一层层找不像微服务那样一报错就要翻日志链路。3.2 项目结构与依赖组织方式我的项目采用标准的Maven多模块结构但考虑到这个项目规模不大主工程只有一个模块按照包名分层前端是一个独立的Vue项目。后端包的划分如下entity存放数据库实体mapper存放MyBatis接口和XML文件service存放业务逻辑controller存放接口入口config存放配置类common存放通用工具和统一返回结果security存放JWT和拦截器。pom.xml里最关键的几个依赖是spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-java、jjwt、hutool。hutool是一把瑞士军刀里面封装了Excel读写、日期处理、加密工具等常用能力批量导入题目时可以直接用hutool的ExcelUtil解析上传的Excel省了不少事。3.3 ORM映射的细节为什么MyBatis在这类场景更顺手写SQL的过程中我体会最深的一点是MyBatis的灵活性在处理统计查询时简直是降维打击。比如学习统计模块要查用户近七天的正确率趋势用一个带条件聚合的SQL就能一次查出来如果用JPA要么写JPQL要么查全表在应用层筛性能和可维护性都差很多。Mapper的XML文件里我统一管理了所有复杂的动态SQLJava代码里只留简单的接口定义。查询条件多的时候用if标签拼接分页用PageHelper插件批量插入用foreach标签每个场景都有对应的最佳实践这也是MyBatis能在中国Java社区经久不衰的原因。4. 数据库设计支撑刷题闭环的表结构与索引策略表设计是整个系统的地基。我画ER图的时候一直在想一个问题用户做完一道题系统里要产生多少数据、这些数据之间怎么流转最终我设计了6张核心表用户表、分类表、题目表、答题记录表、错题表、刷题统计表。下面重点讲清楚题目模型和答题记录这两块因为它们直接决定了刷题功能能做得多深。4.1 题目模型设计怎么把多种题型塞进一张表题目表是系统里最关键的表。面试刷题平台常见的题型有单选题、多选题、判断题、问答题。为了不过度设计我把题目统一放进一张表用一个type字段区分题型。核心字段包括题干、选项A/B/C/D用四个可空字段存储、正确选项、题目解析、难度等级、所属分类ID、题型、创建时间。这里有个设计取舍为什么不把选项单独拆成一张子表原因是平台90%的题目都是选择题和判断题选项数量固定在4个以内用四个冗余字段存储可以大幅简化查询逻辑。如果要支持不定项选项或者以后扩展填空题再拆子表也不迟。好的表设计不是追求理论上的完美范式而是在当前业务下保持简洁可维护。4.2 答题记录与错题本的数据流转答题记录表记录了每一次刷题行为的明细每答一道题生成一条记录字段包括用户ID、题目ID、所选答案、是否正确、作答时间。这张表的数据量会随着用户使用逐渐变大所以设计时必须建好联合索引一般按用户ID和作答时间建组合索引保证查某个人的历史记录时能走索引。错题表和答题记录表不同它只记录做错的题且同一道题对同一用户只能有一条记录。每次用户答错时我先查错题表是否已有记录如果存在则更新重错次数如果不存在则插入新记录。用户之后重做答对可以选择手动移除错题。这条逻辑让我想明白了一件事业务上重复做错和首次做错是两种不同的学习信号保留错题次数能让后续的学习统计更有说服力。4.3 索引设计让题库查询和学习统计保持流畅索引方面我踩过一个明显的坑测试阶段数据量只有几百条什么查询都快等批量导入了上万条题目之后模拟测试的随机抽题接口一下子慢了明显感觉有延迟。排查发现随机抽题用的SQL是ORDER BY RAND()这个写法在数据量大的时候会让数据库全表扫描非常慢。后来我改成了分段取随机ID的方案第一步查出当前条件下符合筛选条件的题目ID列表第二步在应用层随机选出N个ID第三步通过WHERE id IN (...)查询出完整题目。这个方案把随机性拿到应用层处理数据库只需要做一次普通范围查询上万条数据的场景下接口响应时间从一千多毫秒降到了五十毫秒以内。具体代码会在下一个部分详细说。5. 核心功能实现随机组卷、答题判分与进度统计这一章是整个项目最核心的价值所在。我会把随机组卷策略、答题提交的判分事务、学习统计的SQL实现都展开讲因为这些内容才是面试刷题平台区别于普通管理系统的真正亮点。5.1 随机组卷策略不要再用ORDER BY RAND()组卷功能的需求是用户在某个分类下发起随机练习时从该分类包含的题目中随机抽取N道题。最直觉的写法是SELECT * FROM question WHERE category_id ? ORDER BY RAND() LIMIT ?简单确实简单但数据量上来之后性能无法接受。我最终采用的方案是两步走。第一步查询该分类下所有符合条件的题目ID集合这一步的SQL很简单。SELECT id FROM question WHERE category_id #{categoryId} AND status 1 AND (difficulty #{difficulty} OR #{difficulty} IS NULL)第二步在Service层用Java的Collections.shuffle方法打乱List然后截取前N个ID作为本次组卷的题目。ListLong idList questionMapper.selectIdList(categoryId, difficulty); Collections.shuffle(idList); ListLong pickedIds idList.stream().limit(questionCount).collect(Collectors.toList()); ListQuestion questionList questionMapper.selectBatchByIds(pickedIds);这套方案的优点是灵活度和性能兼得筛选条件可以随便加不需要拼复杂SQLID列表可能达到几千条在内存里打乱完全没问题最终查询一次就能把整组题目拉出来。实测一万条数据、随机抽5题的场景接口耗时稳定在几十毫秒。5.2 答题提交与判分事务边界和状态设计用户提交一组答案后后端要一次性完成多件事逐题判分、写答题记录、更新错题表、更新统计表。这几件事只要有一件失败整个操作都应该回滚否则会出现答案已提交但错题没记上这种数据不一致问题。所以我用Transactional把提交逻辑包在同一个事务里。判分逻辑按题型分开处理单选题和判断题直接比对用户选项和正确答案字段多选题要求用户选项集合和正确答案集合完全一致顺序无关问答题不自动判分默认记为待自评由用户自己对照参考答案判断对错然后手动标记已掌握或者加入错题本。事务提交之前我把答题记录一条条批量插入然后查出本次答错的题去维护错题表。这里为了减少数据库交互我没有在循环里逐个insert而是先把答题记录累积成List最后用MyBatis的foreach做批量插入一次性完成。5.3 学习统计用一条SQL算出学习曲线学习统计模块预览页面要展示的数据包括累计刷题数、累计正确率、今日刷题数、分类正确率排名、近七天每日正确率趋势。这些数据分别来自答题记录表和错题表其中近七天正确率是最能体现学习状态变化的指标。实现思路是查询近7天每天的正确率和答题量SQL如下SELECT DATE(create_time) AS day, COUNT(*) AS total, SUM(CASE WHEN is_correct 1 THEN 1 ELSE 0 END) AS correct FROM answer_record WHERE user_id #{userId} AND create_time DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(create_time) ORDER BY day这个SQL在数据量小的时候没有任何问题但如果用户答题记录非常多DATE(create_time)会放弃索引扫描。优化做法是单独加一个day字段插入答题记录时就把日期冗余存进去查询时直接对day字段分组。我把这个优化加进去之后统计接口的响应稳定保持在100毫秒内这个体验对用户来说是很顺滑的。6. 调试与部署阶段的高频问题排查开发过程中的坑主要集中在环境、联调、部署三个环节。我整理出4个最有代表性的问题每一个都花了超过半小时排查写出来给后来人省点时间。6.1 数据库连接与中文乱码问题本地启动一切正常往服务器上一放插入中文就变成问号。排查链路如下先看数据库连接URL有没有指定characterEncoding。jdbc:mysql://localhost:3306/interview_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai确认URL没问题之后查数据库、表的字符集发现建表时默认使用了latin1。解决方法是把表字符集改成utf8mb4。这里提醒一下不要只改表字符集已经存在的字段也要改ALTER TABLE question CONVERT TO CHARACTER SET utf8mb4。这个坑让我学会了建库建表之前先把默认字符集检查一遍。6.2 前后端联调时踩到的跨域问题前端Vue单独起了开发服务器后端口是8080直接请求接口必然遇到跨域。一开始我在后端写了一个CorsFilter来放行所有来源开发阶段没问题部署之后发现带着登录凭证的请求依然被拦截。后来我才反应过来跨域配置如果允许的来源写的是*浏览器在请求带cookie或Authorization头的时候是不允许通配符匹配的。正确做法是明确写出允许的来源地址。我改成读取配置文件的cors.allowed-origins配置项指定具体的域名和端口同时allowCredentials设为true问题就解决了。6.3 打包部署时的静态资源路径问题这个项目前后端分离所以不涉及静态资源打包进JAR的问题。但我帮其他同学排查过类似的坑如果把Vue打包后的dist目录放到了SpringBoot的static下面刷新页面会出现404。原因是前端路由用的history模式后端没有做对应的路径转发。解决方法是配置一个路由重定向把没有匹配到的请求统一返回前端入口的index.html。这里特别提醒如果你用的是history路由模式部署时一定要处理后端兜底逻辑否则用户一刷新就白屏体验非常差。6.4 上线之后遇到的高并发刷题场景模拟测试功能上线之后我观察到一个现象某天集中有几十个人同时发起模拟测试数据库连接池被打满。SpringBoot默认的HikariCP最大连接数是10每个组卷请求从查ID列表到批量查题目至少占用两次数据库连接并发一上来连接就不够用了。我的调整是把最大连接数调到50并做了一个简单的内存缓存把每个分类下符合条件的题目ID列表缓存到Redis设置30分钟过期。用户发起随机组卷时优先从缓存读ID列表只有缓存未命中才查数据库。这个优化之后同样的并发量下数据库压力降了一大半接口响应速度也更稳定。整个项目从立项到稳定运行我前前后后用了三周时间。最强烈的感受是一个看起来不复杂的刷题平台真正做起来才知道业务细节都在看不见的地方——事务边界怎么划、随机性怎么实现、统计怎么做索引优化、部署之后怎么保证稳定性每一个点都有值得深挖的空间。如果你正打算拿这个题目练手我建议不要急着写代码先把题库分类、答题流程、错题流转这些业务规则用大白话写清楚后面开发会顺畅很多。遇到问题的时候也别慌按照环境问题还是代码问题→复现路径→日志定位→最小化验证这个思路去排查大部分坑都能在半小时内解决。