做毕业设计或者技术练手Java 后端 微信小程序的组合一直是我比较推荐的搭配尤其在电动车充电这类真实业务场景里这套组合能很自然地把用户端、业务端和支付链路串起来。今天要拆的“电动车智能充电服务平台”后端拿 SSMSpring Spring MVC MyBatis做接口服务小程序端承担地图找桩、扫码充电、订单支付这些高频交互。它不是一个只能截图交差的 Demo而是一个能真实跑起来、能答辩、也能写进简历的完整项目。我会从需求拆解、数据库设计、核心接口实现、小程序端页面逻辑、论文组织以及我实际踩过的坑这几个维度完整过一遍。正在做相关课题的同学或者想用一套全栈项目快速打通 SSM 和小程序开发的朋友都可以从里面找到能直接复用的东西。1. 项目全貌与核心需求拆解1.1 充电服务平台到底要解决什么痛点电动车数量上来之后“充电难”就不再只是电池续航的问题而是基础设施和用户习惯之间的匹配问题。用户打开地图找不到充电桩、找到了又不知道是否空闲、充电过程中看不到实时状态、充完电结算方式各异这四件事串起来就是整个平台的业务核心。我做这个项目时第一件事不是写代码而是把用户旅程完整画了一遍人走到停车场打开小程序看到附近空闲桩扫码连接启动充电实时观察功率和金额结束充电后微信支付最后查看历史订单。整个过程听起来很简单但落到系统上就有几个明确的硬需求。第一个需求是充电桩的实时状态管理。一个桩只有三种可见状态——空闲、充电中、异常但背后还牵扯到离线、维护中、被预约等隐藏状态后台必须能区分“用户可见状态”和“真实物理状态”。第二个需求是计费规则要灵活充电订单的金额不能写死按分钟、按度数、按时段优惠都要支持否则换一个运营方就要改一次代码。第三个需求是支付闭环用户在小程序端发起的支付后端必须能收到微信支付回调并正确更新订单状态这一步容不得半点模糊涉及重复回调、掉单补单这些边界情况。想清楚这三个需求后面的表设计和接口设计就有了方向。很多同学一上来就写代码结果做到一半发现字段不够用、接口返回结构对不上都是因为前期没有把业务场景拆透。1.2 为什么选 SSM 小程序这套组合而不是更“新”的技术栈选题时不少同学会纠结市面上已经有一堆微服务、Spring Boot 云原生方案了为什么还要用 SSM我的观点很直接毕业设计和技术练手的首要目标不是追新而是可控、可解释、能够完整闭环。SSM 三个组件的分工逻辑其实非常清晰。Spring 管对象Spring MVC 管请求分发MyBatis 管数据库映射这套框架虽然“老”但它把分层思想训练得特别扎实。Controller 层只做参数接收和结果封装Service 层写业务规则Mapper 层操作数据库三层结构在答辩时讲起来条理分明面试官问到 SSM 常用注解、Bean 生命周期、Mapper 动态 SQL 这些问题也都能拿实际代码来说明这比单纯背八股文强得多。小程序端的选择就更好理解了。它天然解决了“用户为什么愿意装你的 App”这个问题微信扫码即用加上微信支付生态的打通成本极低一个个人主体的小程序配合微信支付商户号就能完成真实的支付闭环。相比开发原生 App 或者 H5 网页小程序在定位、扫码、支付这些核心能力上的开发门槛反而更低页面列表加载、下拉刷新这些基础组件都已经封装好了开发者要关注的核心是业务而不是底层适配。这套组合还有一个隐含优势论文好写。SSM 架构、微信小程序框架、JSON 数据交互、HTTP API 设计每一个点都有成熟的理论基础可以引用写需求分析、系统设计、系统测试这些章节时不会出现“没有理论支撑”的尴尬。2. 数据库设计与接口规划2.1 核心表结构拆解与字段设计数据库是整个项目的压舱石。我见过太多项目最后烂尾不是因为前后端代码难写而是表结构从一开始就设计得不合理。充电服务平台最少需要六张业务表用户表、充电桩表、充电订单表、充值账户表、计费规则表、意见反馈表。用户表的核心字段不用多说openid、昵称、头像、手机号但这里容易犯一个典型错误——把 openid 设置成主键。openid 由微信生成长度 28 位左右理论上唯一且稳定但它本质上是个业务标识不应该承担主键的职责。我用自增 id 作为主键openid 加唯一索引这样后续接入车牌号、会员等级、账户余额这些扩展字段时表结构不会被动摇。充电桩表需要重点设计。每个充电桩的物理位置用经纬度存因为小程序端地图展示、距离排序、附近推荐统统依赖这两个字段。状态字段我建议直接用 tinyint0 空闲、1 充电中、2 故障、3 离线不要用字符串去存“idle”“charging”这类英文单词节省空间是一方面更重要的是代码里用枚举做映射时更直观。充电桩和充电枪的映射关系也一定要提前考虑一个桩可能有多个枪订单要记录到枪级否则同时充电的人数一多桩状态和订单状态就对不上了。订单表是业务核心关键字段有订单号、用户 id、充电桩 id、充电枪编号、开始时间、结束时间、时长、电量、金额、支付状态。订单号不要用数据库自增 id 直接暴露给前端我习惯用“yyyyMMddHHmmss 随机数”生成业务订单号既能排序又能防猜测。金额字段务必用 decimal(10,2)这一点我在后面计费模块会展开讲。计费规则表用“启停时间 费率”的组合来设计也支持按电量计费。比如 00:00 到 08:00 每度电 0.6 元、08:00 到 22:00 每度电 1.2 元这样的配置才能支持运营方灵活调价。表设计的核心思路就一句话把可能变化的业务参数抽出来独立成表而不是写死在代码里。2.2 REST 接口设计与 Token 鉴权方案接口设计直接决定了前后端联调的效率。我这次采用标准的 REST 风格资源用名词复数动作交给 HTTP 方法表达POST /user/login 做登录、GET /charger/list 查充电桩、POST /order/create 创建订单、POST /order/pay 发起支付。统一返回结构是必须做的一步。我用了 Result 泛型封装内部字段包括 code、message、data成功时 code 为 0失败时返回业务错误码。这样前端拿到任何接口的返回值都能用同一套逻辑去解析不至于一个接口返回一种结构。鉴权方案我选了 JWT而不是传统的 Session。原因很现实SSM 默认的 Session 方案在跨域请求和移动端请求里都要额外处理 Cookie 传递小程序原生请求并不会自动携带 SessionId会白白增加很多联调成本。JWT 的思路是把用户标识、过期时间、签名三样东西打包成一个字符串后端签发后返回给小程序端小程序每次请求在 Header 里带上 Authorization 字段后端写一个拦截器统一解析。拦截器的实现有几个细节值得注意。第一白名单要配好登录接口、充电桩列表接口、微信支付回调接口这些不需要鉴权的路径要放行。第二JWT 过期时间不要太长我设置了 7 天小程序端每次启动时可以静默检查 token 是否过期过期就引导用户重新登录。第三解析失败时要区分“token 失效”和“token 被篡改”返回不同的错误码方便小程序端做不同处理。REST 接口的另一个细节是参数校验。Controller 层只做接收和转发但业务参数的合法性校验必须在 Controller 层提前挡住这样脏数据不会落入 Service 层比如开始时间晚于结束时间、充电桩 id 不存在这样的低级错误直接在入口处抛业务异常比写到一半爆出空指针好排查得多。3. 后端核心模块从登录到充电订单闭环3.1 微信登录与 JWT 签发的完整链路微信登录是整套系统的第一道闸门。小程序端调用 wx.login 拿到一个临时凭证 code这个 code 有效期很短而且只能使用一次。后端拿到 code 后调用微信提供的 jscode2session 接口换取用户的 openid 和 session_key然后拿着 openid 去用户表里查找首次登录就自动注册非首次登录就直接签发 JWT 返回。这里有一个容易踩的坑前端传给后端的 code 必须严格一次性使用后端接口要做防重放处理。实际联调时我遇到过一次诡异现象请求打了两遍第一遍成功第二遍失败排查后发现是前端把 wx.login 放在了页面 onLoad 里页面被反复加载导致重复调用。解决方式是让小程序端把登录公共逻辑抽取到 App 实例上保证整个生命周期只执行一次。JWT 签发的过程我在代码里用了一个轻量的工具类。payload 部分只放 userId 和 loginOpenid 两个字段不放敏感信息签名密钥放在后端的配置文件中不硬编码到代码里。密钥选一个复杂度高的随机字符串我习惯用 32 位以上的 uuid这样即便有人拿到了 JWT也很难暴力破解签名。3.2 充电桩状态机与并发控制充电桩的状态是整个系统最容易出并发问题的突破口。两个用户同时扫码同一个空闲桩如果后端不做任何控制两个订单都会成功创建但物理上只有一个枪能供电另一个订单就变成了“幽灵订单”。为了保证同一时刻一个桩只能被一个用户占用我在创建订单的 Service 层做了严格的并发控制。核心思路是使用数据库的乐观锁在充电桩表加了 version 字段更新时使用这样的 SQLupdate charger set status 1, version version 1 where id #{id} and status 0 and version #{version}。如果受影响行数为 1说明当前用户成功抢占了该桩可以继续创建订单如果受影响行数为 0说明桩的状态已经被其他事务改掉了直接给前端返回“该充电桩已被占用”。这段逻辑必须在事务里执行且事务的隔离级别要设置为读已提交避免读到脏数据。状态变更的时序也需要严格设计。用户发起充电时桩从空闲变为充电中用户主动结束充电时桩从充电中变为空闲设备异常断连时桩应该由后台任务更新为异常状态。我在 Service 层定义了一个状态流转规范非法状态变更直接抛异常不允许代码里出现“任意状态改任意状态”的写法方便后续排查问题。3.3 计费规则与订单结算的实现细节计费模块是业务规则的集中地。我在计费规则表中维护了多条费率配置后端计算金额时先从订单的开始时间和结束时间中取出时间段再匹配生效的费率规则计算出总金额。这里要特别提醒金额计算一律使用 BigDecimal绝对不能用 double 或 float。原因很直白二进制浮点数在计算机里无法精确保存 0.1 这样的小数充电订单金额一旦出现精度误差对账时就会产生一分两分的差异累积起来可能变成大问题。我用 BigDecimal 的 multiply 方法计算金额并在最后调用 setScale(2, RoundingMode.HALF_UP) 保留两位小数。订单结算还有一个隐藏问题就是用户在充电过程中提前离开。产品策略上用户点击“结束充电”时基于最后一次上报的电量读数和时间戳生成结算数据而如果充电过程中小程序被系统杀掉了后端也要有一个定时任务去扫描那些“充电中但长时间无心跳”的订单延长一定时间后自动停机结算避免用户因为客户端故障而被持续计费。定时任务我用的是 Spring 自带的 Scheduled 注解配合 cron 表达式扫描频率不建议太频繁我设了每 5 分钟跑一次对订单量级来说完全够用。4. 小程序端地图找桩、扫码充电与支付闭环4.1 地图组件与附近充电桩列表小程序端的第一屏是充电桩地图。这里的关键点是如何把后端返回的充电桩列表变成用户看得懂的地图标记点。小程序自带的地图组件 map 支持 marker 标记点我根据充电桩经纬度和用户当前位置在地图上动态绘制所有可见的充电桩标记点颜色与桩状态绑定绿色空闲、红色充电中、灰色异常这样用户一眼就能看出附近有哪些可用资源。获取用户位置前必须先调用 wx.getLocation 并获得授权这一点开发者需要注意用户拒绝授权后的兜底逻辑。有些用户隐私意识比较强拒绝地理位置授权此时不能直接崩溃我选择退化为手动选择城市 浏览全部充电桩的模式给用户多一条路径。获取附近充电桩列表时后端接口接收经纬度和半径两个核心参数。SQL 的写法不是用 haversine 公式逐个计算后再排序那种写法在数据量上来后会非常慢。我用的方式是把经纬度先换算成对应的边界范围用 between 语句快速筛选出候选数据再在内存中计算精确距离排序输出。900 万用户量的场景下依然能稳定在百毫秒内返回这个思路在小样本毕业设计里体现得不太明显但面试时能讲出这个优化点是加分项。4.2 扫码充电与状态轮询扫码充电是小程序端体验最“仪式感”的一步。用户点击扫码按钮后wx.scanCode 调用摄像头扫描充电桩上张贴的二维码二维码内容我设计成了一段 URL形如 https://api.xxx.com/charger/info?id001002小程序端扫码后解析出充电桩 id再调用后端查询该桩的详情。后端返回详情的同时会检查桩的状态如果已被占用则直接提示如果空闲则展示确认充电页面用户确认后创建订单并启动充电。充电过程中的数据刷新我用的是轮询而不是 WebSocket。为什么不用 WebSocket 呢对毕业设计来说维护一个长连接服务需要额外占用服务器资源而且 SSM 框架原生对 WebSocket 的支持并不像 Node.js 那样顺手。轮询方式很简单小程序端每 5 秒请求一次订单实时状态接口返回当前电量、充电时长和预估费用用 setData 更新页面展示。这个刷新频率对用户感知来说已经足够流畅服务器压力也完全扛得住。4.3 微信支付回调与订单状态同步支付环节直接关系到资金流向代码必须严谨。小程序端调用 wx.requestPayment 支付前需要先请求后端创建预支付单后端调用微信支付统一下单接口拿到支付参数小程序端拉起支付界面用户输入密码完成支付。这个过程完成后微信服务器会给后端配置的支付回调地址发送一个异步通知后端必须正确处理这个通知才能最终确认订单已支付。支付回调处理有三个关键点必须处理好。第一是签名验证回调请求里带的签名必须用商户密钥重新计算比对防止伪造回调。第二是幂等性同一笔订单的支付回调可能因为网络原因被微信多次投递后端必须判断如果订单已经是已支付状态直接返回成功不再重复处理。第三是业务幂等更新更新订单状态和加账户余额必须在同一个事务里完成否则会出现“钱到了余额但订单还是未支付”的数据不一致。小程序端收到支付成功的结果后不能只凭前端回调去更新界面可靠的做法是调用后端查询订单真实状态以服务端的支付状态为准刷新页面。这一条是我在联调时体会最深的前端支付成功的回调并不可靠用户可能在支付中途杀死小程序但钱已经从账户扣了这时候唯一值得信任的就是后端订单库里的状态。5. 论文写作思路与图表组织5.1 把项目拆进论文结构的实用策略做毕业设计的同时要把项目过程写进论文很多同学觉得是最痛苦的部分其实关键是找到论文结构和项目阶段的对应关系。论文的开篇通常要求阐述研究背景和意义这一部分就可以把第 1 节的痛点分析直接转述成书面表达从电动车保有量增长引出充电难从充电难引出服务平台的必要性。不要空谈“随着我国经济快速发展”而是用具体的用户场景和数据结果来支撑论点。系统设计章节要放核心表结构的 ER 图以及关键功能模块的流程图。这里有个很实际的建议论文里的流程图不要画得天花乱坠用统一、简洁的矩形框和箭头表达清楚数据流向就好评审老师更关注你的逻辑是否清晰而不是图表本身多精美。工具方面我用的是 draw.io免费且支持导出 SVG 格式放到论文里也不会失真。5.2 测试章节怎么写才扎实论文的系统测试章节是最容易被敷衍的部分也最容易拉低评分。常见错误是只写“系统运行正常”“功能实现了”没有数据和用例支撑。正确做法是设计一张完整的测试用例表字段包括用例编号、测试模块、前置条件、操作步骤、预期结果、实际结果、是否通过。比如针对充电桩并发占用场景我专门写了并发测试用例使用两个账号同时扫码同一空闲桩预期结果是一个成功一个失败实际结果符合预期并将数据库层面的状态进行日志比对。性能测试同样不能空口说“系统很流畅”。我用 JMeter 模拟了 200 个并发用户同时查询充电桩列表记录平均响应时间、吞吐量和错误率把这些数据整理成表格放进论文。这样做出来的论文不仅内容充实答辩时更可以当证据使用任何关于系统是否稳定的问题直接拿数据说话完全不需要背锅。6. 调试排障与避坑记录6.1 并发状态下订单状态错乱第一次联调并发充电场景时我遇到了订单状态错乱的典型问题。两个账号同时抢一个桩日志里两条创建订单的 SQL 均执行成功数据库里出现了两条同桩订单。排查后发现原因有两个一是充电桩状态更新和订单创建没有放在同一个事务里状态被改掉后创建的订单没有回滚二是状态更新的 where 条件里没有带上“当前状态必须为空闲”这个约束。解决方案就是我前面提到的乐观锁 SQL把更新和选择的动作绑定在一起并给表加上 version 字段彻底杜绝了并发错乱。6.2 小程序真机调试连不上后端服务开发工具里接口请求一切正常一到手机预览就请求失败这个问题几乎每个做微信小程序开发的人都遇到过。原因通常是真机和电脑不在同一个局域网或者请求的接口地址写成了 localhost。解决的排查顺序是先确认后端服务监听地址不是 127.0.0.1 而是 0.0.0.0再把接口地址改成电脑在局域网中的 IP手机和电脑连接到同一个 Wi-Fi最后还要把该 IP 加入到微信公众平台的“开发设置”中的请求合法域名或者直接勾选“不校验合法域名”选项进行开发调试。这几个步骤按顺序排查百分之八十的问题都能解决。6.3 小程序抓包定位接口异常定位小程序和后端之间的接口异常抓包是很实用的手段。Charles 是使用频率很高的一台工具配置好 SSL 代理并安装证书后就能看到小程序发出的每一个请求的 URL、Header 和响应体定位参数错误、状态码异常这类问题非常直观。但抓包调试只是开发阶段的辅助手段真实生产环境必须将接口切换到 HTTPS 域名关闭调试模式的证书校验保证数据和通信安全。我自己在排查一个订单金额多出一分钱的问题时就是通过抓包对比了两次请求的入参发现前端把某个参数序列化成了字符串后端 BigDecimal 解析时做了进位处理根源找到后修改序列化配置就解决了。6.4 小程序页面列表加载更多的分页处理充电桩列表和历史订单列表涉及分页我在小程序端实现“上拉加载更多”时也踩过坑。小程序提供的 onReachBottom 是页面滚动到底部时的生命周期回调我首次实现时没有做“是否正在加载”的锁判断导致用户快速上拉时触发了多次相同请求出现数据重复追加的情况。修正方式是在加载方法内设置一个 isLoading 标志位进入请求时将标志位设为 true请求完成后再设为 false同时在页面底部维护一个 hasMore 状态接口返回的数据不足一页时就停止后续加载请求避免无意义的请求浪费流量。个人经验体会这个项目完整做下来我的体会是SSM 和微信小程序这套组合虽然不新但它们逼着你把每一层的基本功都练扎实了。Controller 怎么写才能瘦身、Service 怎么抽才能复用、Mapper 的动态 SQL 怎么拼才不易出错、小程序端页面数据怎么管理才不让交互卡顿这些问题在真实项目里都会一遍遍地挑战你。另外想说的一点是技术选题不要只盯着“热门”两个字而要盯着“完整闭环”。一个能跑通全部流程的项目哪怕技术栈老一点也要比一个只写了几个接口但连支付都没打通的“微服务全家桶”有价值得多。做完毕设答辩的时候被问到最多的问题其实不是你用了多新的框架而是“这个状态是怎么流转的”“并发冲突怎么解决”“支付回调怎么保证幂等”。把这些核心问题讲透就已经赢下了一大半。我在最后调试阶段还把每个接口都过了一遍边界参数做成了一个完整的接口测试文档这不仅是论文的一部分后续如果真的想把它部署上线也是一份直接能用的系统说明。