前阵子刚把一个学生资助在线管理微信小程序从零到一完整做下来后端用的是 SSM前端是微信原生小程序数据库走了 MySQL最后交付物包含可运行源码和配套文档。这个项目最值得说的地方在于它不只是一套简单的增删改查而是把高校资助工作中“学生申请—辅导员初审—学院复核—校级终审—公示—结果反馈”这条完整业务链搬到了线上。如果你正在为课设、毕设或者练手项目选题发愁又想把前后端整条链路打通那这个选题非常合适。我在这里把从需求拆分、表设计、后端接口到小程序端交互、再到打包部署的完整过程重新过一遍也会把实际开发中踩过的坑和对应的解决思路写清楚。项目里的数据全部是模拟数据流程和字段按普通高校常见模式设计你可以直接照搬也可以按自己手里的需求改。1. 立项之初学生资助管理为什么要“在线化”1.1 传统线下流程的痛点很多人第一眼看到“学生资助在线管理”会觉得这就是个普通信息管理项目实际上它要解决的问题比表面复杂得多。传统线下流程通常是这样的学生打印纸质申请表手写家庭经济情况说明再附上相关证明材料交给辅导员辅导员人工核对后签字送到学院学生工作办公室学院汇总后交到校级资助管理部门由专人再复核一遍最后还要组织公示再统计最终名单。这个过程里问题很明显纸质材料容易丢学生填写的字段经常缺漏辅导员来回退回补材料很费时间学院和校级之间靠 Excel 汇总版本一多就容易对不上学生想查进度只能反复问辅导员沟通成本高到了学期末要做统计报表时数据要重新录入准确率还不敢保证。所以“在线化”的本质不是给纸质表格拍张照而是把每一个环节都变成一条可查询、可追溯、可控制权限的数据记录。项目目标就是让每笔资助申请从创建到结束系统能回答出“当前在谁手里”“是谁在什么时候做的操作”“因为什么被退回”这三个问题。1.2 需求梳理与角色划分接到这个项目需求后我没有直接建表而是先画了一套角色权限图。分析下来至少有四类角色加上管理员就五类角色核心操作数据可见范围学生查看资助项目公告、提交申请、补传材料、查看审核结果自己提交的申请辅导员查看所带班级学生申请、初审、退回、提交学院本班学生数据学院管理员查看本院申请、复核、汇总上报本学院数据校级管理员配置资助项目、终审、公示、统计导出全部数据系统管理员用户管理、角色分配、数据字典维护系统级数据把角色理清之后功能模块自然就浮出来了用户登录注册、资助项目管理、在线申请、审核流程、公示管理、通知公告、附件上传、数据统计、系统配置。做这个项目时最忌讳一上来就写代码先把这些边界定清楚后面接口设计和表结构都会轻松很多。2. SSM 微信小程序技术选型是怎么定下来的2.1 为什么选 SSM 而不是 Spring Boot现在新项目普遍推荐 Spring Boot但这道题目的要求是 SSM也就是 Spring Spring MVC MyBatis。很多人觉得 SSM 过时但如果你是在做课设或毕设SSM 反而是更能体现“底层理解”的选择。它不是靠自动配置把一切包起来而是要求你手动把applicationContext.xml、spring-mvc.xml、mybatis-config.xml一层层配明白。这个配置过程本身就是对 Spring 容器、AOP 事务、MyBatis 会话工厂的一次系统复习。SSM 的分层也非常清楚Controller 负责接收请求和参数校验Service 负责业务规则和事务Mapper 负责 SQL。这种“看得见摸得着”的三层结构写出来的代码最容易答辩讲解也最方便导师检查每一步逻辑。Spring Boot 会把很多细节藏起来反而少了那种“亲手搭起来”的踏实感。2.2 小程序端为什么用原生框架小程序端我也对比过原生、uni-app、Taro。最后选了原生微信小程序。原因是这个项目本身前端页面不算多核心页面就是登录、首页公告、申请、审核列表、结果详情、个人中心这几类原生语法写起来完全够用而且不需要额外引入编译链微信开发者工具打开就能跑。如果目标是快速交付、方便评审现场演示原生框架是最稳妥的。2.3 整体架构拆解整个项目可以拆成五块小程序前端、后端接口层、业务服务层、数据访问层、存储层。请求链路是小程序原生请求 → 后端 Controller → Service 业务处理 → MyBatis Mapper → MySQL 数据库处理结果再原路返回。后端部署在 Tomcat 上提供 RESTful 风格的 JSON 接口。上传的附件统一保存到服务器的uploads目录MySQL 里只记录文件相对路径。线上使用时微信小程序要求接口必须是备案过的 HTTPS 域名所以正式环境需要一台云服务器和一个已备案域名本地调试阶段可以在开发者工具里勾选“不校验合法域名”直接用局域网 IP 访问后端。3. 数据库模型与状态机设计资助流程的核心3.1 核心数据表有哪些数据库设计是这类项目里最重要的一步我把它当成整个项目的“地基”。一共规划了七张核心表。用户表保存学生和管理人员的基础信息包括 openid、姓名、学号、学院、专业、班级、角色类型等。资助项目表用来维护可申请的助学金项目包括项目名称、资助类型、金额、申请起止时间、状态。申请记录表是业务核心保存谁在什么时间申请了哪个项目、当前状态、申请说明、家庭情况描述。审核记录表保存每一次审核动作包括审核人、审核结论、退回原因、审核时间。附件表保存证明材料的上传记录用业务类型和业务ID关联申请记录。公示表保存公示标题、内容、公示起止时间、状态。通知公告表保存系统消息和待办提醒。建表时有一个容易忽略的点申请记录和审核记录千万不要混在一张表里。申请记录只负责保存“申请单本身”审核轨迹单独存这样学生被退回之后再次提交时历史审核记录还能完整保留。后面要做统计报表时这两张表拆开也会方便很多。3.2 状态流转这样设计审核才不会乱资助申请不是一条直线中间会出现退回、补交、驳回等情况。我设计了这样一组状态0草稿学生保存未提交1待辅导员审核2辅导员退回学生可修改后重新提交3待学院复核4待校级终审5审核通过公示中6流程结束7审核不通过流程终止这里最关键的是状态只能按顺序跳不能从待辅导员审核直接跳到公示中。每次更新状态前Service 层都要判断当前状态是不是目标状态的前置状态。我遇到过一些实现比较粗糙的项目学生提交之后还能自己改状态就是因为逻辑里没有做状态机校验。正确做法是每次状态变更都在事务里同时更新申请记录和插入审核记录并写明操作人、操作意见、操作时间这样整个流程才能追溯。3.3 建表语句里值得注意的几个字段拿申请记录表举例核心字段大概长这样。CREATE TABLE application ( id BIGINT AUTO_INCREMENT PRIMARY KEY, student_id BIGINT NOT NULL, project_id BIGINT NOT NULL, semester VARCHAR(20) NOT NULL, status TINYINT NOT NULL DEFAULT 0, apply_reason TEXT, family_desc TEXT, apply_time DATETIME NOT NULL, update_time DATETIME NOT NULL, is_delete TINYINT NOT NULL DEFAULT 0, KEY idx_student (student_id), KEY idx_project (project_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;我特别想强调的是两点。第一所有用户可点击的业务表都要加is_delete逻辑删除字段不要物理删除审核记录一旦物理删除整个流程的可追溯性就没了。第二字符集统一使用utf8mb4因为学生填写的家庭情况描述里可能包含生僻字或者特殊符号只靠utf8容易出现插入报错。4. 后端 Service/Controller 实现要点权限、事务和文件上传4.1 小程序登录openid 才是用户名小程序端没有传统的账号密码它靠微信登录拿到身份。整体流程是小程序端调用wx.login获取临时 code把 code 发给后端后端拿着 code 请求微信接口换取 openid 和 session_key然后根据 openid 去用户表里查找或创建用户最后生成一个自定义 token 返回给前端前端后续请求都带上这个 token。这里有一个非常容易出现的安全问题不要把微信返回的session_key泄露给前端更不要用它来做业务登录判断。前端只需要拿到 token后端把 token 和用户ID的映射关系维护好就够了。登录接口的示例逻辑是这样的。PostMapping(/api/auth/login) public Result login(RequestBody LoginDTO dto) { String openid wxService.code2Session(dto.getCode()); User user userService.findOrCreateByOpenid(openid); String token tokenService.create(user.getId()); return Result.success(token, userService.buildUserView(user)); }用户第一次进入小程序时系统不知道他是学生还是老师。我的处理方式是默认创建为“学生”角色绑定完学生信息之后才能申请管理员账号由系统管理员在后台创建绑定真实 openid 之后自动切换角色。这样可以避免普通用户自己注册成管理员。4.2 申请提交要考虑幂等和事务学生提交资助申请时如果不做限制连续点两次“提交”按钮就会产生两条一模一样的申请记录。后端接口里要做两层防护提交前先查同一个学生在同一个学期对同一个项目是否已经存在未结束的申请业务完成后给前端返回一个不可重复提交的状态标记小程序端也会用节流按钮防止重复点击。更关键的是事务。提交申请这个动作至少涉及三处数据变更插入申请记录、插入附件关联记录、更新资助项目的当前申请人数。这三步必须在一个事务里完成。我平时会用Transactional标注 Service 方法默认遇到 RuntimeException 就回滚。曾经踩过的一个坑是只把事务加在 Controller 上结果异常被提前捕获后事务根本没生效白写一顿。记住事务要加在 Service 层Controller 只做参数接收和响应包装。4.3 附件上传路径要保存相对路径证明材料的审核是整个业务流程里最容易出问题的点。学生需要上传家庭情况证明、收入证明等图片后端用MultipartFile接收文件后按日期生成目录文件名用 UUID 重新命名避免中文文件名和重复名带来的麻烦。String datePath new SimpleDateFormat(yyyyMMdd).format(new Date()); String fileName UUID.randomUUID().toString().replace(-, ) .jpg; String relativePath /uploads/ datePath / fileName; file.transferTo(new File(baseDir relativePath));数据库里保存的是relativePath而不是完整磁盘路径。这样项目换机器部署时只需要改一个上传根目录的配置项就行。文件类型和大小也需要限制我一般只允许 jpg、png、pdf单文件不超过 5MB否则答辩现场一个 20MB 的扫描件能把接口拖到超时。5. 小程序端实现细节从表单到审核的完整交互5.1 登录态管理与角色切换小程序的登录态我用wx.setStorageSync(token, ...)保存每次请求在wx.request的 header 里带上Authorization: Bearer {token}。我封装了一个request工具函数遇到后端返回 401 就自动清理缓存并跳回登录页避免用户停留在失效页面继续操作。角色切换的核心逻辑在用户信息页。学生、辅导员、管理员看到的功能入口不一样我用一个role字段控制首页按钮的渲染。页面跳转时再根据角色判断是否允许进入对应页面不能只隐藏按钮因为小程序页面路径是可以手动输入的后端接口也必须配合权限校验双重保险。5.2 申请表单不用做成万能动态表单一开始我考虑过把申请表单做成动态表单引擎数据库里存字段定义小程序端动态渲染。后来发现对于这个业务来说过度设计。资助项目虽然多但申请信息基本可以归纳为申请理由、家庭情况、证明材料这三类。动态表单看上去灵活实际上会让联调成本翻倍还容易出兼容问题。所以最终方案是固定申请页面结构资助项目表里保存申请须知和金额说明学生填写统一的申请理由和家庭情况描述再上传附件。如果要扩展不同项目的特殊字段我预留了一个ext_infoJSON 字段后续需要的时候再解析不需要现在就做动态组件。5.3 审核列表分页和结果反馈辅导员端审核列表是这个项目的核心页面。列表必须做分页不能一次性把几百条数据都 setData 到小程序端。我用页码和页面大小两个参数请求接口小程序端滚动到底部时自动请求下一页新增数据用数组追加而不是整体覆盖。审核操作这里还有一个体验细节辅导员点击“通过”或“退回”时页面不能只弹一个 toast要弹出确认框并要求填写意见退回时必须填写原因。这样返回给学生端时学生才能知道自己缺什么材料、需要补充什么。在数据库设计上退回原因写入审核记录表学生端申请详情页直接读取最新一条审核记录展示即可。5.4 小程序开发里的几个常见坑先说请求域名。开发阶段可以开“不校验合法域名”但上线前必须换成已备案的 HTTPS 域名而且要在小程序管理后台配置 request 合法域名配置完了还要等几分钟生效不要上线前一分钟才想起来。第二个坑是wx.login的 code 只能用一次。我之前在页面onLoad和onShow都调了登录接口第二次调用拿同一个旧 code 去换 openid结果一直报错。解决方法是只在app.js启动阶段做一次登录把 token 和用户信息放进全局变量。第三个坑是图片提交。小程序端wx.chooseMedia返回的是本地临时路径不能直接传给后端存库必须用wx.uploadFile把图片上传到后端接口拿到返回的文件ID之后再和申请单一起提交。我早期没注意直接把临时路径存进数据库下次打开详情页图片全裂了。6. 项目文档与代码打包毕业设计交付的最后一公里6.1 “文档源码”怎么整理才加分这个项目最终交付时同时包含文档和源码很多人在这一步会翻车。评阅老师拿到代码包的第一件事通常是看 README里面如果写着怎么启动、数据库怎么初始化、默认账号是什么整体印象会好很多。我习惯把文档拆成这样几个部分需求说明文档、数据库设计文档、接口文档、部署说明文档、操作手册。需求说明里要把角色和流程写清楚配上业务流程图文字版。数据库设计文档里放完整建表语句、ER 关系说明、每个字段的注释。接口文档我用表格列出接口地址、请求方式、入参、出参并用 Postman 导出了一份可导入的接口集合。部署说明要写到 JDK、Tomcat、MySQL 版本这种细度否则换一台电脑根本跑不起来。源码部分我会单独建一个sql目录放初始化脚本一个uploads目录放示例图片并写一个config说明文件把数据库连接、上传路径、小程序请求地址这些容易改漏的配置集中放在开头。代码里不要写绝对路径比如C:/...这种否则换个人启动直接报文件找不到。6.2 本地部署环境与联调配置我的调试环境是 JDK 1.8、Maven 3.6、Tomcat 8.5、MySQL 5.7微信开发者工具用最新稳定版。SSM 项目用 Maven 打成 war 包放到 Tomcat 的 webapps 下访问后端接口地址是http://localhost:8080/student-fund/小程序端把全局 baseURL 改成这个地址在开发者工具里勾选“不校验合法域名”即可联调。这里有一个很误导人的地方小程序端如果不开“不校验合法域名”本地连局域网 IP 的 HTTP 接口都会被拦截而且报错信息不一定很明显经常被误以为是后端没启动。遇到请求连不通时先看是不是域名校验的问题再看后端日志最后再查网络。6.3 我踩过的几个坑与复盘这个项目里最折腾我的三个坑我简单复盘一下。第一个是 MyBatis 的驼峰映射。数据库字段是apply_timeJava 属性是applyTime如果不开启map-underscore-to-camel-case查询出来的对象里这个字段永远是 null。在 mybatis-config.xml 里加一行配置就能解决但第一次做 SSM 项目时很容易忽略。第二个是事务没有生效。我最初把Transactional加在了 Controller 的 private 方法上Spring 默认代理只拦截 public 方法private 方法上的注解完全没作用。熬夜查了半天才发现是这个问题后来把业务方法移动到 Service 层并改成 public事务就正常了。第三个是时间格式。学生申请起止时间和公示起止时间跨时区或者数据库时区设置不对时会出现截止时间比实际晚 8 小时的情况。后端统一使用字符串格式yyyy-MM-dd HH:mm:ss传给前端MySQL 连接字符串里加上serverTimezoneAsia/Shanghai这个问题才算彻底解决。项目做到最后我对 SSM 和小程序这套组合的理解比开始时深入了不少。如果时间充裕后续可以再扩展消息推送让学生端在审核结果出来后收到模板消息提醒也可以增加资助数据统计看板按学院、项目、学期维度导出报表。这种扩展方向基本都是在现有表结构和接口上做加法不会推翻重来。希望这篇记录能给正在做同类项目的你一点参考少走几个我走过的弯路。
