SpringBoot+小程序驾校考试模拟系统：从需求分析到部署答辩全流程

1. 驾校考试模拟系统：这个毕业设计题目为什么值得做

每年到毕业设计选题季，总有一批同学在"做什么题目"上反复纠结。太简单的怕过不了关，太复杂的怕自己搞不定，太冷门的怕找不到参考资料。基于springboot+小程序的驾校考试模拟系统，恰恰属于那种"难度适中、需求明确、技术栈主流、演示效果好"的题目——后端用Java生态里最主流的springboot框架，前端用微信小程序，业务场景是所有人都熟悉的驾考理论考试。

先说清楚这套系统到底长什么样。简单来说，它解决的是一个非常具体的痛点：驾校学员练科目一和科目四理论题的时候，不能只靠翻纸质书或者在电脑前刷题，而是希望随时掏出手机就能做几道题，做完能立刻看到对错、有解析、有错题记录，甚至能来一场仿真模拟考试，测一测自己有没有把握去考场。对驾校管理员来说，他们需要能管理题库、查看学员的练习情况、统计考试通过率。整套系统拆开就是两个端：学员用的小程序端（做题、模考、错题本、个人中心），管理员用的后台管理端（题库管理、学员管理、数据统计）。

很多同学拿到这类题目容易犯一个错误：一头扎进代码里，先把登录注册写了，然后开始写题库CRUD，结果做着做着发现业务逻辑理不清，表结构设计得乱七八糟，做到一半想改又不敢改。我自己的经验是，毕业设计真正难的不是某个技术点，而是"需求边界"和"数据模型"这两件事。前者决定你要做多少功能，后者决定你做起来顺不顺。

这个题目适合谁？适合有一定Java基础、熟悉springboot基本用法的同学，也适合那些"Java基础一般但愿意花时间查资料"的同学。小程序端不需要你会原生安卓或iOS开发，微信小程序的那套WXML+JS就够用；后端也不需要你玩得很花哨，springboot+MyBatis-Plus+MySQL就是一套非常成熟稳妥的组合。做完之后，你既能把springboot的接口开发流程串一遍，又能接触小程序的前端开发，还能把"前后端联调"这种真实项目里天天干的事体验一遍，性价比非常高。

这篇博文我就以这个项目为例子，把从需求分析、架构设计、核心功能实现到远程调试、文档撰写、答辩准备的完整链路都捋一遍。我不会只丢给你一堆代码片段，而是会告诉你每一块为什么这么设计、在实现过程中一般会遇到哪些坑、怎么排错、怎么跟老师解释你的设计思路。这样无论你是想直接参考这个题目做毕业设计，还是想理解springboot+小程序项目的一般套路，都能少走很多弯路。

2. 从业务场景到功能清单：先把需求边界划清楚

这一节是整个项目的地基，地基没打好，后面写代码就是给自己挖坑。很多同学拿到题目之后的第一反应是"先把环境搭起来，跑一个hello world看看"，但真正有经验的做法是先把"这个系统到底给谁用、他们分别要干什么、数据从哪来到哪去"想明白。

2.1 用户角色与核心业务流程

驾校考试模拟系统里面，核心角色有三个，虽然管理员在演示阶段可能没那么显眼，但它的存在决定了整个系统的闭环能不能成立。

第一个是学员。学员在小程序端做的事情非常聚焦：选科目（科目一或科目四）、开始练习或模拟考试、查看答题结果和解析、查看错题本、查看自己的考试记录和成绩趋势。学员是不会去后台管理系统点来点去的，他所有的操作都在小程序里完成。

第二个是管理员。管理员在后台管理端维护系统运行的基础数据：管理试题（新增、修改、删除、上下架、按科目分类）、管理公告、查看学员列表和学员的模考成绩，必要的时候还可以手动帮助学员重置密码之类。这块界面不需要做得花里胡哨，但功能要完整，逻辑要能自洽。

第三个是系统本身需要考虑的一个隐含角色——那就是"考试规则"。科目一和科目四的考试规则在现实中是有明确规定的：比如科目一共100题，每题1分，90分及格，考试时间45分钟；科目四共50题，每题2分，90分及格，考试时间30分钟。这些规则不是拍脑袋定的，而是这个系统的业务核心。你的模拟考试模块必须按照这个规则来出题、计时、算分、判断是否合格。

我把这些梳理成一张简单的功能矩阵表，你照着这个表去设计页面和接口就够了：

有人可能会问：管理员登录怎么处理？两种常见方案——一种是管理员直接走后端单独的管理系统页面（比如springboot+Thymeleaf或者vue管理后台），另一种是共用小程序，管理员用单独入口登录。考虑到毕业设计的演示成本和开发量，我更推荐后端的web管理界面用springboot直接渲染一个简单的后台页面，或者如果你时间充裕，用vue搞一个更现代的管理端也行。但从"稳稳做完"的角度看，springboot+Thymeleaf足以把后台功能演示明白，还省去了部署两个前端项目的麻烦。

2.2 数据库设计：把表结构先定下来

业务功能理清之后，数据库表结构就顺理成章了。这个系统核心表大概有六张左右，我逐个说设计思路。

用户表（user / student）：字段包括openid（微信openid，用于小程序登录识别）、昵称、头像、手机号、角色（学员/管理员）、状态（正常/禁用）、创建时间。特别注意openid要加唯一索引，否则同一个微信用户反复登录会生成多条脏数据。

题目表（question）：字段包括题目内容、选项A/B/C/D、正确答案、题目解析、所属科目（1或4）、题型（单选/判断）、难度级别、状态（启用/禁用）。这里有个细节要注意：判断题在数据表里可以存成"正确/错误"两个选项，也可以单独用type字段区分，我的建议是统一用选择题的结构存，判断题就变成只有两个选项的特殊选择题，判分逻辑完全统一，省事很多。

题目分类表（category）：如果题目量很大，可能需要按章节或者知识点分类，比如"交通信号""安全行车常识""法律法规"等。这个表不是必须的，但有了它，学员刷题时可以按专项练习，演示的时候也更像样。

考试记录表（exam_record）：字段包括用户ID、科目、试卷总分、得分、及格状态、用时、创建时间。这张表是后期统计的核心数据来源，管理员看通过率、学员看历史成绩趋势，都查它。

答题明细表（exam_detail）：记录每一次考试/练习中每道题的对错、所选答案。这张表的作用是支撑错题本和答题回顾——不然你只存一个总分，学员想看"我到底哪道题做错了"就没法实现了。

错题本表（wrong_question）：字段包括用户ID、题目ID、错误次数、最后错误时间。从答题明细表里可以汇总生成错题本，但单独建一张表的好处是查起来快，而且可以做"移出错题本"操作。

公告表（notice）：标题、内容、发布时间、状态。功能不复杂，但考研的是你对基础功能完整性的把握。

建表的时候有几个容易踩的坑。一是字符集：表结构里默认utf8mb4，不然微信昵称里的emoji表情存进去会变成问号。二是题目表里正确答案字段最好存的是"答案选项"（比如A/B/C/D），而不是存答案文本，这样判卷逻辑好写。三是所有时间字段建议用datetime类型，不要用varchar存时间字符串，否则后面做统计报表的时候巨痛苦。四是逻辑删除字段（deleted）这种"行业惯例"可以加，但别过度设计，加个is_deleted字段然后配合MyBatis-Plus的逻辑删除注解就够用了。

3. 技术栈选择与项目架构：为什么是springboot+小程序这个组合

这个题目之所以在国内毕业设计里出现频率极高，根本原因不是它多先进，而是它特别"稳"。SpringBoot解决的是后端开发效率的问题，微信小程序解决的是C端触达的问题，两者组合起来，整个项目的技术路线清晰、生态成熟、参考资料多、出bug也好排查。

3.1 后端为什么是springboot不是SSH不是PHP

很多年前做毕业设计流行SSH（Struts+Spring+Hibernate）或者SSM（Spring+SpringMVC+MyBatis），现在几乎都切到springboot了。原因很简单：springboot把配置简化到了极致，内嵌Tomcat，一个main方法就能跑起来。对于毕业设计来说，这意味着你不需要在"搭环境"这件事上花两周时间，而是可以直接进入业务开发。

再说持久层框架。现在国内公司里MyBatis-Plus的占有率很高，因为它把单表CRUD基本都封装好了，你不需要写一堆重复的XML mapper文件。在这个项目里，90%的数据库操作都是单表查询，少数联表查询比如"查学员最近的考试记录连带题目信息"，你完全可以用MyBatis-Plus的分页插件加简单的自定义SQL搞定。如果纯用MyBatis，代码量会膨胀不少；用JPA的话，虽然可以少写SQL，但一些复杂点的查询反而不好控制。所以MyBatis-Plus是我在这个项目上的首选。

前端界面我建议直接用微信小程序原生框架，不要去折腾uni-app或者Taro这种跨端框架。理由也很实际：一是这道题的核心是"微信小程序"，老师看重的就是你有没有掌握小程序原生的组件、API、生命周期这些基本功；二是原生框架排错方便，编译报错信息直接，社区问答资料也丰富；三是uni-app虽然一套代码多端复用，但面试时反而容易被追问"那你对小程序原生组件熟悉吗"，你要是没真正用过原生开发，容易露怯。

3.2 前后端交互的逻辑与接口约定

整个项目本质上是一个典型的"前后端分离"架构：小程序端负责界面展示和用户交互，springboot后端负责业务逻辑和数据处理，双方通过HTTP接口通信，数据格式统一用JSON。

实际开发中，前后端联调最怕的就是"各说各话"。所以接口设计从第一天就要规范化。拿这个项目的几个核心接口举例：

小程序端登录时，前端调用wx.login()获取到临时code，然后把这个code传给后端接口POST /api/user/login，后端拿着code调用微信的jscode2session接口换取openid，查数据库——如果这个openid存在就正常登录，不存在就自动注册一个用户，然后返回自定义登录态token给小程序端，小程序把token存到storage里，后续每个请求的header里都带上token。

刷题接口GET /api/question/list?category=1&page=1&limit=10，返回的是题目列表，但要注意选项字段的设计。前端要展示的选项ABCD和对应内容，后端最好直接返回整个对象，不要返回拼接好的字符串，这样前端渲染更灵活。

交卷接口POST /api/exam/submit，请求体是{ userId, subject, answers: [{ questionId, answer }] }，后端收到后进行判卷，逐题比对正确答案，统计得分，存入考试记录表和答题明细表，返回给前端本次考试的得分、及格状态和错题列表。这个接口是本项目里业务逻辑最重的一个，后面我会单独详细讲。

除了接口规范，还有一件事值得提前做：统一响应结构。我在项目里定义了一个Result类，包含code、message、data三个字段，所有接口都返回这个结构。这样做的好处是前端处理逻辑非常统一——先判断code是不是200，是的话就取data渲染页面，不是的话toast一下message。这个习惯虽然简单，但能让项目看起来非常专业。

3.3 目录结构：如何让你的代码"看起来"很规范

毕业设计有个隐性要求：老师会看你的代码结构。哪怕逻辑完全正确，如果所有类都堆在一个包里，观感分也会大打折扣。我建议的目录结构是这样的：

code复制com.example.drivingexam
├── controller        // 接口层：接收请求，返回结果
│   ├── ExamController
│   ├── QuestionController
│   └── UserController
├── service           // 业务层：核心逻辑在这里
│   ├── ExamService
│   ├── QuestionService
│   └── UserService
├── mapper            // 数据访问层：MyBatis-Plus的Mapper接口
│   ├── QuestionMapper
│   ├── ExamRecordMapper
│   └── WrongQuestionMapper
├── entity            // 实体类：对应数据库表
├── dto               // 数据传输对象：比如登录请求、交卷请求
├── vo                // 视图对象：比如答题返回给前端的结构化数据
├── config            // 配置类：比如拦截器、跨域配置、web mvc配置
├── common            // 通用类：Result类、异常处理、工具类
└── DrivingExamApplication.java

很多同学写代码时分不清entity、dto、vo的区别，全部用一个实体类打天下。在小项目里这确实也能跑，但老师如果稍微看得严一点，很容易被问住："你的实体类直接暴露给前端，万一有个字段不该给前端看怎么办？"所以我的建议是至少分出entity和vo两层：entity对应数据库字段，vo对应返回给前端的数据结构。像用户表里有密码字段，就不可能直接把entity返回给前端，你总得用一个userVo把它滤掉吧。

4. 小程序端核心实现：从登录到模拟考试全流程

小程序端是整个系统里学员直接接触的部分，也是答辩时演示的重点。它看起来功能不复杂，但每个模块都有值得细说的坑和技巧。

4.1 微信登录授权：一个让人头疼的接口变迁问题

微信小程序登录这块，这几年有过几次调整，网上教程鱼龙混杂，很多老教程还停留在wx.getUserInfo直接弹窗授权的年代。实际现在的规范是：wx.login获取code拿openid做登录，用户信息的获取要走button组件的open-type="getUserInfo"或者新版wx.getUserProfile（2022年后也做了调整），而且用户头像昵称的填写方式早就变成了"头像昵称填写能力"。

这里最坑的一点是，很多同学按照老教程做完，真机预览的时候发现用户头像昵称拿不到，在开发者工具里面是正常的，一到真机上就失败。我曾经排查这个问题排查了很久，最后确认是基础库版本和接口调整导致的兼容性问题。稳妥的做法是：不依赖微信返回的头像昵称作为核心登录信息，openid才是登录的唯一凭证。头像昵称可以做"优化体验"来用：允许用户在个人中心自行修改昵称和上传头像，这样即使微信侧获取失败，系统也能正常工作。

具体登录流程的代码逻辑核心就三步：

小程序端发起登录时：

javascript复制wx.login({
  success: async (res) => {
    const code = res.code
    const loginRes = await request.post('/api/user/login', { code })
    wx.setStorageSync('token', loginRes.data.token)
    wx.setStorageSync('userInfo', loginRes.data.userInfo)
  }
})

后端根据code换openid的部分，很多人会忽略异常处理。jscode2session这个接口偶尔会因为网络或code失效返回错误码，你的代码里一定要判断返回结果，不要默认它一定成功。否则一旦微信接口抖动，学员直接卡在登录页进不去，这种事故在演示现场非常尴尬。

4.2 刷题页面的设计：练习模式和模拟考试模式要分清

刷题页面是小程序端最核心的页面。我把练习模式和模拟考试模式做了完全不同的设计，因为它们的交互逻辑差异很大。

练习模式下，学员可以随时退出、查看答案、看解析、收藏或者标记错题。页面的基本结构是：顶部是题目进度（第12题/共100题），中间是题目内容和四个选项，底部是上一题/下一题和查看答案按钮。点击选项之后，要能立刻反馈对错——对的选择项变绿色，错误的选择项变红色，同时弹出一个半屏面板展示答案解释。

模拟考试模式下，交互逻辑完全不同。首先，顶部要显示倒计时，时间到了自动交卷。其次，学员答题过程中不能看到正确答案，也不能查看解析，必须交卷之后才能看到结果和错题回顾。第三，要有一个答题卡功能——一个小面板展示所有题号，已答的显示蓝色，未答的显示灰色，方便学员跳题和检查漏答。最后，交卷逻辑必须严谨：点击交卷按钮要弹二次确认，倒计时归零自动交卷不能遗漏未答题。

其实这两个模式在开发时并不需要写两套完全独立的页面，可以用同一个页面组件，通过一个mode参数来控制是否显示解析、是否计时、是否允许退出。这样代码量能省不少，逻辑也更集中。

4.3 错题本和前端的本地缓存技巧

错题本功能的实现，很多同学会走入一个误区：每次学员做错一道题，就立刻调后端接口写库。这样会导致接口请求非常频繁，而且在网络差的环境下体验特别差。更合理的做法是：先把本次答题记录保存在本地缓存里，等交卷或者退出练习时一次性提交。

我在小程序端用了wx.setStorageSync做本地缓存，把答题记录暂存在storage里。等学员完成一次练习或者模拟考试之后，再把本地缓存的答题记录同步到后端。这样做有两大好处：一是大幅减少接口调用次数，降低服务器压力；二是学员在答题过程中即使断网，本地缓存也能兜底，等网络恢复再同步，不会因为网络抖动丢数据。

另外，页面跳转时，题目进度和已选答案也应该存在本地，否则学员不小心退出页面再进来，之前的进度全丢了，这种体验会非常糟糕。在onUnload生命周期里做缓存，在onLoad或onShow时恢复缓存，就是我提到的老生常谈但极其实用的技巧。

4.4 页面样式和体验优化的几个细节

小程序端的界面虽然不需要设计得多惊艳，但基础体验要做到位。有几个细节很影响观感，但很多同学会忽略。

第一个是顶部导航栏的自定义问题。不同手机的顶部状态栏高度不同（尤其是有刘海屏和灵动岛的手机），如果使用默认导航栏，标题就是系统字体，样式比较一般。如果你希望做一个更美观的自定义导航栏，需要动态获取状态栏高度：wx.getWindowInfo()或者老接口wx.getSystemInfoSync()里有一个statusBarHeight字段，用来做顶部占位，否则页面内容会被状态栏或者胶囊按钮遮挡。这个坑几乎每次做小程序都会遇到，但网上很多教程压根不提。

第二个是底部安全区适配。iPhone的底部有横条，如果不做env(safe-area-inset-bottom)适配，底部的提交按钮或者tab栏就会顶到最下面，看起来很不专业。解决办法是给底部容器加上padding-bottom: env(safe-area-inset-bottom)。

第三个是加载态。小程序请求接口很快，但网络差的时候，如果没有loading提示，用户会以为卡死了。用wx.showLoading配合wx.hideLoading做接口请求的loading态，这不算什么复杂技术，但能让整个演示过程顺畅很多。

5. springboot后端关键模块：题库管理、判卷逻辑与后台页面

后端是整个系统的"大脑"。我把后端拆成几个核心模块来设计，每个模块的职责边界一定要清晰，否则写着写着就变成一个大杂烩。第一个是用户认证与登录模块，第二个是题库与刷题接口模块，第三个是模拟考试与判卷模块，第四个是后台管理模块。

5.1 登录认证与拦截器设计

登录认证这部分，虽然技术不复杂，但涉及"安全"这个敏感话题，也是老师喜欢追问的点。最朴素的方案是：登录成功后生成一个随机token，存到Redis或者数据库里，后续请求带上token，后端校验。考虑到毕业设计的复杂度，直接用Redis存储token时效是个加分项，但如果你没装Redis或者不想引入额外依赖，用一个内存Map存token也能演示（只要你清楚瓶颈在哪）。

更标准的做法是引入JWT，登录成功后签发一个带过期时间的token，后端再配一个拦截器统一校验。JWT的好处是无状态，不需要在服务端保存session信息，更适合前后端分离的场景。不过要跟老师解释清楚JWT的优缺点：它是无状态的，所以没法主动吊销（除非加黑名单），对毕业设计来说够用了。

拦截器的实现逻辑很固定：在HandlerInterceptor里取header的token字段，解析校验，失败就返回401，放行则把userId放入request attribute供后续使用。注册到WebMvcConfigurer里，并且要配置excludePathPatterns——登录接口和获取题目列表这类基础接口可能要放行，但提交考试、查看个人中心这类接口需要登录。

这里有一个细节坑值得说：小程序的request请求默认不会带cookie，所以你的token校验一定是从header里取，而不是依赖于session。有些同学做后端时习惯用session管理登录状态，但在小程序场景下完全行不通，这个点千万要注意。

5.2 题库管理的两种方式：手动录入与批量导入

题库数据怎么进来？这是项目从"demo"走向"看起来完整"的关键。

第一种方式是手动录入。管理员在后台页面里一条条添加题目。实现起来不难，就是基础的CRUD，用MyBatis-Plus的save和updateById就够了。但纯手动录入的效率太低了，一套像样的题库至少几百道题，用手点的话得点一天。

第二种方式是批量导入，我强烈建议做。最常用的方案是Excel模板导入：管理员下载模板，按格式填好题目，然后上传，后端用EasyExcel或者POI解析Excel，批量插入数据库。用EasyExcel比原生的POI简单得多，内存占用也小。这里注意几个问题：Excel文件里的科目字段、正确答案字段要校验，不能写什么都能入库；解析成功后要返回"成功导入XXX条，失败N条，失败原因见列表"，而不是简单的成功或失败；题目的重复性校验也值得做，比如按题目内容查重，防止同一个题被导两次。

批量导入这个功能在毕业设计答辩时非常亮眼。你演示的时候，切到后台管理，下载一个模板，填几道题，上传，然后切到小程序端刷新题库，新题立刻就出现了。这个"数据流转闭环"的演示效果远远好于你在后台手动添加一道题。

5.3 判卷逻辑：模拟考试的核心，怎么设计才合理

判卷是考试系统最核心的业务逻辑，写得好不好直接决定了这个项目有没有灵魂。我在设计交卷接口时用了下面这个思路：

java复制public SubmitExamVO submitExam(SubmitExamDTO dto) {
    // 1. 查询本次考试的所有题目
    List<Question> questions = questionMapper.selectBatchIds(dto.getQuestionIds());
    
    // 2. 遍历答题列表，逐题判定
    int correctCount = 0;
    List<AnswerDetailVO> wrongList = new ArrayList<>();
    for (AnswerDTO answer : dto.getAnswers()) {
        // 找到对应题目
        Question q = questions.stream()
            .filter(item -> item.getId().equals(answer.getQuestionId()))
            .findFirst().orElse(null);
        if (q == null) continue;
        
        boolean isCorrect = q.getCorrectAnswer().equals(answer.getAnswer());
        if (isCorrect) {
            correctCount++;
        } else {
            wrongList.add(new AnswerDetailVO(q, answer.getAnswer()));
        }
        // 3. 保存答题明细
        saveExamDetail(dto.getUserId(), dto.getExamId(), q, answer.getAnswer(), isCorrect);
        // 4. 同步错题本
        saveWrongQuestion(dto.getUserId(), q, isCorrect);
    }
    
    // 5. 计算分数，判断是否及格，生成考试记录
    // 科目一：每题1分，共100题；科目四：每题2分，共50题
}

这中间有几个容易出问题的点。

一是"交卷时题目快照"的问题。学员考试过程中，管理员如果删掉了一道题或者改了一个题的正确答案，学员的成绩怎么算？最严谨的做法是：开始考试时，后端生成一张试卷快照，把所有题目ID和当时的正确答案存下来，交卷时按快照判卷。但这样设计复杂度会上升不少。对毕业设计来说，采用"交卷时实时查题目表"也可以接受，但你心里要明白这个设计是有瑕疵的，答辩时被问到可以诚实说明，并且给出改进方案，反而显得你有思考深度。

二是"满分和及格线"的规则不能硬编码在判卷逻辑里。更好的做法是给科目表或者配置表里加一个exam_rule字段，存总分、及格分、考试时长等配置。这样以后如果想加一个科目三理论模拟，只需要在后台配一条规则，而不需要改代码。这个"配置驱动"的思路，在答辩时说出来是很大的加分项。

三是"并发重复提交"的问题。学员快速双击交卷按钮，可能导致同一份答卷被提交两次。解决方式有两个：前端控制按钮的loading状态，点击后置灰不可再点；后端利用一个唯一索引或者加一个is_submitted字段判断，如果已有提交记录则直接返回上次结果。两个方案建议都做，前端控制体验，后端兜底防错。

5.4 后台管理页面：用springboot直接渲染，少走弯路

后台管理这块，我之前提到过有两种方案：vue单独做管理端，或者springboot+Thymeleaf直接渲染。很多同学纠结到底选哪个，我跟你说下我的判断逻辑。

如果用vue做管理端，你将额外维护一套前端工程，涉及node环境、npm依赖、构建打包、跨域配置、登录token管理等一系列问题。一台电脑上环境稍微有点问题，可能几个小时就耗进去了，而收益只是"后台看起来更现代一点"。而用springboot+Thymeleaf，ModelAndView直接返回页面，后端渲染，不需要处理跨域，不用另起前端项目，所有代码在一个工程里，对演示和打包都友好得多。

当然用Thymeleaf也不是完全没坑。第一个坑是静态资源的路径问题，你需要在application.yml里配置好spring.mvc.static-path-pattern，不然css和js加载不出来。第二个坑是Thymeleaf的语法和Vue差别很大，循环用th:each，条件用th:if，可能一开始不太习惯，但这东西学起来半小时就够。

后台页面的功能优先级排序应该是：题库管理 > 学员管理 > 考试统计 > 公告管理。题库管理是最重要的，因为它是整个系统的数据源头。学员管理需要做一个表格展示所有注册用户，带搜索和分页。考试统计页面，可以用ECharts画一个简单的"近七日模考人数"折线图或者"科目通过率"柱状图，这会让你的毕业设计瞬间上了一个档次——毕竟有图表展示，看起来才是"系统"，而不是"一堆增删改查页面"。

6. 远程调试，实用部署与演示全流程：避开那些让你当场翻车的坑

很多同学做毕业设计，本地运行一切正常，一到要演示或者要部署给老师看，就各种翻车。尤其是这个题目带"远程调试"的卖点，说明它是要能够脱离本机运行的。这一节我把从本地联调到远程部署、再到正式演示的完整链路讲一遍。

6.1 本地前后端联调：小程序的域名校验难题

微信小程序默认要求所有请求的域名必须是HTTPS且备案过的。但在开发阶段，我们显然不需要真实部署，这时候要打开开发者工具里的"不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书"选项。

这个小细节看起来人尽皆知，但每年都会有人卡在这里。而且要注意，开发者工具里关掉了校验不是一劳永逸的——真机预览时，手机上运行的小程序同样会进行域名校验。如果你用的是真机调试，需要在"详情-本地设置"里勾选"不校验合法域名"；如果用的是预览模式，那就需要把后端接口地址改为局域网IP，并且手机和电脑连同一个WiFi。

这里有个联调时最常见的坑：电脑防火墙拦截了手机访问。你的springboot启动在8080端口，电脑本地访问正常，手机通过http://192.168.x.x:8080访问不通，大概率是Windows防火墙拦了。解决方式是去防火墙的高级设置里，添加入站规则放行8080端口，或者用一个"临时关闭防火墙"的办法（注意演示完记得恢复，安全第一）。

6.2 部署到Linux服务器：jar包运行与nginx反向代理

真正要远程调试或者演示，建议把后端部署到一台云服务器上，小程序端通过线上接口访问。这样无论你在哪里，掏出手机打开小程序就能看到效果，也不用纠结局域网和防火墙的问题。

springboot的打部署包非常简单：在项目根目录执行mvn clean package，会把项目打成一个可执行的fat jar。然后扔到服务器上，执行nohup java -jar driving-exam.jar > app.log 2>&1 &，后端就跑起来了。这里容易踩的坑是jdk版本不一致——本地用jdk17编译，服务器上如果是jdk8，直接跑不起来，报UnsupportedClassVersionError。打包时最好指定<java.version>和Maven编译参数，或者干脆在服务器上也装一个与本地一致的JDK版本。

关于小程序端，这里有一个非常大的认知误区需要澄清：微信小程序本身不需要部署到服务器。你写的WXML/JS代码是在微信的容器里运行的，你只需要在微信公众平台"小程序后台"里提交代码审核发布，或者直接把代码上传为开发版/体验版就行。真正需要部署的是：后端接口、图片等静态资源（如果小程序里有图片资源）、以及后台管理系统（如果用的是thymeleaf渲染的页面则和后端一起部署）。

如果你想把接口域名做成HTTPS，需要准备SSL证书并配置到Nginx里。Nginx的配置大概是这样：

nginx复制server {
    listen 443 ssl;
    server_name yourdomain.com;
    ssl_certificate /etc/nginx/cert/yourdomain.pem;
    ssl_certificate_key /etc/nginx/cert/yourdomain.key;
    
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这里我要提醒一句：如果你只是自己演示，不打算真的发布小程序给公众使用，申请HTTPS域名+备案的流程很耗时（尤其是备案，通常需要一两周）。一个可接受的替代方案是：开发环境和演示阶段用局域网IP联调；体验版二维码只能在"小程序后台-成员管理"里添加体验成员后扫码打开，且体验版同样会有域名校验问题，也需要关闭校验或者配置合法域名。所以在规划时间时，别把"部署上线"想得太轻松，预留两周比较稳。

6.3 答辩演示的流程编排：先演示什么，再演示什么

答辩演示是整个毕业设计的临门一脚。我见过太多项目做得不错、但演示过程混乱导致扣分的例子。演示不是把功能从头到尾点一遍就完了，你要有一个"剧本"。

我的建议是：开场先用30秒介绍项目背景和功能边界，然后进入小程序端演示——先登录（展示微信授权过程），再刷几道题，刻意做错一道，让观众看到对错反馈和解析，接着进入模拟考试，快速答题交卷，展示得分、成绩单和错题回顾。这个流程把学员端的核心体验完整地串起来。

然后切换到后台管理，先展示题库列表的翻页和条件查询，再演示一道新增题目的完整流程——新增完成后切回小程序，刷新题库，让这道新题在前面出现。这个"后台录入、前台展示"的闭环是全场演示的高光时刻，强力建议一定要演示到位。如果有时间，再演示一下批量导入Excel和考试统计图表。

整个演示流程控制在10到15分钟最合适。太长老师会不耐烦，太短显得项目没深度。你可以在关键节点主动讲解设计思路，比如判卷时可以说"我采用的是实时判卷方案，答辩时的局限性是如果题目中途被修改会导致成绩波动，正式生产环境下应该用试卷快照机制"，这种话术既展示了你有思考，又提前堵住了老师可能追问的问题。

6.4 远程调试过程中常见的翻车场景与定位方法

远程调试不是指你在自己电脑上debug，而是说功能部署之后，别人（比如老师）通过手机访问时出了问题，你怎么排查。这里有一套完整的排查链路，我建议你记一下。

第一步是看后端日志。用tail -f app.log实时查看运行日志，很多问题的线索都藏在日志里——数据库连接失败会有Connection refused，接口异常会有异常堆栈，请求没进来会有404或405提示。日志是定位问题的第一入口。

第二步是看小程序端的报错。打开开发者工具的Console面板和Network面板，如果请求报错，Network请求列表里能看到具体的请求URL、状态码和响应体。如果是404，检查一下后端路径是否跟小程序请求路径完全一致——注意springboot里@RequestMapping的路径不能有前后斜杠不一致的问题；如果是500，大概率是后端代码抛异常了，去日志里捞堆栈。

第三步是检查网络连通性。在服务器上执行curl http://localhost:8080/api/question/list看本地通不通，再从外部执行curl http://server_ip:8080/api/question/list。本地通外部不通，多半是防火墙或云安全组没放行端口；两边都不通，后端可能没起来，先看进程在不在。

这里要特别提一下"springboot版本太高"这个热词背后说的问题。很多同学创建项目时直接选择springboot最新版，但最新版对JDK版本、某些依赖的兼容性要求很高。比如springboot 3.x要求JDK17起步，很多学校机房的机器或者服务器上装的是JDK8，编译都编不过。还有springboot 2.7到3.0之间有不少配置项变了（比如javax.servlet改成了jakarta.servlet），如果你按网上老教程写代码，版本对不上就会出一堆莫名其妙的错。我的建议是：springboot版本选择2.7.x，JDK选择1.8或者11，这是目前兼容性和教程丰富度综合最好的组合。如果你的老师强调要用新版本，那务必确认整个工具链（JDK、Maven、依赖）都能对齐，别开局就给自己挖坑。

7. 文档、源码与答辩准备：毕业设计拿高分的最后一块拼图

项目代码做完了，文档写不好，照样拿不到高分。这部分我聊聊怎么把"代码做完"升级为"项目交付完整"。

7.1 毕业论文/设计说明书的写作思路

毕业论文的类型是工程设计类，它的核心逻辑不是"复述代码"，而是"论证你的设计合理性"。一份合格的毕业设计文档通常包含这些部分：绪论（背景与意义、国内外研究现状）、需求分析（功能需求、非功能需求）、系统设计（总体架构、功能模块设计、数据库设计）、系统实现（每个模块的流程图、核心代码、界面截图）、系统测试（测试用例、测试结果）、总结与展望。

这里有个常见误区：很多同学把"系统实现"写成了代码粘贴集，一大段一大段的代码贴上去，没有任何说明。好的写法是：每部分先用文字描述实现思路，然后贴一段关键代码（十到二十行为宜，不要整屏贴），接着解释这段代码解决了什么问题、为什么这么写。你要记住，老师读文档是想了解你的设计思路，不是想帮你调试代码。

验收材料清单方面，除了论文，通常还需要：开题报告、中期检查表、任务书、答辩PPT、演示视频（有的学校要求）。PPT要控制在一页一个核心问题，演示视频建议提前录好，3-5分钟，包括登录、刷题、模考、后台管理全流程。真到了答辩现场设备出问题，视频就是你最后的保底方案。

7.2 答辩时老师最常追问的问题与应对思路

根据我的经验，答辩老师问的问题基本集中在这几个方向。

第一个方向是"为什么"。为什么选springboot？为什么用小程序不用App？为什么题库导入用Excel不用手动录入？这些问题没有对错，关键是你要能说出选型的理由。比如"用springboot是因为它简化了配置、内置服务器、生态成熟，适合快速开发前后端分离项目"——这就比"因为大家都在用"好得多。

第二个方向是"怎么实现"。模拟考试的判卷逻辑是什么？登录的token机制怎么做的？错题本数据是怎么维护的？这些问题要求你对自己代码的逻辑非常熟悉。应对策略是你一定要亲手把你核心模块的代码逐行看懂，不要写完就忘。

第三个方向是"如果让你改进，你会怎么做"。这是最考验水平的开放式问题。常见回答思路有：引入Redis缓存热点题目数据、用消息队列异步处理交卷后的统计逻辑、增加试卷快照机制保证考试一致性、加入用户行为分析系统等等。这里有一个原则：不要说超出你项目范围太远的改进，说两三条务实的、可落地的改进就行。

7.3 源码交付与"全bao定制"绕不开的问题：代码规范与注释

毕业论文项目最后都要提交源码，这个源码的"可读性"直接影响查重和评阅体验。有些同学代码里的变量名是a、b、c、temp、data，注释一个都没有，这种源码交上去，老师对你的印象分直接打对折。

代码规范不需要你做到什么大厂标准，但至少要做到几点：包名使用全小写，类名使用驼峰命名；方法名要能看出来是干什么的，比如submitExam、getQuestionList、saveWrongQuestion；核心业务逻辑（比如判卷、登录）要有注释，但注释不是废话复述，而是说明"这一步为什么要这么做"。

我见过一种很适合毕业设计的代码注释风格：类头部写清楚这个类的作用，复杂方法的头部写清楚入参、出参、关键逻辑，方法内部的关键代码块隔几行加一句注释。这样就算代码量不大，整个项目看起来也像模像样。

这里顺便提一句"全bao定制"的问题。现在网上很多毕业设计相关服务会宣传全包定制、远程调试之类的服务，但我的态度是：项目可以借鉴参考，但代码最终要变成你自己的。因为答辩现场老师提问的时候，他问的往往是特别具体的实现细节，如果你只是拿了一套别人的代码而没有真正理解，随便一问就露馅了。把这套代码从头到尾自己敲一遍、调一遍、改一遍，比你想象中要花的时间少，而收获却大得多。

8. 我的实操总结：这些坑我踩过，希望你别再踩

最后聊几个我在做这类项目时亲身踩过的坑，也许不是普遍问题，但遇到了真的很耽误时间。

第一个坑：数据库表设计时没有预留统一的前缀。我在建表时表名用了user、question这种单词，结果发现user在MySQL里是保留字，虽然加上反引号能跑，但每次写SQL都特别别扭。建议所有表都加一个统一前缀，比如exam_user、exam_question、exam_record，既避免保留字冲突，也方便一眼看出这个表属于哪个业务域。

第二个坑：MyBatis-Plus的字段自动填充没有配置。我的表里有create_time和update_time两个自动填充字段，一开始没有配置MetaObjectHandler，导致每次新增数据都要手动set时间，漏一次就得去数据库改。后来统一加了自动填充处理器，再也不用管了。如果你用MyBatis-Plus，这个配置建议顺手做上。

第三个坑：小程序端请求封装没有做统一的错误处理。我的第一个版本里，每个页面单独调wx.request，请求失败就在页面里自己写toast，结果代码重复得非常严重。后来统一封装了一个request.js，把所有请求集中管理，统一处理token注入、401跳转登录、错误提示。代码瞬间清爽了很多。我强烈建议你在一开始就把这个工具封装好，不要等项目写了一半再重构。

第四个坑：千万别在答辩前一天临时换JDK或升级springboot版本。我见过有同学因为本地jdk版本与服务器不一致，折腾了一整天，最后发现是maven编译的target版本问题。版本这种东西，一旦项目跑通了就"别手贱"去动它，一切以稳定为主。

回到这个项目本身，我始终认为驾校考试模拟系统是一个非常有价值的毕业设计选题。它看起来平平无奇，但你把它拆开来看——用户认证、权限拦截、题库管理、自动判卷、数据分析、前后端联调、部署发布——几乎涵盖了一个完整Web项目的所有关键环节。你能把这个项目从头到尾搞透彻，说明你已经具备了一个初级后端开发或者全栈开发的基本素养，这在找实习和秋招的时候，比简历上写一堆"精通XX框架"管用得多。