简介面向高校毕业设计的设备故障报修小程序项目基于微信小程序SSMMySql实现包含管理员、用户、维修员三类角色覆盖报修提交、维修报告、经验分享、实验室管理等功能模块。后台采用Java SSM框架与MySQL数据库前端使用微信开发者工具适合作为计算机专业毕业设计参考模板也适合入门学习前后端分离开发。包内共1255个文件集成源码、数据库脚本、毕业论文和视频演示。文件类型涵盖Java后端代码、Vue管理端页面、微信小程序wxml/wxss/js前端代码、SQL数据库文件以及png/jpg图表素材压缩包整体约49.98MB目录结构清晰。已有131人学习下载。附带完整的系统分析、可行性分析和数据库设计等文档并包含可运行的源码与录屏演示能够帮助读者快速掌握项目架构、业务流程和毕业论文写作结构。1. 设备故障报修小程序一套能直接拿去答辩的SSM微信小程序毕设方案如果你正在为毕业设计选题发愁又不想只做个花架子管理系统那基于微信小程序 SSM MySQL 的设备故障报修小程序是个非常务实的选择。它的核心价值在于前端用微信小程序降低用户使用门槛后端用 SSM 框架把业务逻辑和数据持久化讲得清清楚楚整条链路从用户扫码报修、维修工接单处理到管理员统计复盘闭环完整又有真实业务场景非常适合在答辩时展示你的系统设计能力。这篇笔记我会直接对着这个标题拆解技术选型为什么合理、数据库怎么设计、接口如何落地、小程序端怎么对接以及哪些地方最容易让你翻车。全程照着做你手里的源码、数据库和论文就能真正变成你自己能讲清楚的东西。2. 报修业务的数据底座与立项逻辑先搞清楚状态机再写表2.1 报修单状态流转是整套系统的命脉做报修系统的第一步永远是梳理业务状态机而不是急着建表。一个标准的报修流程至少包含这几个节点待受理、已派单、维修中、待验收、已完成以及双方都可能触发的已驳回或已取消。你会发现后端每个接口、小程序每个按钮都是围绕状态的变化在写逻辑——查询列表要按状态筛选提交操作要校验当前状态统计报表要按状态分组甚至权限控制也跟状态相关。我用状态机把这套流转画出来用户提交报修后单据进入待受理管理员或调度员把一个单子指派给维修工它变成已派单维修工到场开始处理标记为维修中处理完提交结果后转以待验收用户或管理员验收通过流程走到已完成。任何环节发现问题比如维修工报错单子、用户取消申请就落到已驳回或已取消。数据库层面状态的变更记录配合一张操作日志表就能让论文里的时序图、状态图都有的画。CREATE TABLE repair_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 报修单号业务编号用于展示和搜索, user_id BIGINT NOT NULL COMMENT 报修人关联用户表, device_name VARCHAR(64) NOT NULL COMMENT 故障设备名称, device_location VARCHAR(128) NOT NULL COMMENT 设备位置精确到房间或区域, fault_desc VARCHAR(500) NOT NULL COMMENT 故障描述来自小程序表单, image_urls TEXT COMMENT 现场照片URL逗号分隔最多支持三张, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0待受理1已派单2维修中3待验收4已完成5已驳回6已取消, assignee_id BIGINT COMMENT 维修工ID派单时写入, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL );这里尤其建议把 order_no 这种业务单号单独设计出来不要直接用自增主键对外暴露。原因有两个一是论文里写一个编码规则更显专业性比如先取时间戳再加随机数二是小程序端拿 order_no 做展示和检索时不会把数据库行数泄露出去。create_time 和 update_time 尽量让 MyBatis 统一填充后面写 SQL 和 Java 代码时能省去大量重复赋值。2.2 用户权限与角色拆分三种角色一套登录体系报修流程里至少有三种参与角色普通用户、维修工、管理员。数据库设计上我的建议是不要用独立的角色表加多对多关联而是直接在 sys_user 表里放 role 字段因为业务角色固定就三个做成三张表反而让查询复杂化。初始化数据时管理员账号在 SQL 脚本里直接 INSERT维修工账号由管理员在后台创建普通用户则通过微信登录机制自动注册。CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, password VARCHAR(128) COMMENT 管理端账号需要小程序用户可留空, nickname VARCHAR(64), openid VARCHAR(64) UNIQUE COMMENT 小程序登录凭证, avatar VARCHAR(255) COMMENT 头像, phone VARCHAR(20), role TINYINT NOT NULL COMMENT 1普通用户2维修工3管理员, status TINYINT NOT NULL DEFAULT 1 COMMENT 是否启用, create_time DATETIME NOT NULL );密码字段只对后台账号有用小程序端的用户走 openid 登录理论上不需要密码。这里要注意MyBatis 的 ResultMap 在映射这种只有一个唯一逻辑主键的表时没什么坑但遇到字符串和数字隐式转换时要小心比如 status 传了 1 字符串框架不会替你强转SQL 层会按数据库隐式规则处理容易查出空列表。2.3 数据库脚本的初始化策略要给论文附上完整建表脚本答辩时导师大概率会打开你的数据库看表结构甚至会要求现场导入脚本重新跑一遍。所以数据库脚本文件要做得足够完整包含 CREATE TABLE、初始管理员账号、演示用的维修工和几条不同状态的报修单。初始数据的 status 要刻意覆盖多个阶段这样小程序端和管理后台打开时能看到不同状态下的真实界面效果不是在同一个列表里全是待受理。用户反馈表或评价表我建议也加上。也就是完成验收时填一条评价数据形成一个完整的业务闭环。表结构很简单id、order_id、user_id、rating、comment、create_time 六个字段就够但它的存在意味着你考虑了用户体验反馈这在开题报告和论文里都是加分项。3. SSM 后端接口设计从 Spring Boot 配置到 MyBatis 动态 SQL3.1 项目结构怎么摆才不容易在开发时迷路后端我建议用 Maven 管理依赖结构上分成 controller、service、mapper、entity、common 五个包。controller 只做参数接收和结果封装service 层做业务和状态流转判断mapper 层只写 SQL 和数据访问代码。很多初学者习惯把业务逻辑直接堆在 controller 里写完当下很快但后面遇到微信小程序的 session 校验或者状态冲突时会改得想砸电脑。SSM 体系里 Spring Boot 不算严格意义上的 SSM因为 SSM 的本意是 Spring SpringMVC MyBatis 手动整合Spring Boot 把 SpringMVC 融入自动配置让你少写一堆 XML。毕设答辩时你可以说“底层仍然是 SSM 技术栈只是采用了 Spring Boot 这种简化配置的方式”这完全站得住脚。依赖里只需要四个核心spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-java、lombok其他按需添加。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.0/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependencymybatis-spring-boot-starter 2.3.0 是个比较稳的版本不需要额外写 SqlSessionFactory 的 XML。数据源配置写在 application.yml 里注意 MySQL 8 以上驱动要带 cj 前缀时区参数 serverTimezone 最好显式指定为 Asia/Shanghai否则部署到服务器之后所有时间都会差 8 小时这种问题排查起来很折磨人。3.2 核心接口清单报修单创建、派单、状态推进后端接口不追求多而是要让关键路径完整。我用一个最简单但覆盖完整流程的清单举例子POST /api/repair/create 接收小程序提交的报修数据GET /api/repair/list 按角色和状态分页查询POST /api/repair/assign 让管理员把单子派给维修工POST /api/repair/updateStatus 做状态推进POST /api/repair/evaluate 提交验收评价。不需要额外设计过多的细碎接口够演示一个闭环就行写太多反而增加答辩时被你导师追问的风险。状态推进接口是这套系统最容易出错的地方因为不能无条件跳转。比如一张已完成的单子不能再变回维修中已取消的单子也不能被派给维修工。这个校验逻辑放在 Service 层最合适Mapper 层不要管业务。代码实现时先根据 ID 查出当前数据再把当前状态和目标状态放进一个允许的状态映射表判断不匹配直接抛业务异常统一由全局异常处理器返回给前端。Override Transactional(rollbackFor Exception.class) public void updateStatus(Long orderId, Integer targetStatus, Long operatorId) { RepairOrder order repairOrderMapper.selectById(orderId); if (order null) { throw new BusinessException(报修单不存在); } // 状态流转校验当前状态和目标状态必须匹配 boolean allowed checkTransition(order.getStatus(), targetStatus); if (!allowed) { throw new BusinessException(非法状态流转: order.getStatus() - targetStatus); } repairOrderMapper.updateStatus(orderId, targetStatus); // 记录操作日志 operationLogMapper.insert(orderId, operatorId, 状态变更为: targetStatus); }Transactional(rollbackFor Exception.class) 这里值得多说一句。如果你在 Spring 里直接写 Transactional 不加 rollbackFor那么当方法抛出异常时事务是否回滚取决于异常类型对于自定义的 BusinessException 这类 RuntimeException 是没问题的但如果你后面改成 throw new Exception 这种受检异常事务默认不会回滚数据会处于半写状态。所以统一加上 rollbackFor 是最保险的写法。3.3 MyBatis 动态 SQL报修单列表的条件筛选技巧列表接口几乎是必写的。普通用户只看自己的单子维修工看指派给自己的单子管理员看全部单子而且这三种人还都可能叠加状态字段筛选动态 SQL 不写你就得拼字符串或写多个静态 SQL维护性很差。MyBatis 的where配合if标签就是来干这个事的。select idselectByCondition resultTypecom.example.entity.RepairOrder SELECT * FROM repair_order where if testuserId ! null AND user_id #{userId} /if if testassigneeId ! null AND assignee_id #{assigneeId} /if if teststatus ! null AND status #{status} /if if testorderNo ! null and orderNo ! AND order_no LIKE CONCAT(%, #{orderNo}, %) /if /where ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} /select这里有个常见的坑if里千万别写status ! 这种判断因为 Integer 类型的 status 如果只想判断非空写teststatus ! null就够了。一旦同时写 status ! 框架会解析属性不存在或类型比较出错。另外 ORDER BY create_time DESC 放在动态 SQL 外面MyBatis 不会给你包一层顺序是可控的。分页我用的是手写 LIMIT offset, pageSize毕设里完全够用可以少引入 PageHelper 这种插件依赖。如果导师问起来为什么不用分页插件你说项目规模不大、手写 SQL 更容易控制查询条件就行。真要用 PageHelper 也行但要注意它必须在查询语句之前开启分页否则 SQL 语句会被改写出 bug。4. 微信小程序端从登录授权到报修全流程的页面实现4.1 小程序登录与后端 Session 对接小程序端和后端的交流核心是 wx.request但登录链路一定要先搞清楚。小程序通过 wx.login 拿 code把 code 发给后端后端再用 code 去微信接口换 openid 和 session_key。openid 是用户在你这套系统里的唯一身份标识你要拿它去 sys_user 表查是否有记录没有就自动注册一条新用户数据然后后端生成自定义登录态字符串返回给小程序。我再强调一点后端拿到 openid 之后不要每次都带着 openid 来作为登录凭证。标准做法是后端生成一个 token 返回给小程序小程序把 token 存到 storage之后的请求在 header 里携带。后端从 token 里解析出用户身份。这个设计避免了把 openid 暴露在请求体里被人伪造答辩时也会被认为是考虑了安全性的好习惯。wx.login({ success: (res) { wx.request({ url: http://localhost:8080/api/auth/login, method: POST, data: { code: res.code }, success: (loginRes) { const token loginRes.data.data.token; wx.setStorageSync(token, token); // 登录成功后跳转到首页或列表页 wx.switchTab({ url: /pages/index/index }); } }); } });如果你想做得更快可以用自定义登录态比如 UUID 直接返回不引入 JWT 系列依赖。JWT 本身需要秘钥管理和过期时间判断对小项目可能反而增加复杂度。不过注意到 wx.login 的 code 5 分钟内有效且只能使用一次后端接口要做防重放处理至少保证换过 openid 之后不会二次成功这个点写成代码注释复盘时说明你能意识到安全问题。4.2 报修表单页图片上传与页面路径的自定义实现报修表单是整个小程序端交互最重的页面核心模块有设备名称、位置、故障描述和图片上传。文字字段都好处理麻烦的是图片上传。小程序的 wx.chooseMedia 可以从相册选图之后用 wx.uploadFile 把图片传给后端单独的接口后端返回图片 URL前端再把 URL 和其他字段一起提交给创建报修单接口。我这里有个建议把上传接口和后端业务接口分开不要上传图片的同时把报修单也提交了。好处是用户体验更好。用户先传图片、看到预览效果确认之后再点提交按钮整个交互符合直觉。后端 image_urls 字段存逗号分隔的相对地址将来部署到服务器时图片所在的静态目录需要单独映射。Spring Boot 里可以通过 WebMvcConfigurer 配置虚拟路径映射把本地磁盘目录映射到 /images/**这样图片 URL 是类似于 /images/20250407/xxx.jpg 的形式在数据里存的就是这种相对地址。wx.chooseMedia({ count: 3, mediaType: [image], sourceType: [camera, album], success: (res) { const tempFilePaths res.tempFiles.map(item item.tempFilePath); // 逐个上传到后端 /api/file/upload tempFilePaths.forEach((path, index) { wx.uploadFile({ url: http://localhost:8080/api/file/upload, filePath: path, name: file, success: (uploadRes) { const imageUrl JSON.parse(uploadRes.data).data; imageList.push(imageUrl); } }); }); } });count: 3 限制图片张数这个参数在平时做演示时候非常有用。多传图片后端存储压力和微信上传耗时都会增长。我在实际测试中5 张以上的图片在网速一般的情况下会明显感觉到提交卡顿3 张刚刚好既证明了功能又保住体验。sourceType 同时选择 camera 和 album真机预览时用户能切换拍照或相册这里不要只留其中一个答辩演示时如果现场没有现成图片可以直接拍照。4.3 角色视角差异同一个列表页如何呈现不同端小程序端不用给管理员做完整后台但普通用户和维修工两个视角最好要在界面上区分开。普通用户进入列表页看到的是自己提交的单子和状态维修工看到的则是待受理、已派单以及自己处理中的单子。同一个页面组件根据用户角色决定渲染内容和操作按钮。我通常的处理方式是在进入页面时先请求一个用户个人信息接口获取 role 字段存到全局变量 app.globalData.userInfo。列表渲染时普通用户每个卡片底部显示“取消申请”按钮维修工显示“接受任务”和“提交结果”按钮具体显示哪个由状态和角色共同决定。这样前端只用一个列表组件代码量减少而且逻辑统一。// 操作按钮的显示逻辑先判断角色再判断状态 const showButton (item) { const role app.globalData.userInfo.role; if (role 1) { // 普通用户待受理时可取消待验收时可确认完成 return item.status 0 || item.status 3; } else if (role 2) { // 维修工待受理可接单已派单可开始维修维修中可提交完成 return item.status 0 || item.status 1 || item.status 2; } return false; };维修工接单的逻辑值得注意。派单有两种模式一种是管理员手动指定维修工另一种是维修工抢单。毕设做手动指派即可逻辑简单且容易绘制业务流程图。维修工点击接单时接口要做一次校验单据必须还是待受理状态才能被设为已派单并写入 assignee_id防止两个维修工同时点接单都成功。我见过有人在表里搞了锁机制结果复杂化了代码。用乐观锁或者先 UPDATE 来判断影响行数更符合真实项目习惯。5. SSM 与小程序联调避坑指南5 个高频率翻车点实测记录5.1 本地调试时微信开发者工具请求后端接口的域名白名单现象小程序端模拟器里请求 http://localhost:8080 能通但真机预览时请求失败报 url not in domain list。原因微信小程序平台要求正式环境下请求域名必须是 HTTPS 且在后台配置了白名单模拟器勾选了“不校验合法域名”所以本地才通。真机预览默认不跳过校验。解决开发调试阶段在微信开发者工具的“详情 - 本地设置”勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”这样真机预览也能请求局域网 IP 地址。但你部署上线时必须换成备案域名加 HTTPS同时在小程序后台的 request 合法域名里添加这个域名。我记得有时候明明配置好了还是报错那是配置修改后没有重新编译或者浏览器缓存住了。# 真机预览时使用的后端地址不建议写 localhost改成电脑在局域网中的IP # 例如: http://192.168.x.x:8080 # 原因是手机上的 localhost 指向手机自己5.2 时间字段从 MySQL 查询后相差 8 小时现象数据库存的时间是当前时间查询出来的结果却差了 8 个小时在列表页显示的时间总是凌晨。原因MySQL 的 JDBC 连接串里没有指定 serverTimezone驱动默认使用服务器时区。国内环境多半是 UTC 与本地时区 Asia/Shanghai 的偏差。部分较新的 MySQL 版本默认时区就是 UTC偏差整整一个时区。解决在 application.yml 的 JDBC URL 中明确加 serverTimezoneAsia/Shanghai 和 useSSLfalseMySQL 8 驱动还要求加 allowPublicKeyRetrievaltrue。如果仍然不对检查服务器系统时区Linux 可以用 timedatectl set-timezone Asia/Shanghai 统一。小程序端展示时可以不再做额外偏移处理前端拿到的时间就是正确的。spring: datasource: url: jdbc:mysql://localhost:3306/repair_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: yourpassword5.3 文件上传成功但图片在页面上不显示现象上传接口返回了 URL小程序端拼接成 http://localhost:8080/images/xxx.jpg 后渲染 显示空白真机预览时更严重。原因前后端分离的地址拼接错误。如果上传接口返回的是相对路径 /images/20250407/xxx.jpg小程序端直接拿这个值放在 src 里无法识别而且后端本地磁盘映射的虚拟路径在局域网内也不能用 localhost 访问。解决后端返回相对路径前端根据 request 的 baseUrl 拼接完整路径。baseUrl 就是你配置的LocalHost或局域网IP。比较稳的做法是后端返回 Map 里同时带 fileUrl 和完整路径但工程上更推荐前端统一维护一个 API_BASE_URL 变量所有请求都基于它拼接。注意图片域名在小程序里不受 request 合法域名限制它是 downloadFile 合法域名控制开发阶段同样可以通过勾选不校验域名跳过但论文里最好写清楚上线时要配置。5.4 报修单重复提交网络卡顿导致用户多点了几次提交按钮现象用户在报修表单页连续点了两次提交数据库里出现两条一模一样的报修单。原因前端没有做按钮 loading 状态禁用后端也没有做防重复提交。网络稍慢时用户以为没点成功再次点击两次请求都到达后端两条记录都写进去了。解决前端在请求发出后立即 wx.showLoading 并配合一个 submitting 布尔值在收到回调前屏蔽再次点击。后端在 service 层做幂等性处理可以用数据库的唯一索引也可以接单前先查用户是否有相同描述、相同位置且状态为待受理的单子存在就拒绝。我更推荐前端禁按钮加后端校验双重保障。if (this.data.submitting) return; this.setData({ submitting: true }); wx.showLoading({ title: 提交中 }); // 发起请求5.5 部署到云服务器后静态资源路径全部 404现象本地一切正常把项目上传到某台云服务器跑起来后之前上传的图片全部无法访问控制台报 404。原因Spring Boot 默认不会把本地磁盘下的普通目录当作静态资源目录之前你是在开发工具里通过某些配置或 IDE 的默认行为正常访问的但到了新环境里没有生效。解决写一个 WebMvcConfigurer 配置类把上传文件的存储目录注册成资源映射。Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceLocations(file: uploadDir); } }这里 uploadDir 建议从 application.yml 里读取不要写死这样不同环境下部署都方便。另外正文中加图文混排时保证数据库里存的图片 URL 是以 /images/ 开头别在数据里存全地址否则换环境域名一改全部失效。6. 演示数据与答辩技巧把代码变成能讲清楚的毕业设计报修单的数据要覆盖多种状态管理员入口和维修工入口都需要可演示的素材。我给初始化脚本的建议是造 8 到 10 条单子至少包含三种状态各两条、已完成一条且带评价数据、已取消一条这样演示时每个页面都有内容可展示。设备名称写成某个高校实验室常见的名字更贴合场景。造数据的 SQL 用 INSERT 直接写死在 init.sql 里保证任何环境导入后都能复现演示效果。答辩演示时我个人的习惯是按照这个顺序走先打开数据库看表结构展示数据字段和几条不同状态的数据把数据模型讲清楚然后启动后端展示接口文档或在浏览器里访问 Swagger 界面再打开小程序模拟器演示普通用户从注册登录到提交报修中间拍一张照片上传接着切到维修工角色接受任务处理完成后由普通用户确认并评价最后打开管理后台或统计接口展示不同状态的数量统计结果。整个过程 4 到 5 分钟紧凑但不乱。有一个细节很多人会忽略答辩前把后端接口的超时时间调大一点或者确认一下你演示时用的云服务器带宽。我见过不少同学演示到上传图片那一步卡住 1 分钟没反应现场直接冷场。你把超时时间设置在 30 秒而且提前把图片准备好演示时优先选择相册上传安全性更高、速度也快。代码层面把 service 层的方法注释写清楚每个方法标注业务逻辑说明。不要光依赖类名和函数名答辩评委不一定会翻开你的代码看但一旦翻了看到注释清晰会明显加分。在 README 里写清启动步骤从数据库导入到后端启动再到小程序导入全过程。这份 README 将来也是你论文附录的一部分。写到这里希望帮到你这也是我做完几个类似毕设项目后最想分享的路径。本文还有配套的精品资源点击获取