1. 课堂测试场景拆解这个项目实际上在做什么连续看了好几个基于SSM的微信小程序课设题目其中课堂测试小程序算是出现频率相当高的一个方向。乍一听觉得功能简单不过是把纸质试卷搬到线上但真正开始设计的时候你会发现它牵扯到的角色关系、状态流转和异常情况远比想象中多。先把这个项目对应的现实场景讲清楚。传统的随堂测试大概是这么个流程老师带一沓试卷进教室发卷、计时、收卷、批改、登记成绩。如果是选择题和判断题还得靠答题卡或者手工比对批改工作量集中在考试结束之后。到了成绩汇总阶段Excel录入和分数统计又是另一轮体力活。这个小程序要替代的就是这条完整链路而不是只做其中一环。我拆解出来的核心角色有三个。学生端登录后能看到老师发布的试卷列表点进去答题提交后马上能看到客观题得分。对错题最好还能看到解析。教师端维护题库、组卷、发布测试、查看班级提交情况和成绩分布。后端管理侧通过SSM框架支撑两端的业务逻辑包括登录鉴权、试卷存取、答案比对、成绩记录。所以这个题目听起来只有一个小程序实际上是一整套前后端分离的系统。微信小程序只是C端载体真正的业务逻辑和数据存储全部落在SSM后端。这也是很多同学容易理解偏的地方以为写完小程序页面就完事了其实小程序页面只是整个项目的一层皮。从业务流程上看最核心的闭环是教师创建试卷并发布学生看到试卷并作答后端完成判分并把结果返回给学生端同时把成绩落到数据库供教师查询。整条链路里我在实际项目中更关注的是发布这个动作前后的状态切换。一份试卷在没有发布之前学生端不应该看到一旦发布就要处理进入答题状态之后的重复提交、刷新、断网重连等问题。这样的系统放到毕业设计或者课程设计里价值在于它完整覆盖了SSM框架的常规使用方式Spring管理业务对象、SpringMVC处理请求路由、MyBatis操作数据库加上微信小程序端的完整生命周期管理。对于需要展示我会做全栈的同学来说这个题目的呈现效果非常直观。2. SSM后端的设计取舍从三层架构到数据表2.1 为什么在这个项目里仍然选SSM而不是Spring Boot现在打开招聘网站几乎看不到SSM了实际生产环境也基本被Spring Boot接管。但放在课堂测试小程序这个选题上SSM有它不可替代的理由。第一是教学惯性。很多高校的Java Web课程仍然以SSM为核心教学内容最后的大作业和毕设也默认要求用SSM。第二是材料积累。SSM框架相关的教程、报错案例、源码解析已经沉淀了很多年遇到问题几乎都能搜到现成的解决方案对经验不足的同学非常友好。第三也是最实际的一点SSM的配置过程本身就是一门课。Spring和MyBatis需要手动整合要写配置文件、配置数据源、管理事务这些步骤让你必须理解框架之间的协作关系而不是像Spring Boot那样把复杂性藏进自动配置里。所以在文章开头我可以给你一个结论如果你是为了实战项目去的直接学Spring Boot但如果你是为了课堂测试小程序这种课设或毕设题目SSM是更稳妥、答辩时也更有东西可讲的选择。2.2 SSM三层与小程序请求的对应关系用一张对应关系来理解整个后端结构会更清晰小程序前端SSM后端职责wx.request请求Controller层接收HTTP请求校验参数返回JSON业务逻辑调用Service层处理业务规则比如判分、查重、状态校验数据存储Mapper层MyBatis与MySQL交互执行SQLapp.js全局数据Spring容器管理对象生命周期、依赖注入实际编码的时候一个典型的请求链路是这样走的小程序端调用wx.request发起POST请求到/student/loginSpringMVC的DispatcherServlet把请求交给对应的Controller方法Controller调用StudentService的login方法Service里通过StudentMapper查询数据库验证用户身份再把结果封装成统一的JSON结构返回给小程序端。这里有一个细节新手容易忽略Controller层不应该写业务逻辑。我知道很多同学为了赶进度直接把SQL写在Controller里前期用着没什么问题一旦后面要加试卷已发布则拒绝提交这种规则代码会变得非常难维护。哪怕只是课设也建议严格遵守Controller - Service - Mapper的分层规范答辩时这一条就可以讲很久。2.3 核心表结构设计课堂测试小程序的核心表我按实际项目经验来归纳大概是这么几张。用户表t_user学生和教师统一存一张表用role字段区分身份。之所以不拆成两张表是因为登录逻辑完全相同只是后续权限不一样。role用Integer类型0代表学生1代表教师。试卷表t_paper包括id、paper_name、create_teacher_id、status0草稿、1已发布、2已结束、duration考试时长单位分钟、start_time、end_time。status这个字段是整个系统的状态核心所有查询列表的SQL都要依赖它做过滤。题目表t_question存储题目内容、选项、正确答案、解析、题型。题型我用0和1区分单选和判断题因为本系统暂不支持多选这样判分逻辑最简单。如果你后续想扩展多选把type改成0单选题、1多选题、2判断题即可。试卷题目关联表t_paper_question多对多关系的中间表字段为id、paper_id、question_id、score。之所以要有这张表是因为一份试卷包含多道题一道题也可能被多份试卷引用而且同一道题在不同的试卷里分值可能不同。答题记录表t_answer_record记录学生每道题的作答情况包括record_id、student_id、paper_id、question_id、student_answer存选项编号比如A或对。这张表是判分和成绩统计的数据来源。成绩表t_score一个学生考完一份试卷生成一条成绩记录字段包括id、student_id、paper_id、score、submit_time。这里的score是综合试卷里所有题目的得分算出来的。这六张表基本上就能支撑起课堂测试的核心功能。在设计的时候我建议大家特别注意一个地方题目内容和试卷的关联必须通过中间表不能直接把题目字段塞进试卷表。否则后续要复用题库里的题目来组新试卷会非常痛苦。实际课程里老师出题时通常会从题库选题组卷中间表就是为这个场景设计的。3. 小程序端核心功能的实现顺序与状态管理3.1 微信登录到业务登录的完整链路微信小程序的登录和传统Web登录不太一样。Web端是输入用户名密码小程序端则依赖微信的授权机制。整个登录链路是这样跑的小程序端调用wx.login获取一个临时凭证code。把code通过wx.request发送到自己的后端接口比如/user/login。后端拿到code后调用微信的code2Session接口换取openid和session_key。后端用openid去t_user表查用户如果查到就直接登录成功如果查不到说明这是一个新用户可以在表里插入一条新记录完成自动注册。后端生成一个自定义的token可以用UUID存到Redis或者直接存到内存里然后把token返回给小程序端。小程序端把token存到本地storage后续所有请求都在header里带上这个token后端通过token识别用户身份。这里有一个特别重要的安全点绝对不能把微信小程序的AppSecret放到前端代码里。AppSecret是用来在后端换取openid的凭证一旦泄露到小程序包里任何人都可以假冒你的后端去调用微信接口。正确做法是把AppSecret配置在后端的application.properties里由后端去请求微信服务器。另外一个实际开发中容易被忽略的细节是wx.login获取的code有效期只有5分钟而且只能使用一次。所以前端不能在发起业务请求时才临时去调用wx.login应该在用户进入小程序时先完成登录把token存好。后续token过期了再重新走一遍登录流程。我在实际项目中习惯在小程序app.js的onLaunch里先调用一次wx.checkSession检查微信的session_key是否过期如果过期就重新登录这样可以避免用户使用过程中突然被登出。3.2 答题页的状态设计与提交策略答题页是小程序端最核心的页面它涉及到的状态管理比看起来复杂得多。一份试卷拿到手后学生要按顺序答题看到题目进度、剩余时间还可能需要在题目之间切换检查。我的建议是试卷详情接口一次性返回整份试卷的所有题目存放在小程序的data里答题过程中通过currentIndex控制当前显示第几题。学生的答案用一个对象保存key是questionIdvalue是选中的选项。这样在页面里做上下题切换时不需要重新请求后端体验非常流畅。关于答案保存时机有两种方案一种是每做一题就调一次后端接口保存另一种是全部答完统一提交。课堂测试的场景我建议用统一提交。原因很简单每道题都请求一次接口对后端的压力大而且容易出现网络波动导致某次保存失败学生根本不知道哪道题没存上。统一提交虽然看起来技术含量不高但在这个场景下最可靠。提交时要做的处理很关键用wx.showModal弹窗和用户二次确认防止误触。点击确认后把答案对象和paperId一起POST到后端判分接口前端拿到返回的得分后跳转到结果页。这里还要处理一个情况用户重复提交。后端要做好校验如果该学生已经提交过这份试卷直接返回已提交请勿重复作答不要再执行判分和写入成绩。倒计时功能也要在答题页里体现。建议用setInterval每分钟减一或者每秒减一按需求来。需要注意的是在页面onUnload时必须清除定时器否则页面销毁后定时器还在跑会出现内存泄漏。实际踩过的坑是用户切到后台比如来了个电话定时器依然在走等用户回来时发现考试时间已经被耗完了。这个问题在真实使用场景中非常常见但课堂测试通常时间较短影响不算太大。如果你想做得更严谨可以在onHide时记录时间戳onShow时对比时间差并重新计算剩余时间。3.3 教师端题目管理与试卷发布教师端的核心功能是题库维护和试卷发布。题库维护可以拆成两个页面一个是题目列表页展示所有题目支持按题型筛选另一个是题目编辑页支持新增和修改。我的建议是新增和编辑共用一个页面通过URL参数区分。比如/pages/question/edit?id123表示编辑没有id参数就表示新增。这样代码复用率高后期维护也方便。试卷发布流程的设计要注意状态流转。我把试卷设计成四种状态草稿、已发布、进行中、已结束。创建试卷后默认是草稿状态只有教师确认题目都配好了才能点击发布。发布时弹窗选择开始时间和结束时间或者直接设为立即开始、时长多少分钟后端更新status字段。列表页的查询条件也要跟着状态走。学生端只能看到已发布且当前时间在起止时间范围内的试卷教师端可以看到自己创建的所有试卷但草稿和已发布的要区分显示。在教师端的UI实现上小程序自带的picker组件就够用了。试卷时长的选择、题目分值的设置都可以用picker实现不需要引入额外的UI库。如果你想让界面更好看一些可以考虑用Vant Weapp或者ColorUI但以课设的标准来看原生组件完全够用。4. 联调与部署阶段最常翻车的几个环节4.1 request合法域名与HTTPS校验课堂测试小程序做好之后最痛苦的阶段不是写代码而是把代码跑在真机上。很多时候开发者工具里一切正常一用手机预览就请求失败。主要原因集中在微信小程序的网络限制上。微信小程序要求所有wx.request的域名必须是HTTPS并且要在小程序管理后台配置到request合法域名里。如果你没有注册小程序账号、只是用测试号开发那这个限制会一直在。开发阶段有两个选择在小程序开发者工具的详情 - 本地设置里勾选不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书这样开发者工具里可以访问任何HTTP接口。真机调试时需要在手机预览的右上角菜单里打开开发调试开关才能绕过HTTPS校验。但要注意这个绕过只是开发阶段的临时方案。一旦你要提交代码审核、上线正式版本就必须配置合法的HTTPS域名否则线上版本无法正常请求接口。在你的后端部署到云服务器上之后正确做法是去云服务商申请一个免费的SSL证书比如腾讯云和阿里云都有免费版DV证书然后在Nginx里配置HTTPS反向代理。Nginx的核心配置大概长这样server { listen 443 ssl; server_name yourdomain.com; ssl_certificate /etc/nginx/ssl/yourdomain.pem; ssl_certificate_key /etc/nginx/ssl/yourdomain.key; location / { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这段配置的意思是用户的HTTPS请求先打到Nginx的443端口Nginx解密后转发到本地8080端口也就是你的SSM后端服务。这样小程序端访问的是https://yourdomain.com/user/login后端实际收到的是http://localhost:8080/user/login。很多同学会问为什么不能直接用Tomcat的8080端口配上HTTPS非要加一层Nginx因为Tomcat配HTTPS需要对server.xml做较多改动而且管理证书不如Nginx方便。多加一层Nginx证书续期、多站点配置、负载均衡都更容易处理。4.2 开发模式下用局域网IP调试的注意事项如果你不想走云服务器那套流程只是想先用手机连上电脑的后端做真机调试可以用局域网IP。但这里有个非常常见的坑后端服务监听的地址不对。Spring Boot或者SSM里的SpringMVC默认的监听地址是localhost也就是127.0.0.1。这意味着它只能接受本机的请求手机通过局域网IP访问是连不上的。你需要让Tomcat监听0.0.0.0才能接受来自局域网其他设备的请求。修改Tomcat的server.xml找到Connector配置Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 /这段配置默认监听所有网卡所以理论上不用改。但前提是你的服务器代码没有额外绑定地址。如果你自己写了一个main方法启动Spring容器就要确保启动时没有指定server.address127.0.0.1。然后查一下电脑的局域网IP。Windows系统在命令行输入ipconfigMac系统在终端输入ifconfig找到类似192.168.x.x的地址。手机和电脑连接同一个WiFi然后在小程序端把请求地址改成http://192.168.x.x:8080。这里要提醒一点如果是Windows系统还要检查防火墙是否放行了8080端口。很多时候后端日志显示请求进来了但手机端一直超时就是防火墙拦截导致的。临时测试可以直接关闭防火墙生产环境则应该在防火墙上放行指定端口。4.3 云服务器部署与数据库初始化如果你用的是云服务器流程大概是这样的在云服务器上安装JDK 1.8、Tomcat 8.5、MySQL 5.7。用Navicat或者命令行把你的数据库导出、导入或者直接在服务器上运行初始化SQL脚本。把SSM后端项目打成WAR包放到Tomcat的webapps目录。启动Tomcat通过curl http://localhost:8080/你的项目名/user/login验证接口是否正常。配置Nginx反向代理和HTTPS证书。在小程序管理后台配置request合法域名。部署过程中最容易被卡住的是数据库的字符集问题。SSM项目里的数据库连接URL最好显式指定编码jdbc:mysql://localhost:3306/class_test?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai如果不指定characterEncoding插入的中文可能会变成问号。在课堂测试这个场景里题目内容、学生姓名都是中文字符集问题一定会暴露。另外serverTimezone也需要设置尤其是MySQL 8.x版本不设置时区参数会直接报错。数据库表结构不用等后端代码写完再建。建议先用SQL脚本建好表再用MyBatis的逆向工程生成Mapper代码这样可以省下大量手写SQL的时间。5. 一个排查实例登录接口在开发者工具能用、真机超时5.1 问题复现这个问题的出现频率在我接触的项目里几乎达到80%以上。现象是小程序开发者工具里所有接口都正常登录、拿试卷列表、提交答案都没问题。但一换成真机预览登录接口就转圈转很久最后报request:fail timeout或者网络异常。为什么会这样因为开发者工具里的网络请求没有走手机的WiFi链路它是通过你电脑的本地网络直接请求后端的。开发者工具访问localhost和手机访问你的电脑或者服务器根本是两条不同的网络路径。5.2 排查链路第一步先看报错类型。如果报的是request:fail说明请求根本没有到达后端问题在网络链路或者域名配置。如果报的是后端返回错误码比如401或者500说明请求到达了后端但业务处理出错了。第二步看小程序端的请求地址。在开发者工具里用的http://localhost:8080在真机上是不可用的因为localhost指向的是手机自己。真机调试必须把地址改成电脑的局域网IP或者HTTPS域名。第三步打开后端日志。如果使用的是SSM项目查看Tomcat的catalina.out日志。如果发现压根没有收到请求那基本可以锁定是网络层的问题。如果收到了请求但响应超时那可能是数据库查询慢或者业务逻辑死循环需要进一步排查。第四步检查服务器的防火墙和安全组。云服务器上除了系统防火墙还要检查云控制台里的安全组规则是否放行了8080端口。安全组的优先级高于系统防火墙是一个经常被忽略的坑。5.3 根因修复与验证我遇到的大多数情况根因出在开发者工具勾选了不校验合法域名但真机没有开启开发调试。开发调试的开关在真机预览时右上角的菜单里需要点开开发调试选项否则真机上所有HTTP请求都会被微信拦截。如果你是正式环境则要确认小程序管理后台的request合法域名已经正确配置且域名已经备案。没有备案的域名无法加进白名单这也是一个卡点。修复验证的步骤如下修改小程序端的接口基础地址统一放到一个config.js文件里方便切换。将基础地址设置为你实际使用的访问地址。预览模式下在手机端打开调试开关确认请求正常。正式环境上传代码前用微信开发者工具的真机调试功能再验证一遍这个模式下走的是真实网络链路能暴露绝大多数环境问题。这里顺便分享一个排查小技巧在手机上预览时如果网络请求失败打开微信的vConsole调试面板可以看到具体的失败原因。是DNS解析失败、TLS握手失败还是超时vConsole里会给出明确提示。不要只盯着页面上那个网络异常的弹窗往下翻一翻真正的错误信息排查效率会高很多。5.4 类似的明明代码没问题但真机就是不行的场景iOS和安卓行为不一致。比如音频播放iOS静音模式下默认不播放媒体声音这个问题在课堂测试里如果要做答题结束提示音就会遇到。真机上的滚动失效。某些旧版iOS微信小程序里overflow: scroll不生效需要用scroll-view组件或者给页面设置正确的高度。顶部导航栏的高度在不同机型上不一致。比如iPhone X系列的刘海屏会让导航栏变高如果自定义导航栏组件要调用wx.getMenuButtonBoundingClientRect动态计算。这些问题单个看都不复杂但如果没有真机调试的习惯会浪费很多时间。我的原则是功能写完之后先跑一遍开发者工具再立刻用真机预览跑一遍主流程越早暴露环境差异越早发现问题。写在最后的几个操作性建议从我经手的多个类似项目来看课堂测试小程序的开发周期大概在3到4周左右。前端部分需要1周后端部分需要1周半联调和部署再占一周剩下的时间用来写文档、做PPT、准备答辩。如果你是零基础起步我建议先不要急着写代码花两天时间把流程想清楚。把整条链路画一遍学生打开小程序之后每一步会看到什么界面、点击什么按钮、请求什么接口、后端做什么处理、返回什么数据。链路想清楚了写代码就是体力活。代码实现上有几个地方要提前注意一个是小程序端的请求封装建议用Promise包一层统一处理loading态和错误提示不要每个页面都写一遍wx.request的完整回调另一个是后端接口的返回结构建议统一用{code: 200, msg: success, data: {...}}这样的格式前端解析起来非常方便。数据库设计是后续开发的地基认真设计好六张表之间的关系之后再动手写Mapper后期能省很多改表的力气。如果遇到需要新增字段的情况也要评估清楚影响范围不要直接在原有的表结构上乱加字段否则很容易出现数据不一致的问题。最后再说一个关于心态的建议真机调试遇到请求失败、白屏、微信缓存不更新这类问题不要慌也不要急着改代码。先想清楚问题出在哪一层是网络请求的问题还是前端数据渲染的问题还是后端业务逻辑的问题。按照这个思路逐层排查绝大多数问题都能在一小时内定位。做这种全栈项目养成先定位再动手的习惯比多背十个框架都要管用。
