微信小程序 SSM放在课程设计和毕业设计里几乎是出现频率最高的固定组合之一。光看题目以为只是个打分页面真正动手做起来才发现用户角色、评分状态、防重复提交、Token登录、数据统计、域名部署一环扣一环任何一个环节没想清楚演示环节就容易翻车。我做过也指导过不少评分类小程序今天就拿微信小程序评分小程序ssm这个经典题目做例子把从需求拆解到部署联调的完整链路从头到尾讲一遍。不管你是正在准备课设的在校生还是想快速上手这类外包项目的开发者这篇都能给你一套可以直接落地的实战经验。1. 项目设计与技术选型思路1.1 评分需求拆解谁、给谁、按什么维度评评分系统表面上是一个打分页面但它背后是一条完整的业务链路。第一要确定角色关系是谁在什么场景下给谁评分。以最常见的课堂教学质量评价为例学生给自己的任课教师和所学课程评分。第二要确定评分维度一般拆成教学态度、教学内容、教学方法、课堂效果几个一级指标每个指标下再细化若干评分项。第三要确定评分后的数据流向学生提交后不能再修改教师能查看自己课程的平均分和评语分布管理员能看全院汇总报表。这三个问题在代码动工前必须全部敲定否则后期改接口、改表结构都是大工程。这里有一个很典型的忽略点状态流转。一门课对某个学生来说只存在未评和已评两种状态。如果设计时没把这种状态体现在表结构或者接口逻辑里后面就会出现重复评分的脏数据。我见过有项目为了省事不记录任何状态学生提交后再点一次还能提交统计结果直接错乱。所以设计阶段就要明确评分动作只能发生一次查询时能看到当前课程的评分状态。评分动作虽然是核心但管理者真正关心的其实是统计结果。不少同学把大部分精力放在打分页面的动画和交互上后台统计分析却做得很简陋属于本末倒置。评分系统的价值排序应该是数据准确 统计清晰 交互好看。功能边界想清楚之后再去做页面和接口整个开发节奏会顺畅很多。1.2 为什么SSM 微信小程序仍然是稳妥组合先别急着嫌弃SSM技术老对课设和毕设来说稳定、好理解、文档丰富远比最新重要。微信小程序是天然贴合这种轻量业务场景的终端学生扫码即用不需要额外安装App分发和使用门槛都低。小程序的开发规范也很清晰原生框架的文档和社区内容极其丰富遇到问题基本都能搜到解决方案。后端用SSM对做课程设计的同学来说是稳妥中的稳妥。Spring负责依赖注入和事务管理SpringMVC负责请求路由和参数绑定MyBatis负责ORM和SQL映射。这一套三层结构非常好画图、好写文档答辩时不管是画流程图还是讲解层与层之间的调用关系都比用全自动脚手架更有内容可以展开。这类项目在面试或答辩时的得分点往往不是你用了多新的框架而是你有没有把业务逻辑讲清楚。还有一个很现实的原因管理端不需要单独维护。SSM项目里管理后台可以直接用JSP或简单HTML模板放在同一个工程里最后打成一个war包就能部署。对比前后端分离方案web管理端和小程序端要维护两个前端工程部署时还要考虑跨域和Nginx转发对时间有限的课设项目来说复杂度会高不少。我自己做这类项目时更倾向于把复杂度控制在能完全掌控的范围内。1.3 项目目录规划与开发顺序拿到题目我习惯先规划目录不急着写代码。典型做法是把整个项目拆成三个目录miniapp放微信小程序源码ssm放后端工程docs放需求文档、数据库设计文档、接口文档和测试记录。小程序端内部按功能模块拆登录、待评列表、评分页、统计结果、个人中心。后端按controller、service、mapper、pojo、common、utils分层common里放统一返回结果类和全局异常处理utils里放Token工具、日期工具这些通用能力。开发顺序我建议按数据库 - 后端接口 - 小程序页面 - 联调来推进。先把表结构和接口文档定下来前端才有可能并行开发不然几乎一定会出现返工。很多同学喜欢直接从页面写起结果后端接口和前端数据结构对不上改起来非常痛苦。顺序这件事先想清楚后面能省下一大半调试时间。2. 小程序端交互设计与核心实现2.1 页面结构与请求层的统一规划小程序端页面不建议拆得太散我通常用五个主要页面解决登录页、首页课程列表、评分页、结果页、我的页面。首页拉取当前学生待评的课程列表每门课显示课程名称、授课教师、已评或未评状态。点击未评课程进入评分页点击已评课程可以查看自己提交过的分数。结果页主要给教师角色使用展示名下各门课程的平均得分和评语列表。我的页面负责显示当前登录用户信息同时提供退出登录和角色切换入口。页面之外小程序端最重要的基础设施是请求封装。我把所有网络请求收敛到utils/request.js里统一处理这样每个页面不需要关心token怎么带、错误怎么弹窗。封装的逻辑大致是进入request后从本地缓存读取token放进header调用wx.request在success回调里判断HTTP状态码和业务状态码遇到401清掉本地token并跳转登录页其他错误统一toast提示。这样的好处是联调阶段改接口地址或者统一加header时只需要动一个文件。2.2 评分页面的交互细节与数据格式评分页看起来交互不复杂但细节非常多。每个指标项对应一个滑块或星级评分滑动时实时回显分数。我习惯用slider组件绑定一个scoreList数组change事件里通过currentTarget的data-index更新对应位置的值。所有指标项要有明确的默认值或未评分状态提交前做校验如果存在未评分项直接提示还有指标未评分不发起请求。提交的数据结构建议用JSON数组我一般设计成{ courseId: 1024, teacherId: 8, scores: [ { itemId: 1, score: 92 }, { itemId: 2, score: 88 }, { itemId: 3, score: 95 } ], comment: 老师上课节奏很好案例分析非常实用。 }这样做的原因是后端接收参数非常固定只需要遍历scores数组逐条插入明细不需要为每一个指标定义独立字段。将来指标项变更时前端加一个对象就行接口不用变。提交按钮在请求发起时要加loading和disabled这是防止双击重复提交的第一道防线但绝不能只依赖这一层。评语是选填项不过建议限制最大长度避免有人塞进几百字把数据库字段撑爆。2.3 自定义导航栏高度计算与机型适配评分页这类业务页面往往需要自定义顶部导航栏因为原生导航栏样式限制太多放不了进度条或自定义标题。但一旦用了自定义导航就必须处理状态栏高度和右上角胶囊按钮的位置。不同手机状态栏高度差异很大特别是刘海屏和挖孔屏写死px的话换一台手机就可能顶到摄像头区域。正确做法是动态计算const winInfo wx.getWindowInfo() const menuRect wx.getMenuButtonBoundingClientRect() const statusBarHeight winInfo.statusBarHeight const navHeight (menuRect.top - winInfo.statusBarHeight) * 2 menuRect.height把计算出的statusBarHeight和navHeight存入页面datawxml里通过style动态设置导航栏容器的高度和标题位置。这里有一个很多人踩过的坑页面从A跳到B再返回时B页面的onLoad不一定会重新触发如果依赖onLoad计算导航高度B页面可能出现高度错位。建议在app.js里统一计算一次全局缓存各页面直接读取一套代码适配iPhone、安卓和鸿蒙机型。3. SSM后端接口设计与数据库建模3.1 核心数据表结构与字段设计评分系统的数据库设计是整个项目的地基。核心表包括sys_user账号表、teacher教师信息表、course课程表、evaluate_item评分指标表、evaluate_record评分主记录表和evaluate_detail评分明细表。账号表用role字段区分学生、教师、管理员教师和学生的业务信息单独维护这样账号系统和业务信息解耦后面想改登录方式不会影响业务表。表名用途关键字段sys_user登录账号id, username, password, role, statusteacher教师信息id, name, emp_no, departmentcourse课程信息id, course_name, teacher_id, semesterevaluate_item评分指标id, item_name, max_score, weight, sortevaluate_record评分主记录id, course_id, teacher_id, student_id, status, create_timeevaluate_detail评分明细id, record_id, item_id, score设计时有几个细节值得注意。evaluate_record和evaluate_detail之间用record_id关联明细表不需要重复存course_id和student_id避免数据冗余。课程和教师是一对多关系course表里直接存teacher_id。评分指标表的weight字段是权重如果所有指标等权默认填1就行。最关键的一个约束是evaluate_record表要加唯一索引字段是course_id和student_id从数据库层面杜绝重复评分。3.2 分层架构与评分提交接口实现SSM工程的分层我一般这样划分Controller只做参数接收和结果返回不写业务代码Service负责业务规则校验和事务控制Mapper只负责SQL和数据库交互。以提交评分为例Controller接收前端传过来的JSON请求体和token从token里解析出当前学生的userId再把数据交给Service处理。Controller RequestMapping(/api/evaluate) public class EvaluateController { Autowired private EvaluateService evaluateService; PostMapping(/submit) ResponseBody public Result submit(RequestBody EvaluateSubmitVO vo, RequestHeader(token) String token) { Integer studentId TokenUtils.getUserId(token); return evaluateService.submitEvaluate(studentId, vo); } }Service里的核心逻辑是先校验课程是否存在、当前学生是否选了这门课、是否已经评过分校验通过后先插入evaluate_record主表拿到自增id再循环scores数组批量插入evaluate_detail明细最后把课程状态更新为已评。整个方法加Transactional任何一步异常都要整体回滚否则会出现主表有记录但明细缺失这种脏数据。这里判断是否已经评过分的逻辑要放在事务内先查询再插入才能尽量避免并发问题。3.3 Token认证与统计接口的常见设计模式小程序端和传统浏览器会话机制不同不能用session保存登录态我一般统一采用Token方式。具体流程是用户在小程序端调用wx.login拿到code后端拿code换openid查询或创建用户后生成一个唯一token把token和userId的映射关系存入缓存设置过期时间最后把token返回给前端。前端每次请求在header里携带token后端用一个拦截器统一校验排除登录接口和静态资源路径其他接口全部走Token校验。统计结果接口是管理员和教师最关心的功能建议按课程和教师两个维度聚合。按课程统计时查出该课程所有评分记录的平均分、参评人数和各分数段人数按教师统计时汇总该教师名下所有课程的数据。SQL里用AVG函数求平均分如果指标涉及权重需要先乘以weight再累加不能简单取平均值。统计操作比较耗资源如果数据量到几千条以上建议增加一张汇总表提交评分时同步更新或者定时刷新页面查询直接读汇总表不要在每次请求时实时扫描全表明细。4. 前后端联调与服务器部署实录4.1 request封装与本地跨域联调联调第一步是让小程序端能正常访问本地后端接口。我在request.js里统一管理baseURL开发环境用http://127.0.0.1:8080生产环境切换成正式域名。调用wx.request之前先读取本地缓存的token放入header然后在success回调里统一处理返回数据结构解析出业务code和data。如果接口返回401全局清token并跳转登录页。本地联调有一个必经步骤在微信开发者工具右上角详情 - 本地设置里勾选不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书。不勾选的话本地请求http接口会被工具直接拦掉很多同学第一反应是后端没启动其实问题就出在这里。这个开关只在开发时使用正式版发布后请求必须是HTTPS域名。4.2 war包部署与Linux环境适配后端部署最直接的方式是打成war包丢到Tomcat的webapps目录。部署前检查这几项applicationContext.xml里的jdbc.properties配置的数据库地址、账号密码是否改成服务器环境MyBatis的mapper.xml路径是否匹配日志输出目录在服务器上是否存在。很多同学本地跑得好好的部署到云服务器就各种报错八成是配置文件和路径问题。Linux环境和Windows差异最大的地方是MySQL表名大小写。Windows下MySQL不区分大小写Linux默认区分如果你的建表语句和查询SQL里大小写不一致上线后大概率报Table doesnt exist。建议表名字段名全部统一成小写不要在SQL里写驼峰。另外MySQL连接串建议加上serverTimezoneAsia/Shanghai否则时间字段会差8个小时评分记录的时间看起来就像穿越了。war包名字也有讲究。如果打成ssm-1.0.warTomcat解压后访问路径会变成http://ip:8080/ssm-1.0/小程序端的baseURL就必须带上/ssm-1.0这个上下文路径少一个前缀全部404。我习惯把war包改名为ROOT.war再部署访问时直接走根路径省掉项目名的麻烦。4.3 正式环境HTTPS域名与发布检查小程序线上发布有一个硬性要求request接口必须是HTTPS并且域名要在微信公众平台的小程序后台配置成合法域名。这意味着需要一台云服务器、一个备案过的域名和SSL证书用Nginx监听443端口配置证书后把请求反向代理到Tomcat端口。我的建议是先在服务器上把后端接口全部用Postman或浏览器验证一遍特别是登录、提交评分、统计查询这几个核心接口确认路径和参数都没有问题后再在小程序开发者工具里把baseURL切到正式地址做一次全流程回归。演示之前把测试账号和测试课程数据准备好数据来不及造就直接用初始化SQL脚本导入。这些准备工作能避免现场演示时最尴尬的接口不通。5. 常见问题与排查速查5.1 接口404/500的定位方法接口404优先排查两件事。第一Controller类所在的包有没有被Spring的component-scan覆盖到漏掉的类不会注册bean请求自然找不到。第二RequestMapping里的路径和前端传的URL是否严格一致多一个斜杠、少一个斜杠都会匹配不上。还有一种情况是web.xml里没有配置SpringMVC的DispatcherServlet拦截路径导致所有请求都进不了Controller。接口500直接看Tomcat日志的完整堆栈不要只看控制台输出。堆栈会明确告诉你是空指针、SQL异常还是参数转换失败。MyBatis操作报错时把日志级别调到DEBUG控制台会打印出实际执行的SQL和绑定参数值比对着代码猜要高效得多。遇到过很多次前端传的字段名和后端实体属性对不上MyBatis的自动映射又没开启驼峰转换结果查出来全是null。5.2 登录过期与Token失效处理评分类小程序的使用频率通常不高用户隔几天再打开时token很可能已经过期。我在request.js里做了统一拦截当接口返回401时清理本地存储的token和用户信息跳转登录页并提示登录已过期请重新登录。这里要注意不要让每个页面各自处理登录过期逻辑否则多个请求同时失败时会重复跳转登录页。最好是请求层统一处理页面层完全无感知。另外token和用户信息用wx.setStorageSync存储时建议手动设置一个合理的过期时间配合后端token有效期一起控制避免用户几个月不打开导致数据过于陈旧。小程序冷启动时可以主动检查一次本地缓存时间过期就直接回登录页别等接口报错才处理。5.3 重复提交与数据一致性兜底重复提交是评分系统演示时最容易翻车的问题也是答辩老师最喜欢追问的点。场景很简单学生快速点了两次提交前端按钮loading已经被disabled拦住但后端接口如果被脚本重放还是可能产生两条评分记录统计平均分直接算错。我的处理方式是三层防御前端按钮disabled、后端Service里事务内先查询再插入、数据库加唯一索引。ALTER TABLE evaluate_record ADD UNIQUE KEY uk_course_student (course_id, student_id);事实上不管业务代码里怎么判断数据库唯一索引才是防重最可靠的一层。任何并发请求只要撞上唯一索引都会被数据库直接拒绝然后抛出DuplicateKeyException我们只需要在Service里捕获这个异常转成业务提示就行。这个设计一定要在项目演示前就做好因为这是最容易暴露的一个细节。5.4 评分页性能与分页加载如果课程数量比较多首页待评列表不能一次性把全部数据返回。接口要做分页前端用scroll-view配合上拉加载通过hasMore标记判断还有没有下一页。评分历史记录页也一样特别是教师端查看评语列表时数据量大了之后接口响应会很慢建议分页并加时间范围筛选。还有一个容易被忽略的点是图片资源。如果课程列表里带课程封面图不要在小程序端直接加载大图后端接口返回压缩图URL或者用image组件的lazy-load属性。评分页面本身是高频交互页要避免资源过多导致的卡顿。这些细节不会写进功能需求里但直接影响使用体验。做评分类小程序这类项目我最大的体会是技术点本身并不难难的是整个流程能闭环。从数据库设计到前端交互从防重复提交到Token过期处理每一个看起来不起眼的点都会在演示和答辩时被放大。一个代码量不大但逻辑完整的项目远比一个堆了很多页面但到处是坑的项目更让人印象深刻。最后分享一个实用习惯在项目根目录放一个database.sql初始化脚本把建表语句和测试数据全写进去部署时一条命令就能初始化比手动用数据库工具点半天可靠得多。评分类项目的管理后台还可以进一步扩展成多角色问卷、活动报名、满意度调查这样的通用模板核心思路都是一样的。把这些基础能力沉淀好下次再接类似需求速度会快很多。
