不知道你有没有答过这类题：电脑蓝屏了，维修师傅问你故障描述，你只会说“就是开不了机啊”。而对面报修平台还要你填品牌、型号、购买日期、是否在保……用户烦、客服也烦。去年我做阳光电脑公司的维修服务小程序时，核心目标就是把“报修”这件事做成微信里点几下就能发起、工程师手机端抢单、后台全程跟踪的一套闭环。项目用的是微信小程序 + SSM（Spring、SpringMVC、MyBatis），前后端分离又不完全分离——小程序端负责用户和工程师操作，管理后台用传统网页，SSM负责所有接口和业务逻辑。这篇文章就把整个项目从需求拆解、技术选型、数据库设计到接口实现和踩坑记录完整讲一遍，给正在做同类毕设或者接私活的朋友做一个参考。
很多同学一听到“SSM”就觉得是老古董，但真做下来你会发现，SSM 的配置虽然是硬骨头，恰恰是这部分最锻炼人。小程序那边同样有不少坑：手机号获取新规、订阅消息授权、request 合法域名、自定义导航栏高度……我把这些坑都填平了，接下来按实际开发顺序给你捋一遍。
1. 项目定位与需求拆解
1.1 电脑维修服务场景的三个角色
阳光电脑公司本质上是一个本地化的 3C 维修服务商，业务包括台式机故障检修、笔记本清灰、系统重装、数据恢复、屏幕更换这类常见项目。这类公司做维修服务小程序，和纯电商、纯内容类小程序的差异非常大——它是“服务+预约+支付”的混合形态。
先说角色。系统里有三类人：用户（普通客户）、维修工程师（接单员）、管理员（公司运营人员）。用户在小程序端提交故障描述、选服务类型、预约上门时间，工程师在小程序端查看工单池、抢单、更新维修进度、填写维修结果，管理员在公司后台维护服务项目、管理工程师、审核订单、看营收统计。
这个三角色模型听起来普通，但真正的业务难点在“工单状态流转”。维修订单不是电商订单那样“下单→付款→发货→收货”一气呵成，它中间有冗长的人工环节：待接单、待上门、维修中、待支付、已完成、已取消、退款中。状态一多，接口设计就容易失控。
1.2 功能需求清单拆解
按模块细分，项目主要包含以下功能点：
- 用户端：微信登录、获取手机号、服务分类浏览、提交报修单、查看订单进度、在线支付/模拟支付、评价、取消订单、个人中心。
- 工程师端：抢单大厅、我的工单、工单状态流转（接单、开始维修、完成）、查看订单详情、修改个人信息。
- 管理后台：服务项目管理、工程师账号管理、订单管理、统计报表、公告管理。
这些功能里，最容易做糊的是“订单进度”和“工程师抢单”。很多同学把订单表当成一个静态表，只在第一次写入时记录数据，后续所有变更都靠 update 硬改，最后页面呈现就变得一塌糊涂。我建议从一开始就引入“状态机思维”，后面接口设计部分会细讲。
2. 技术选型：为什么还是微信小程序 + SSM
2.1 小程序端选型的现实理由
前端选微信小程序而不是 H5、App，原因很直接：客群在线上的时间已经锁定在微信里，维修这种低频刚需服务，让人下载一个 App 基本不可能。小程序扫码即用、用完即走，还自带微信支付和订阅消息能力，省去了一堆账号体系的建设成本。
小程序端技术栈就是原生微信小程序加 WeUI 风格组件，没有引入 Vant Weapp 这类第三方库。为什么不用？一个是项目工期紧，原生组件在真机上的稳定性足够；另一个是毕设或课程设计场景下，原生小程序的代码结构更容易向面试官讲清楚：页面、组件、自定义事件、数据绑定这些概念都一目了然。后面如果要用 uni-app 搞多端，再迁移也不晚。
2.2 SSM 是不是已经过时了？我的看法
后端选 SSM，确实有“教学惯性”的因素。Spring + SpringMVC + MyBatis 这套组合在 2015 年前后基本是国内 Java 后端事实标准，但现在新项目大多是 Spring Boot。那为什么还要用？
第一，SSM 的配置方式是理解 Spring IoC 和 AOP 的最佳教材。你手动维护 applicationContext.xml、spring-mvc.xml，手动配数据源、事务管理器、Mapper 扫描路径，整个过程会逼你把“容器”这个概念彻底搞明白。Spring Boot 的自动配置把这些都藏起来了，你反而容易变成一个只会写注解的工具人。
第二，很多高校的毕设题目还停留在 SSM 阶段，这类项目文档、代码查重、可解释性都做得更成熟。你已经会 SSM 了，再转 Spring Boot 只需要半个月的适应期，反过来先学 Boot 再回去啃 SSM 反而更痛苦。
第三，实际开发中我仍然用 SSM 打底，只不过做了一点“现代化”改造：Mapper 层用 MyBatis 注解 + XML 结合，Controller 层统一返回 JSON，数据库连接池换成 Druid。这套组合在本地 Tomcat 上跑得非常稳，内存占用小，启动快，适合这种中小型服务系统。
2.3 微信登录与手机号获取的新规则
这个必须单独说，因为 2023 年到 2024 年微信侧更新特别频繁，网上很多旧教程还在用老代码，直接抄会翻车。
现在标准流程是：小程序端wx.login()拿 code，后端拿 code 调code2Session接口换取 openid 和 session_key；用户手机号必须通过“手机号快速验证组件”获取，也就是<button open-type="getPhoneNumber" bindgetphonenumber="getPhoneNumber">这种方式，后端收到 code 后再调用接口换取真实手机号。
这里有几个致命细节：使用手机号快速验证组件要求小程序主体为企业、政府或其他组织，个人开发者小程序是不能用的；如果只是毕设演示，官方推荐用测试号，但测试号没有 real 手机号能力，只能用固定测试手机号模拟。我项目里的处理方式是：正常走完整流程，同时写了一个“演示模式开关”，后端配置常量控制返回模拟手机号，这样就不至于在答辩现场被微信的资质校验卡住。
3. 数据库设计与接口实现
3.1 核心表结构设计
这个项目的表不复杂，但有几张表必须设计对，否则后面业务逻辑全是补丁。我的主要表如下：
- user：用户表，字段包括 openid、unionid、nickname、avatar、phone、status。
- engineer：工程师表，包含 name、phone、service_area、work_status（空闲/忙碌）、score、order_count。
- service_item：服务项目表，包含 item_name、price、price_unit、cover_url、description、sort。
- repair_order：维修工单主表，这是核心中的核心。
- order_status_log：订单状态流转日志。
- comment：评价表。
- admin：后台管理员表。
repair_order 表的字段我列一下重点：order_no（业务单号）、user_id、engineer_id、service_item_id、fault_description、address、contact_name、contact_phone、expect_time、status、pay_status、pay_amount、cancel_reason、create_time、update_time、finish_time。
order_status_log 很多人容易漏掉。有了这张表，你可以随时追溯一个工单从“待接单”到“已完成”全部节点的时间线，后台展示和故障排查都方便得多。强烈建议任何状态流转业务都配一张日志表，别嫌麻烦。
3.2 统一返回结构和接口设计
SSM 项目接口设计最忌讳的就是 Controller 里到处Map<String, Object>乱塞数据。我这里定义了一个通用结果类Result，字段就三个：code、msg、data。约定 code=200 为成功，400 参数错误，401 未登录，500 系统异常。
public class Result<T> { private Integer code; private String msg; private T data; // 省略 getter/setter 和静态工厂方法 success()/error() }前端小程序里封装了一个request函数，所有请求统一走它，成功时判断 code 再取 data，失败弹 toast。这样就把重复的错误处理收敛到了一处，后续新增接口时 Controller 层代码量非常小。
对于列表接口，统一用 PageHelper 做分页。小程序端做“加载更多”时，页码从 0 开始，每次传 pageSize（一般 10 条），后端返回PageInfo，包含 list、total、pageNum、pages。有一个小坑：PageHelper 的分页参数是线程绑定的，用完后一定要在执行 SQL 前设置，而且不能用它包非查询语句，否则分页会串台。
3.3 工单状态机的设计
工单状态我一开始是用硬编码：Service 层写一堆if (order.getStatus() == 1) { ... }，后面发现根本维护不了。后来改成“状态机校验”。
状态机的逻辑是：每个状态只允许跳到特定的下一个状态，其他跳转直接抛异常。比如待接单只能跳“已取消”或“已接单”；维修中只能跳“待支付”；待支付只能跳“已完成”或“退款中（取消）”。
public enum OrderStatus { WAITING_ACCEPT(0, "待接单"), ACCEPTED(1, "待上门"), REPAIRING(2, "维修中"), WAITING_PAY(3, "待支付"), FINISHED(4, "已完成"), CANCELLED(5, "已取消"), REFUNDING(6, "退款中"); }每次状态变更就是一个独立的方法，比如acceptOrder(Long orderId, Long engineerId)、startRepair(...)、finishRepair(...)。方法内部第一步锁行，第二步校验当前状态是否等于允许的前置状态，第三步更新状态并写日志。这套设计让整个系统的状态流转可控，也不容易出脏数据。
4. 关键功能实现：从用户报修到订单闭环
4.1 用户端报修流程与页面数据绑定
用户报修是整个流程的入口，体验必须顺。报修页分了三个区块：服务类型选择、故障描述和照片上传、联系方式和上门地址。服务类型从后端接口动态加载，渲染成单选框列表，避免因为新增服务项目改代码。
故障照片上传用的是微信小程序的wx.chooseMedia，拿到临时路径后先调wx.uploadFile传给后端，后端用 MultipartFile 接收并写入服务器本地目录，返回一个 URL 存到订单表里。这里要注意，本地存储文件有个问题：没有做域名绑定，生产环境图片 URL 访问的是 IP 加端口，小程序端image组件的 src 必须用后台配置的域名做合法域名绑定后才能正常显示。如果不处理，就会出现“后台能看见图、小程序里图片裂开”的诡异现象。
地址那块，为了让用户少打字，直接接了wx.chooseLocation选择位置，反填经纬度和详细地址。这个 API 需要在小程序后台申请“地理位置”接口权限，属于用户隐私接口，提交代码审核时要在后台填清楚使用场景说明，否则会被驳回。这是很多新手容易卡住的地方。
4.2 工程师抢单与并发控制
抢单是高频并发场景，多工程师同时点“接单”时，一个工单不能被两个人抢走。最简单可靠的方案是用条件更新配合影响行数判断：
UPDATE repair_order SET engineer_id = #{engineerId}, status = 1 WHERE id = #{orderId} AND status = 0 AND engineer_id IS NULL用 MyBatis 执行这条 SQL 后，如果返回影响行数为 1，表示抢单成功；返回 0，说明订单已被抢走或者状态已经变化，直接提示“手慢了”。
这个方案足够应对中小型公司的实际并发量，不需要引入 Redis 分布式锁。如果你觉得还不够，可以在 Service 层方法加@Transactional配合SELECT ... FOR UPDATE锁行，但要注意锁的粒度，别把整个表锁了。抢单成功后，要把工程师的work_status改成忙碌，并推送一条订阅消息给用户，告诉 TA 已经有人接单。
4.3 微信支付与订阅消息的取舍
微信支付这一块，很多毕设项目都容易掉进坑里：个人主体的小程序根本没有开通微信支付的资质。即使公司主体能开通，签约、提现、证书配置的流程也会耗掉大把时间。我的处理是做一个可配置的“模拟支付”开关，开关打开时用户点击“去支付”按钮直接调本地模拟接口，后端把订单状态改成已支付、记录模拟支付流水号。答辩时可能被问到为什么不接真支付，就说清楚域名证书、商户号资质限制，以及模拟支付如何确保流程完整性，这就够了。
订阅消息则是真真切切用上了。维修服务与外卖、快递类似，用户需要实时知道“工程师已接单”“工程师正在路上”，所以我在关键节点嵌入了订阅消息推送。需要注意微信的规则：目前订阅消息是一次性订阅，也就是后端要拿到用户点击“允许订阅”后的授权记录，才能向用户推送一次消息。我的做法是在用户提交报修成功后弹出订阅请求，上一次授权对应一次推送，绝对不能在用户没授权时硬推，否则 API 会报 43101，用户也可能直接投诉。
5. SSM 配置与小程序对接中的常见坑
5.1 合法域名与 request 请求失败
小程序真机调后端接口，绕不开“合法域名”问题。开发工具里可以勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”来跳过，但手机预览时必须使用 HTTPS 且域名已备案并在小程序后台配置为 request 合法域名。
我用的是阿里云服务器加 Nginx 做反向代理。后端 Tomcat 跑 8080 端口，Nginx 把https://api.demo.com/api/开头的请求转发到本机 8080，这样小程序只和域名通信，后端 IP 和端口变化也不用改小程序代码。SSL 证书用的 Let’s Encrypt，三个月一续，配合定时任务自动续期。如果没有域名，短期在本地用花生壳做内网穿透也凑合，但只适合联调。
5.2 拦截器放行与 CORS 跨域问题
SSM 的小程序接口用拦截器实现登录校验：前端每次请求在 header 里带 token，拦截器里放行/api/login、/api/sms等白名单路径，其余接口取 token 校验，失效抛 401。这里最容易踩的坑是：静态资源和图片访问也被拦截器拦截。记得在 spring-mvc.xml 里配置<mvc:resources mapping="/upload/**" location="/upload/" />，并且拦截器滤掉/upload/**和静态文件后缀。
管理后台是普通网页，部署在另一台端口，访问后端接口必然产生跨域。我在 Controller 上用一个全局CorsFilter，配置允许来源、允许方法、允许 header。注意Access-Control-Allow-Origin不要随手写*，如果涉及携带 token 的请求，浏览器不允许 origin 为*且携带Authorizationheader，必须显式指定域名。
5.3 小程序顶部导航栏高度与自定义导航
这个小坑确实折磨了很多新手。微信小程序的胶囊按钮（右上角那三个点）高度在不同机型、不同系统版本下不一样，自定义导航栏时如果硬编码一个 padding-top，iPhone 和 Android 上就会错位。
处理方式是读取系统信息里的statusBarHeight和menuButtonBoundingClientRect.top，动态计算导航栏高度。我当时在 app.js 里封装了一个全局方法，所有自定义导航栏页面统一调用：
const systemInfo = wx.getSystemInfoSync(); const menuButton = wx.getMenuButtonBoundingClientRect(); globalData.navBarHeight = menuButton.bottom + menuButton.top - systemInfo.statusBarHeight;这样不管刘海屏还是普通屏，布局都不会乱。真机调试时多准备几台不同厂商的手机试一下，你会感谢这个封装的。
5.4 并发抢单时的数据库行锁测试
抢单接口上线前一定要压测。我本地用 JMeter 模拟 50 个并发线程同时抢同一个订单，一开始代码没加条件更新，用的“先查后改”逻辑，结果 50 个请求全部“抢单成功”，订单被 50 个工程师同时持有。后来改成条件更新加事务，行锁生效，50 个请求里只有 1 个返回成功、其余都返回失败，效果符合预期。这种问题在联调阶段不暴露，一上线就完蛋。
关于事务还有一个细节：@Transactional默认遇到 RuntimeException 才回滚，如果 Service 方法里抛出的是普通 Exception，事务不会自动回滚。抢单失败后我是主动抛RuntimeException来触发回滚，这比在方法里手动transactionManager.rollback()干净得多。
6. 整理文档和源码时的经验之谈
这个项目的题目带“文档+源码”，说明交付物里不只代码，还要有完整的项目文档。做过几次类似交付后我的体会是：文档别最后写，边做边写。
项目文档至少要包含：需求规格说明书、数据库设计说明书（含 ER 图）、系统概要设计、详细设计（核心模块时序图、类图）、测试计划与测试报告、操作手册。封面要写清楚“阳光电脑公司维修服务微信小程序系统”，配上《软件工程》的标准模板，详细设计部分把核心接口的请求/响应示例贴上去。很多同学的项目代码不错，但文档只有苍白的功能列表，答辩时老师翻不到关键设计，印象分会拉低不少。
另外源码目录结构也要整理规整：前端小程序目录、后端 SSM 工程目录、数据库初始化脚本 sql、部署文档、演示视频、说明 README。数据库脚本要自己从零跑一遍，确保另一台电脑上导入后不会报错。别偷懒把applicationContext.xml里的数据库密码写死成自己的本地密码，交付时改成通用配置并在文档里注明修改位置。
7. 几个能直接拿走的优化建议
再说几个我实测下来好用的功能优化方向，不涉及核心流程改动，但体验提升很大。
第一个是同步服务进度时间线。用户端订单详情页用order_status_log表渲染一条“历史轨迹”，比如“2025-01-10 09:23 订单已提交”“09:40 工程师张三已接单”“10:15 工程师已上门”。这个功能用户非常买账，因为维修这种服务等待感很强，时间线能大幅缓解焦虑，而且实现成本极低，后端查询一条列表，前端几个 view 循环就出来了。
第二个是工程师“空闲”状态自动切换。原来工程师在后台手动改忙碌/空闲，经常忘改，导致用户约到了却没上门。我加了一个定时任务，每天凌晨扫描“维修中”工单数超过 5 个的工程师自动改成忙碌，工单结束且数量少于 3 个自动恢复空闲。虽然简单，但比手动控制靠谱多了。
第三个是评价模块的提醒机制。订单完成后，用户不会主动去评价。我做了“完成订单后 24 小时未评价则系统自动好评”的规则，同时在小程序首页做了“待评价”红点提醒。这个对平台积累口碑很有帮助，不然评价栏一直空的，新用户看着不放心。
第四个是数据看板。管理后台加了一个简单的统计首页，展示今日新增订单、今日营收、各服务项目占比图。技术实现上就是一个聚合查询接口，后端返回几个统计值，前端用 ECharts 画图。注意 ECharts 在小程序里有专门的 ec-canvas 版本，不要直接在原生小程序里引入 web 版，否则一堆兼容问题。
以上是我个人从实际开发中提炼出的内容。联调时遇到过 web-view 上无法打开部分页面，排查到最后是业务域名未配置；还遇到过苹果手机上wx.chooseLocation闪退，原因是基础库版本太低，更新基础库后恢复正常。这些琐碎问题不记下来，过半年再遇到又要重新踩一遍。项目做完了，回看整个流程，真正有意义的部分不是代码量有多庞大，而是通过这个小而完整的系统，把微信生态的账号体系、支付逻辑、消息推送和后端 MVC 框架、数据库事务、状态机设计全部打通了一遍。有了这套底子，以后接手任何“小程序加后台管理”的项目，你都会知道第一步该做什么，第一步做完后大概率会在哪个坑里等坑。
