1. 项目是做什么的一张维修工单的生命周期接手“阳光电脑公司的维修服务微信小程序 SSM文档源码”这样一个项目我第一反应是这不就是典型的“小程序做前端触达Java 做后台业务”的毕业设计/课程设计工程嘛。真正把文档和源码工程跑起来之后你会发现它比想象中更贴近中小型维修门店的线上化需求用户不用再翻通讯录打电话直接在微信里提交故障类型、上传故障照片后台接待员再按维修类型派给师傅师傅完工后录入维修明细和费用用户确认后可以评价。整个流程闭环管理者也能看到每台设备的维修历史和收费情况。这个项目适合三类人参考一类是正在做微信小程序 后端选题的学生一类是想拿现成源码做二次开发的个人开发者还有一类是想把维修店从“电话报修 纸质记录”升级成系统化管理的小老板。它不是什么高并发高可用的互联网产品而是一个结构清楚、能跑通核心业务的典型业务系统。理解它之后你可以非常自然地把这套逻辑迁移到家政服务、设备巡检、预约上门等更多场景里。1.1 三个角色三条诉求这类维修系统的核心不是“前端页面好看”而是把一团乱麻的维修流程理清楚。围绕一张维修单系统里实际上有三个角色每个角色关心的事情完全不同角色最关心的事在系统中的职责普通用户报修方便、进度可查、价格透明微信登录、填写故障信息、查看工单、评价售后客服/管理员不漏单、能派给合适的师傅审核新单、派单、调整报价、统计汇总维修工程师今天有几单、故障是什么、怎么收费查看任务列表、更新维修状态、填写维修明细三个角色听起来简单但很多做得不好的系统恰恰是把它们混在一个后台里用户和师傅共用一套界面结果就是角色权限含糊、数据容易串。阳光电脑这个项目里小程序端主要面向普通用户和上门维修师傅后台管理端面向管理员/客服这种“端”的分离在业务上是非常合理的。1.2 核心流程报修、派单、维修、确认、评价系统的主线是一张维修工单它的状态流转大概是这样用户在小程序里提交报修单填写联系人、联系电话、电脑型号、故障描述上传故障照片系统生成一条状态为“待派单”的订单。管理员在后台看到新订单根据故障类型和师傅技能把订单派给某个维修工程师状态变为“已派单”。工程师联系用户或上门后更新订单状态为“维修中”完工后在系统里填写维修明细包括人工费、配件费、检测结果。用户在小程序里看到维修结果和费用确认无误后点击“确认完成”订单状态变为“已完成”。用户可以对本次服务打分、写评价整个闭环结束。这里最关键的一张表就是维修订单表订单状态字段驱动了整个流程。我见过一些项目为了省事把状态设计成“0未派单、1已完成”中间过程全靠用户和客服在微信里自己沟通这样的系统做出来其实只是个“记录台账”没有真正起到管理的作用。阳光电脑这个项目里状态字段一般会做得更细0待派单、1已派单、2维修中、3待确认、4已完成、5已取消。每个状态背后都有对应操作人和时间出了问题可以追溯。电脑维修还有一个比较特殊的地方故障往往不是下单时就能说清的可能上门拆机之后才发现配件问题所以订单里需要预留“实际维修明细”的字段区域并且支持修改费用。这个点上维修单的设计不能太死板不能一开始就把费用锁死。2. 为什么选微信小程序 SSM技术选型背后的权衡很多人在看这类标题时第一反应是“微信小程序”四个字很新而“SSM”三个字很旧新旧搭配是不是有点怪实际上这是一个非常成熟的组合尤其是对于业务系统类的选题来说它兼顾了“前端体验”和“后端分层清晰”两个诉求。2.1 微信小程序解决了什么微信小程序对维修服务场景最大的价值是解决了“用户不愿意为了一个低频业务专门下载App”的问题。一个普通人可能一年才修一次电脑让他为此装App完全不现实但在微信里随手打开一个小程序用完就走这个心理门槛就低很多。而且维修业务天然带社交属性家里电脑坏了同事朋友会互相推荐小程序转给微信好友直接就能打开比发一个App下载链接顺畅得多。小程序端另一个不可忽视的能力是“手机号快捷登录”。传统网页要做用户体系通常要用户注册账号、设置密码烦人且容易忘记。微信小程序可以直接调用微信授权能力用户点一下按钮系统就能拿到微信身份和手机号免去输密码的环节。这个能力对中小型门店尤其实用因为客服后续需要电话联系用户手机号几乎是刚需。当然微信小程序也不是没有代价。它受微信平台规则约束所有请求域名必须备案且在小程序后台配置合法域名开发阶段还经常要处理“真机请求失败”的问题。不过这些问题相比它带来的传播优势和开发效率仍然是值得的。2.2 SSM 在 Java 后端里的位置SSM 是 Spring SpringMVC MyBatis 三个框架的组合曾经是 Java Web 开发的绝对主流现在虽然被 Spring Boot 抢了很多风头但它在教学、毕业设计和存量系统里依然大量存在。用 SSM 做这个项目的后端有非常现实的原因分层清楚、资料多、答辩容易讲。SSM 的三层结构可以这样理解Controller 层负责接收小程序发来的 HTTP 请求Service 层负责处理业务逻辑Mapper 层负责操作数据库。比如用户提交报修单小程序把 JSON 发到 ControllerController 调用 Service 保存订单Service 内部调用 Mapper 的 insert 语句把数据写入 MySQL。每一层各管各的事出了问题也容易定位。在 SSM 项目里有五个常用注解基本绕不开Controller标记这是控制器RequestMapping声明接口路径和请求方式ResponseBody表示把 Java 对象序列化成 JSON 返回给前端RequestBody接收前端传过来的 JSON 并转成 Java 对象Autowired让 Spring 自动注入依赖。如果后端某个接口涉及到多张表同时操作还会用Transactional保证事务一致性。注解作用小程序对接时对应的场景Controller标记一个类是控制器处理 /api/order/add 之类的请求RequestMapping映射 URL 地址通过路径区分不同业务ResponseBody返回 JSON 给前端小程序拿到 {code,msg,data}RequestBody读取请求体并转成对象接收小程序 post 上来的订单数据Autowired自动注入 Service/Mapper不用手动 new 对象如果你单纯从“快速上线商用系统”的角度看我会建议用 Spring Boot MyBatis-Plus因为它配置更少、开发更快。但如果你做的是课程设计或者毕业设计传统的 SSM 反而更容易在论文里展开因为每个配置文件的每行配置都可以写进“系统实现”章节Spring Boot 自动配置太多反而没什么好写的。2.3 环境版本怎么搭配SSM 项目对环境比较敏感版本不对很容易出现莫名其妙的问题。这里给一套我实测下来最稳的组合组件推荐版本说明JDK1.8主流 SSM 源码基本都基于 JDK8Maven3.6.3用来管理依赖和打包Tomcat8.5 / 9.0老项目不要直接用 Tomcat 10包路径不兼容MySQL5.7兼容性最好很多 SQL 脚本默认用 5.7 语法微信开发者工具稳定版调试小程序前端很多“文档源码”工程会在压缩包里附带 SQL 脚本但没写 MySQL 版本。强烈建议先看 SQL 脚本再建库如果里面有ENGINEInnoDB DEFAULT CHARSETutf8这种写法用 5.7 或 8.0 都能跑如果用了DEFAULT CHARSETutf8mb4数据库本身也要把字符集设置成 utf8mb4否则中文会乱码。MySQL 8 也能连但要把 JDBC 驱动改成com.mysql.cj.jdbc.Driver并且在数据库连接地址上加上serverTimezoneAsia/Shanghai。3. 数据库设计与后端接口让每张维修单都有迹可循这个项目的后端核心其实不是那几个框架的配置而是数据库表设计。维修行业最怕的就是“责任说不清、费用对不上”。如果数据库里连维修明细都没有用户说“你们乱收费”时商家一点证据拿不出来。所以阳光电脑项目的表结构必须能支撑一条清晰的业务链路。3.1 核心表结构与字段含义最核心的一定是维修订单表我在这里给出一个常见的结构CREATE TABLE repair_order ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单编号, user_id INT NOT NULL COMMENT 下单用户ID, contact_name VARCHAR(50) NOT NULL COMMENT 联系人, contact_phone VARCHAR(20) NOT NULL COMMENT 联系电话, device_type VARCHAR(50) COMMENT 电脑类型/型号, fault_desc VARCHAR(500) COMMENT 故障描述, images VARCHAR(1000) COMMENT 故障图片URL逗号分隔, engineer_id INT COMMENT 维修工程师ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待派单 1已派单 2维修中 3待确认 4已完成 5已取消, estimate_cost DECIMAL(10,2) COMMENT 预计费用, final_cost DECIMAL(10,2) COMMENT 实际费用, appointment_time DATETIME COMMENT 预约时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );这个表里有两个字段值得多说几句。第一个是order_no也就是订单编号。不要直接用自增 ID 当业务编号给用户看因为自增 ID 容易被猜到比如今天下了 5 单明天别人就能猜到你的业务量。更合理的方式是在后端生成一个看起来像 “XG2025010110001” 的编号规则可以是“前缀 日期 自增序号”。第二个是images字段。很多学生项目会把上传图片的地址直接存在订单表里用逗号分隔多个 URL。这种设计对一个小型维修系统来说足够因为一个订单故障照片通常也就是三四张单独建一张图片表反而让接单逻辑复杂化。但如果后续要做“图片放大预览”“图片数量动态调整”还是要单独拆一张order_image表把一对多关系规范化。除了订单表还需要三张基础表用户表、工程师表、维修明细表。用户表存微信 openid、手机号、昵称、头像工程师表存姓名、电话、技能标签、当日任务数维修明细表存配件名称、数量、单价、人工费。维修明细表非常关键因为它解决了费用透明问题用户在小程序端看到每一项收费的来源而不是只有一个总价。3.2 后端接口清单SSM 后端给小程序提供的接口我整理成一张清单照着这个清单去对源码基本就能把项目脉络捋清楚接口路径方法功能说明/api/user/loginPOST微信登录获取 openid 和手机号创建/更新用户/api/user/infoGET查询当前登录用户信息/api/order/addPOST用户提交报修单/api/order/myGET查询当前用户的维修订单列表分页/api/order/detailGET查询订单详情/api/order/cancelPOST用户取消未接单的订单/api/order/confirmPOST用户确认维修完成/api/order/commentPOST用户提交评价/api/engineer/listGET管理员查询工程师列表/api/engineer/finishPOST工程师填写维修结果/api/admin/order/pageGET管理员分页查询所有订单接口返回统一 JSON 格式{code: 0, msg: success, data: {...}}。小程序端可以封装一个request工具函数全局判断 code 值code 不为 0 时弹出错误提示。这套格式虽然简单但在 SSM 这种手动序列化的项目里非常实用避免每个接口返回风格不一致。3.3 小程序登录的后端逻辑小程序端登录和后端接口是绑定在一起的这也是微信小程序项目里最容易出问题的地方。完整逻辑是小程序先调用wx.login()拿到临时 code再把这个 code 传给后端后端拿着 code 调用微信的code2Session接口换回 openid 和 session_key。后端拿 openid 去数据库查用户存不存在不存在就自动注册存在就直接登录。整个过程用户是无感知的这是“微信登录”的实现基础。至于“微信小程序登录获取手机号”现在的新版接口更简单。小程序端用一个open-typegetPhoneNumber的按钮用户点击授权后回调事件里能拿到一个动态 code把这个 code 传给后端后端再调微信接口换手机号。老版本常用的encryptedData iv解密方式现在仍然有项目在用但新工程建议直接用动态 code代码更简单也不容易踩解密失败的坑。如果项目里没有引入 Redis 存 token最简单可行的方案是在用户表里加一个token字段登录成功后生成一个 UUID 字符串存进数据库同时返回给小程序。小程序每次请求都把 token 放在请求头里后端通过拦截器校验 token再根据 token 反查用户。这个方案虽然不如 Redis 优雅但胜在好理解和好实现放在毕业设计里也完全站得住脚。4. 小程序端核心页面从手机号登录到服务评价小程序端是这个项目递给用户的门面。很多 SSM 后端项目的小程序端只有简单的页面跳转但阳光电脑这种项目如果把页面做好体验完全不一样。小程序端通常分为首页、报修页、工单列表页、详情页、我的页面五个主要页面。4.1 页面结构与页面配置在微信开发者工具里新建项目后pages 目录下每个页面由四个文件组成.wxml负责结构、.wxss负责样式、.js负责逻辑、.json负责页面配置。全局的app.json可以配置页面路径和窗口样式{ pages: [ pages/index/index, pages/order/add, pages/order/my, pages/order/detail, pages/user/user ], window: { navigationBarTitleText: 阳光电脑维修, navigationBarBackgroundColor: #1b6de3, navigationBarTextStyle: white } }navigationBarTitleText 就是顶部导航栏中间显示的文字也就是“微信小程序顶部导航栏高度”这个问题里最基础的部分。默认导航栏由微信系统渲染字体、返回按钮都是固定的开发者只需要设置标题和背景色即可。如果你需要让自定义头部和官方搜索框对齐那就必须通过下面要讲的胶囊按钮位置来计算。4.2 手机号快捷登录怎么写登录页是小程序端最关键的页面。使用微信手机号快捷登录时WXML 里可以这样写button classlogin-btn open-typegetPhoneNumber bindgetphonenumberonGetPhoneNumber 微信手机号一键登录 /button对应的 js 逻辑onGetPhoneNumber(e) { if (e.detail.errMsg ! getPhoneNumber:ok) { wx.showToast({ title: 未授权手机号, icon: none }); return; } const phoneCode e.detail.code; wx.login({ success: (res) { this.loginRequest(res.code, phoneCode); } }); }, async loginRequest(code, phoneCode) { const res await request({ url: /api/user/login, method: POST, data: { code, phoneCode } }); if (res.code 0) { wx.setStorageSync(token, res.data.token); wx.setStorageSync(userInfo, res.data.userInfo); wx.navigateBack(); } }这里要特别留意一点wx.login()的 code 和getPhoneNumber返回的 code 是两个不同的东西一个是用于换取 openid 的一个是用于换取手机号的后端接口要分别处理。很多同学在这里直接把 phoneCode 传去调 code2Session结果拿不到手机号就是这个原因。4.3 维修单列表与上拉加载更多维修单列表是小程序端使用频率最高的页面。这里最常见的需求是“微信小程序页面列表加载更多”也就是用户下拉到底部时自动加载下一页数据。这个逻辑本身不复杂难的是做好防重复请求。一个比较稳定的做法是页面 data 里存page、loading、hasMore三个状态每次请求前先判断是否正在加载如果正在加载就直接 return请求完成后把当前页数据追加到 list 尾部同时把 page 加 1。在页面 json 里开启enablePullDownRefresh: true支持下拉刷新再用小程序自带的onReachBottom监听触底data: { list: [], page: 1, size: 10, loading: false, hasMore: true }, async loadList() { if (this.data.loading || !this.data.hasMore) return; this.setData({ loading: true }); const res await request({ url: /api/order/my, data: { page: this.data.page, size: this.data.size } }); const newList this.data.list.concat(res.data.list); this.setData({ list: newList, hasMore: res.data.currentPage res.data.totalPages, page: this.data.page 1, loading: false }); }, onReachBottom() { this.loadList(); }列表页还有一个体验细节每张维修单卡片上要明显显示“待派单 / 维修中 / 待确认 / 已完成”等状态颜色尽量区分。用户最关心的是“我的电脑到底修好了没”状态一眼可见比什么都重要。4.4 自定义导航栏高度的问题默认情况下微信小程序顶部导航栏是系统生成的高度在不同机型上不一致开发者不需要自己处理。但如果你希望页面头部更美观把导航栏设置为自定义模式就需要获取胶囊按钮位置和状态栏高度来动态计算导航栏高度。const systemInfo wx.getWindowInfo(); const menuRect wx.getMenuButtonBoundingClientRect(); const navBarHeight (menuRect.top - systemInfo.statusBarHeight) * 2 menuRect.height;这段公式的逻辑是胶囊按钮顶部到状态栏底部的距离乘以 2再加上胶囊自身高度就得到自定义导航栏完整高度。这样算出来的高度能保证导航栏里的标题和官方胶囊按钮垂直居中。如果你只是做普通的毕业设计我其实不建议用自定义导航栏默认导航栏省事且稳定把精力放到业务功能上更划算。5. 从源码到可运行部署、跑通与排查实录拿到“文档源码”工程之后最容易出现的误区是直接双击后端源码就想跑。实际上这类项目至少要过五关建库导数据、改配置、启动后端、启动小程序、调通接口。下面这份顺序是我实际跑项目时总结出来的照着走会顺畅很多。5.1 拿到“文档源码”后的处理顺序先解压源码包不要急着用 IDEA 打开。先在压缩包里找到两个关键东西SQL 脚本和 README 文档。SQL 脚本通常在doc目录下文件名可能是sunshine_pc.sql或db.sql。打开看一下里面有哪几张表然后在 MySQL 里新建一个数据库导入脚本。注意导入不要直接双击 .sql 文件建议命令行为mysql -uroot -p create database sunshine_pc default character set utf8mb4; use sunshine_pc; source /解压目录/sunshine_pc.sql;导入成功后用 IDEA 打开后端 Maven 工程等待依赖下载完成。然后重点修改三个配置文件jdbc.properties里的数据库账号密码、log4j.properties里的日志级别、小程序端utils/config.js里的 request 地址。如果后端部署在 Tomcat 下并且 context path 是根路径接口地址就是http://localhost:8080/api/...如果带项目名就需要写成http://localhost:8080/sunshine_pc/api/...这是接口 404 最常见的原因之一。后端启动之前记得检查 Maven 依赖是否完整。老 SSM 项目用的依赖版本都比较旧如果你的 Maven 仓库没有对应版本会显示红条。最稳妥的方式是看源码里的pom.xml把版本号复制到 Maven 中央仓库搜索确认依赖确实存在再重新导入工程。5.2 典型问题速查表我在跑通这类项目时把高频问题整理成了一张速查表基本上覆盖了 90% 的异常场景现象可能原因处理建议小程序请求后端返回 404baseUrl 少了项目 context path用浏览器先访问后端接口地址确认路径真机调试请求失败工具却正常真机访问不到 localhost改成电脑局域网 IP并让手机和电脑同一 WiFi数据库中文乱码jdbc 连接没指定 utf8URL 加characterEncodingutf8手机号登录拿不到用户信息测试号不支持 getPhoneNumber换成已认证的小程序 AppID列表重复加载没有 loading 防重参照上面 loadList 加 loading 判断Tomcat 启动失败端口被占用或 JDK 版本不对检查 8080 端口确认用 JDK8 启动MySQL 连接失败驱动版本不匹配老项目用 5.1.x 驱动MySQL8 要换驱动包这里面最值得说的是真机调试问题。小程序工具里请求 localhost 能通是因为开发者工具相当于跑在电脑上的模拟环境真机是另一台手机它不可能通过localhost访问到你电脑上的 Tomcat。所以在真机调试时要改用局域网 IP同时保证手机和电脑在同一网络下。开发阶段可以在微信开发者工具右上角“详情 - 本地设置”里勾选“不校验合法域名”这样能省掉域名配置的麻烦正式上线则必须在微信公众平台配置 request 合法域名而且域名必须备案。5.3 我自己踩过的一个坑这个项目里最容易让人忽略的是图片上传的路径问题。报修时要上传故障照片通常小程序端用wx.chooseMedia选图然后通过wx.uploadFile上传到后端的/api/upload接口。后台上传成功后会返回一个图片 URL小程序端拿这个 URL 去展示图片。看起来很简单但如果你在后端把图片存到了 Tomcat 的某个磁盘目录然后在返回结果里写死了一个http://localhost:8080/upload/xxx.jpg给前端在开发者工具里能看到图片换到真机上就会裂开因为真机根本访问不到你电脑的 localhost。比较稳妥的做法是后端只返回相对路径比如/upload/xxx.jpg小程序端拿到相对路径后自己拼上请求地址的域名部分再来回显图片。这个坑我踩过一次之后所有涉及文件上传的项目都统一改成“相对路径存储 前端拼接域名”再没出过问题。6. 最后再分享一点真实体会我实际跑完这类 SSM 微信小程序项目之后最大的体会是它不够新潮但作为“理解小程序业务系统如何运转”的样本价值非常高。很多人一上来就想着用云开发、用 Serverless、用各种新技术但如果你连一张维修单从用户提交到数据库再从小程序展示的完整链路都讲不清楚换再多新技术也只是堆概念。如果你不是交作业而是真想给维修店上线用我会建议在原有设计上加几个点。第一订单完成后自动生成设备维修档案下次这台电脑再坏直接调出上次的维修记录用户和管理者都会觉得实用。第二派单不要只按顺序派可以按工程师的技能标签来匹配比如修数据恢复的师傅和修主板芯片的师傅不能乱派。第三价格确认流程里加入“到店支付”或“微信支付”选项虽然微信支付需要商户号开通但业务模型上可以让费用结算更完整。说到底一个项目能跑通只是第一步跑通之后还能不能根据真实业务去调整才是把源码变成自己东西的关键。这套维修服务系统的核心逻辑往小里说是一家电脑维修店的订单管理往大里说其实是所有“预约 派工 服务 评价”类业务的通用模板。吃透它之后你会发现后面再看家政服务小程序、上门维修小程序、企业设备巡检小程序思路都是通的。