做电动汽车充电服务系统这类选题在高校毕业设计里几乎年年都有但真正做出“能答辩、能演示、能说明白”的反而不多。Spring Boot Java 的技术栈看似简单真正落地时牵扯到充电桩状态流转、订单计费、故障上报、运维闭环这些才是拉开差距的地方。这篇内容从业务设计、数据建模、接口实现、故障运维一路拆到排坑记录适合正在做同类系统设计的同学也适合刚接触充电运营业务的 Java 后端开发者。不需要多少分布式经验但需要你能完整走通一条充电订单的生命周期。1. 项目整体设计与业务拆解1.1 系统到底在解决什么问题作为毕业设计很容易把充电服务系统做成一堆 CRUD 页面老师一问“订单状态怎么流转”就答不上来。实际上充电服务系统的核心不是用户登录、不是后台列表而是设备、订单、资金三个对象的联动用户扫一个二维码桩从空闲变成占用充电过程中订单不断累计电量和金额结束之后账户余额被扣款桩又恢复空闲。中间任何一环断了都会产生资损或者投诉。这类系统要服务的角色有三类车主、运营管理员、运维工程师。车主关心附近哪些桩能用、怎么启动充电、怎么结算运营管理员关心电桩利用率、收入、故障率运维工程师关心哪里报故障、工单怎么处理。一个完整设计需要把这三种角色的核心诉求都覆盖到才好在答辩时把业务闭环讲清楚。我见过不少毕业设计的代码把“充电桩管理”理解成一张设备表的增删改查这只能算后台管理系统不是充电服务系统。真正有价值的部分在“充电流程”上从扫码启动到订单结束这个流程在服务端应该怎么设计才是选题的魂。很多同学把时间花在后台美化上到了核心流程却讲不清楚这是很可惜的。1.2 功能模块怎么划分我建议在功能设计上按端拆分而不是按数据表拆分。整体可以划成三类模块用户端App/小程序电站地图、桩状态查询、扫码启动、充电进度、订单结算、余额充值、故障提交。运营端Web管理后台电站管理、桩设备管理、价格策略、订单管理、充值流水、运营统计。运维端工单中心故障告警、工单派发、处理进度、设备维修记录。这样划分的好处第一是权限清晰用户端不可能访问运营端的接口运营端也看不到工单流转细节之外的运维数据。第二是便于演示答辩时按角色切换讲完用户流程讲运营流程再讲故障流程逻辑非常顺。第三是技术实现上有边界每个端对应一组接口代码不会变成一锅粥。如果项目想再冲高分可以加一个“运营大屏”模块把实时数据做成可视化统计。后面我会专门讲大屏上该放哪些指标以及这些指标背后的 SQL 怎么写。强烈建议毕业设计不要只做“能用”要做“能讲”大屏就是很直观的展示点。1.3 为什么是 Spring Boot而不是 SSM 或微服务很多同学纠结技术选型担心不用微服务会不会显得不高级。我的观点很直接单体应用优先除非团队规模和数据量真的到了必须拆分的程度。充电服务系统在毕业设计和小型商业试点场景下单体能跑得很稳开发效率也高。对比一下 SSM 和 Spring BootSSM 是经典三层架构组合但要手动装配 Spring 和 MyBatis写大量 XML 配置对刚入门的同学不友好Spring Boot 把这些配置自动化了提供了起步依赖、内嵌容器、健康检查开箱即用。我并不是说 SSM 不好只是在当前语境下Spring Boot 已经成为 Java Web 开发的事实标准企业里也更认可这套技术栈。加上 Spring Boot 的理念是“约定优于配置”对一个人完成的小项目来说能省下大量配置时间。那微服务呢Spring Cloud 那套注册中心、网关、配置中心对一个充电平台来说属于过度设计。真要用分布式架构至少得有一堆真实业务场景支撑否则答辩时老师一定会追问“你的服务拆分依据是什么”“数据一致性问题怎么解决”反而把自己绕进去。合理做法是用 Spring Boot 写一个模块边界清晰的单体预留出后续拆分的空间比如把“订单中心”“设备中心”“用户中心”做成独立的 Maven 模块。这样既能体现工程素养又不用真上分布式中间件。2. 核心数据模型与接口设计2.1 三张核心表怎么建数据建模是我最想强调的部分。先看设备侧一张device表必须包含桩编号、所属电站、充电类型交流/直流、额定功率、当前状态、经度纬度、固件版本、最近心跳时间。桩编号要用业务编号而不是自增 ID比如站编号加设备序号因为它在物理世界里是唯一标识后续对接硬件、生成二维码都要用它。再看订单侧charging_order表是系统里最忙的表字段至少要有订单号、用户 ID、设备 ID、电站 ID、开始时间、结束时间、启动前电表读数、结束电表读数、充电电量、订单金额、状态。订单号一定要唯一常见做法是“yyyyMMddHHmmss随机数”方便分表也方便日志排查。另外要把设备 ID 和用户 ID 都冗余进来因为在统计“某台设备的充电次数”“某个用户的消费总额”时单表查询就能完成不用来回 join。最后是资金侧建议拆成account和recharge_record两张表。账户余额放在account充值流水记到recharge_record。为什么不能只记流水因为余额是当前值流水是历史明细查询余额时不能每次去 SUM 流水性能差且容易出错。同理每笔订单扣款也在流水里留一条“消费”类型这样对账时有据可查。我用一个简化版建表来演示核心字段实际项目里再加冗余字段CREATE TABLE device ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_no VARCHAR(32) NOT NULL UNIQUE, station_id BIGINT NOT NULL, type TINYINT NOT NULL COMMENT 1-交流 2-直流, power_kw DECIMAL(6,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0空闲 1占用 2充电中 3故障 4离线, lat DECIMAL(10,6), lng DECIMAL(10,6), last_heartbeat DATETIME, version INT DEFAULT 0, create_time DATETIME );这里有个容易踩的坑power_kw和金额相关的字段不要用FLOAT或DOUBLE因为浮点数的精度会产生类似0.10.2 ! 0.3的问题。货币计算全用DECIMALJava 层面对应BigDecimal。2.2 充电状态机是关键我在开头说过充电系统最有技术含金量的是状态流转。一个充电桩最少要有这几种状态空闲、占用中、充电中、故障、离线。很多人的实现是把status当成普通字段直接用 update 覆盖这是错误示范。正确的思路是定义状态机明确哪些状态之间可以跳转。比如空闲 - 占用中用户扫码且设备健康检查通过。占用中 - 充电中设备启动成功服务端收到启动确认。充电中 - 空闲用户主动结束或订单完成结算。任意状态 - 故障设备心跳上报故障码或多次启动失败。任意状态 - 离线心跳超时。状态跳转要在代码里做校验不能哪段逻辑想改就直接 update。用一个枚举来收口public enum DeviceStatus { IDLE(0, 空闲), OCCUPIED(1, 占用中), CHARGING(2, 充电中), FAULT(3, 故障), OFFLINE(4, 离线); private final int code; private final String desc; DeviceStatus(int code, String desc) { this.code code; this.desc desc; } public int code() { return code; } }设备状态更新时不仅要判当前状态是否允许跳转还要防并发。比如两个用户同时扫同一个桩都读到“空闲”然后都执行“改成占用”就会造成一桩多充。解决办法是用带条件的更新UPDATE device SET status 1, version version 1 WHERE id #{deviceId} AND status 0这条 SQL 返回影响行数为 1 才说明抢锁成功为 0 就要提示“设备已被占用”。这种方式既不用加数据库悲观锁又能保证并发下的正确性是单体应用里最实用的做法。后续如果要继续优化还可以把这个条件更新和 Redis 分布式锁配合但对毕业设计已经足够了。2.3 计费与结算逻辑计费规则可以做得简单也可以做得有层次。低配版是“固定单价乘以电量”高配版是“尖峰平谷分时电价服务费”。如果时间来得及建议至少做分时段计费因为这是运营系统里很明确的加分项。先定义价格表price_rule设备类型、时段开始、时段结束、电量单价、服务费单价。查询时优先取当前时间所在时段找不到就取默认价。结算代码的核心逻辑如下BigDecimal unitPrice priceService.getPrice(deviceType, settleTime); BigDecimal amount energy .multiply(unitPrice) .add(energy.multiply(serviceFee)) .setScale(2, RoundingMode.HALF_UP);这里有两个细节值得注意。第一电量不能简单用“结束读数减开始读数”要考虑电表翻转和读数异常商业系统里通常以充电设备上报的累计电量为准异常数据要走人工审核。第二订单创建和余额扣款必须在一个事务里否则会出现订单成功但扣款失败的脏数据。对于异常订单比如用户启动后 5 秒内就结束我认为应该设置一个“最小计费时长”不足 5 分钟按 5 分钟计但是要提前在用户协议里写清楚避免投诉。金额计算出来之后最好在返回结果里把“电量”“单价”“服务费”“总金额”都展示给用户减少后期对账矛盾。2.4 RESTful 接口怎么设计接口设计遵循 RESTful统一前缀/api返回统一结构体。一个简单的ResultT包含 code、message、data状态码用业务码而不是 HTTP 状态码因为 HTTP 状态码对前端业务判断不够细。充电主要接口可以这样规划方法路径说明POST/api/charging/start启动充电POST/api/charging/stop结束充电GET/api/charging/order/{orderNo}查询订单实时状态GET/api/device/list附近可用设备POST/api/fault/report用户上报故障以启动充电为例参数应该是deviceNo加userId返回订单号和预计等待信息。服务端流程是这样的校验用户是否实名、校验余额是否充足、校验设备状态、创建订单、调用设备启动接口、更新设备状态。其中“创建订单”和“更新设备状态”不能分开要包在一个事务里。接口层面还要考虑幂等。用户网络卡顿会重复点击前端可以通过按钮 loading 限制后端也要兜底。做法是生成一个请求唯一标识requestId启动时先查这个 requestId 是否已处理过重复请求直接返回原订单结果。这个设计在答辩时也很加分因为它属于真实场景里必须考虑的问题。3. 从零搭建与核心实现3.1 工程结构与基础配置工程我习惯用 Maven 管理依赖版本统一放parent。Spring Boot 版本建议选稳定版不需要追新。主工程结构可以是这样的charging-server ├── charging-common // 通用返回、工具、异常 ├── charging-admin // 运营后台接口 ├── charging-user // 用户端接口 ├── charging-ops // 运维端接口 └── charging-infra // 数据访问、外部服务对接如果是普通单体项目也可以不拆这么细但至少 Controller、Service、Mapper、Entity、Config 这五层要分开。包结构清晰的好处是答辩时可以展示工程素养别人接手也省心。依赖方面最常用的一套是spring-boot-starter-web、mybatis-plus、mysql-connector-j、redis、validation、jwt。连接池用 HikariCP它是 Spring Boot 默认集成的性能很好不用额外配。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/charging?useUnicodetruecharacterEncodingutf8 username: root password: ${DB_PASSWORD} driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 mybatis-plus: global-config: db-config: logic-delete-field: deleted配置里有个小细节数据库密码不要硬编码用环境变量${DB_PASSWORD}替换提交代码时不会泄露。如果你想把这个项目放到简历和代码仓库里这个习惯很重要。3.2 启动充电流程的实现实际写代码时可以先把 Controller 写好再写 Service。Controller 只做参数接收和结果返回业务逻辑全部下沉。RestController RequestMapping(/api/charging) public class ChargingController { Resource private ChargingService chargingService; PostMapping(/start) public ResultStartChargeVO start(RequestBody Valid StartChargeReq req) { return Result.ok(chargingService.start(req)); } PostMapping(/stop) public ResultStopChargeVO stop(RequestBody Valid StopChargeReq req) { return Result.ok(chargingService.stop(req)); } }Service 里的核心逻辑是启动前检查、状态抢占、创建订单、模拟设备启动。我在指导时一般建议先实现“模拟设备层”不要一上来就考虑怎么接真实充电桩硬件。真实桩的协议很杂对接周期长毕业设计根本来不及。可以定义一个DeviceAdapter接口模拟实现里返回固定结果真实实现留出 TODO答辩时讲清楚设计思路即可。如果是模拟充电进度我推荐用 Spring 的定时任务或者CompletableFuture来模拟电量增长而不是让用户在前端手填。比如启动充电后每 30 秒把订单电量加 0.5 度直到达到容量或者用户结束。这样演示时界面有动态效果论文里还能写“系统通过任务调度模拟充电过程实际接入硬件时替换数据源即可”。Component public class ChargeTask { Resource private ChargingOrderMapper orderMapper; Scheduled(fixedDelay 30000) public void simulateProgress() { ListChargingOrder runningOrders orderMapper.selectRunningOrders(); for (ChargingOrder order : runningOrders) { order.setEnergy(order.getEnergy().add(new BigDecimal(0.5))); orderMapper.updateById(order); // 达到阈值后自动结束 if (order.getEnergy().compareTo(order.getMaxEnergy()) 0) { chargingService.finishOrder(order); } } } }定时任务的缺陷是断电和重启后会漏任务所以真正严谨的做法是把状态机和任务调度结合后面在常见问题里我会专门讲重启补偿。这个模拟过程也不要做得太随机因为答辩时老师会盯着看数据是否合理固定增长比随机增长更容易讲。3.3 故障上报与工单闭环故障运维模块是这类系统区别于普通管理系统的重要亮点。故障来源一般有两个设备心跳主动上报、用户扫码或充电时手动上报。前者靠last_heartbeat判断心跳超过 5 分钟没有更新就把设备置为离线设备上报故障码则直接置为故障。收到故障信息之后系统要做三件事写故障记录、生成运维工单、通知相关人员。工单状态可以简化为待处理、处理中、已解决。核心接口FaultService.handleReport伪代码如下public void handleFault(FaultReport report) { Long deviceId report.getDeviceId(); deviceMapper.updateStatus(deviceId, DeviceStatus.FAULT); WorkOrder workOrder new WorkOrder(); workOrder.setDeviceId(deviceId); workOrder.setFaultType(report.getFaultType()); workOrder.setStatus(WorkOrderStatus.PENDING); workOrderMapper.insert(workOrder); // 通知运维人员先做站内信预留扩展 notifyService.send(workOrder); }这个模块里我建议加一个“处理时限”维度按故障等级设置 SLA。比如 P0 级必须在 30 分钟内响应P1 级 2 小时P2 级 24 小时。后台用定时任务扫描超时工单并升级提醒虽然代码量不大但是能体现运营思维。如果答辩被问到“故障工单和一般工单有什么区别”就可以把 SLA 机制拿出来讲。3.4 登录与权限怎么处理JWT 是现在比较通用的方案。用户端登录成功后返回 token前端每次请求放在 Authorization 头里。服务端用拦截器解析 token把用户信息放入 ThreadLocal业务代码直接取。运营端和运维端的权限可以通过角色字段区分不用引入太重的权限框架。真正要做细权限后面可以接 Spring Security 加角色化的方法注解但毕业设计阶段先保证“登录能拦截、接口能鉴权”即可。有一点要注意JWT 一旦签发在没有刷新机制的情况下无法主动失效。演示时如果遇到“用户已禁用但 token 还能用”的质疑可以补充一个 Redis 黑名单设计登出时把 token 的 jti 写入 Redis拦截器检查黑名单。这个设计不复杂但能体现你对 token 机制的完整理解。4. 故障运维、监控与报表4.1 故障分级与处理策略设备故障不能一刀切。我建议按业务影响程度分三级级别定义处理要求P0设备完全不可用、通信中断、存在安全隐患30分钟内响应必要时停运设备P1充电中断、计费异常、设备频繁自动关闭2小时内响应优先恢复充电P2单个指示灯异常、屏幕显示异常、非核心部件问题24小时内列入计划处理分级在后台要有对应字段工单自动带出等级。答辩时如果讲出这套机制比单纯展示“能上报故障”要深刻得多。还要注意一点离线不等于故障。停电、现场网络抖动都可能导致离线这种场景下如果能恢复心跳设备应该回到之前的状态。状态机里要允许“离线 - 空闲”这样的恢复路径不能一离线就要求人工介入。4.2 管理端统计报表怎么设计运营后台如果只有列表和表单演示效果会大打折扣。至少要做一个统计面板指标可以分三层设备层设备总数、在线率、故障率、利用率。订单层今日充电订单数、今日充电量、平均单次充电时长。收入层今日金额、本月累计、充值金额与消费金额对比。这些指标对应 SQL 都不复杂比如今日收入SELECT COALESCE(SUM(amount), 0) AS today_amount FROM charging_order WHERE status 2 AND settle_time CURDATE()但要注意统计 SQL 不要去扫全表最好按settle_time建索引。如果页面打开慢优先看 SQL 执行计划而不是加缓存因为这个量级的数据根本到不了必须上缓存的级别。如果想让大屏更好看可以做一个GET /api/statistics/overview接口把聚合好的数据一次返回前端每 10 秒轮询一次效果就很流畅。不要为了显得高级去上 WebSocket轮询在这个场景里足够演示。4.3 并发与事务充值与扣款不能“打架”充电订单结算时扣款这一步最容易出错。很多人的写法是先把账户余额查出来减掉金额再 update用代码控制“查询-计算-更新”三个步骤。这在并发下是危险的用户充值接口和订单扣款接口同时操作账户可能把余额算错。标准解法是把判断和更新放到一条 SQL 里让数据库保证原子性UPDATE account SET balance balance - #{amount}, version version 1 WHERE user_id #{userId} AND balance #{amount}影响行数为 1 说明扣款成功为 0 说明余额不足。这一步加上事务再配合幂等控制基本能保证资金安全。事务边界要特别注意不能把“扣款”和“更新订单状态”写在两个方法里然后指望调用方去控制而应该在同一个 Service 方法上加Transactional这样两个写操作要么一起成功要么一起回滚。锁、事务、索引这三个点答辩时被问到的概率非常高。4.4 性能优化与部署建议单体应用性能优化重点是“少查数据库、查对数据”。充电桩状态列表接口不需要把 30 个字段全查出来只返回 id、状态、功率、距离就够了。列表 SQL 用字段白名单避免select *。附近电站查询可以先用经纬度范围过滤再在代码里算距离排序。简单做法WHERE lat BETWEEN #{latMin} AND #{latMax} AND lng BETWEEN #{lngMin} AND #{lngMax}这个条件能命中索引先圈定候选集数据量大时再用 Redis GEO 或引入空间索引。对毕业设计来说MySQL 这种方案足够别为了“技术新颖”硬上不熟悉的东西。要看实时性设备状态可以加一层 Redis 缓存但要注意缓存和数据库的失效策略不然会出现“桩实际空闲但页面还显示充电中”的尴尬情况。部署层面我推荐最基本的方案一台云服务器MySQL、Redis 装在同一台机器Spring Boot jar 包用 systemd 启动。不要一上来就搞 Docker、K8s除非你非常熟。先把应用跑起来、日志能看、进程能重启就比很多人强了。5. 常见问题与排查实录5.1 高频问题排查对照表做这类系统我总结过一份高频问题速查表按出现频率从高到低排列现象可能原因排查思路扫码后设备状态没变化并发下两个请求都读到空闲状态检查设备更新语句是否带where status 0充电订单启动成功但电量不动定时任务没生效或任务异常被吞service 方法是否有 try-catch定时任务日志是否打印订单金额算出来是 0.30000000004金额字段用了浮点类型数据库改 DECIMALJava 用 BigDecimal设备一直显示离线心跳时间字段没更新或时区不一致看日志里最近心跳时间确认服务器时间与数据库时间接口返回 500 且前端看不到原因全局异常处理器吞掉或日志没配置在全局异常处理器打印堆栈统一返回错误码重启后所有订单都卡在充电中缺少启动恢复任务在 ApplicationRunner 里补偿异常订单第一条最典型我见过很多项目都在这里翻车。两个用户同时抢同一个桩表面上都“成功”了订单也建了但实际上只有一个能真正占用。如果不用带条件的 update后续计费和状态会乱得一塌糊涂。排查时只要检查 update SQL 的 where 条件是否包含当前状态即可。5.2 设备重启补偿这件事必须做有一次做压力测试我把服务重启了一下结果所有“充电中”的订单全部卡死。用户端看不到结束按钮后台也结算不了。原因很简单订单状态存在数据库里但充电中的实时推进靠的是内存里的定时任务应用一重启任务就没了。解决办法是在应用启动时做一次补偿。扫描所有状态为“充电中”的订单逐个处理如果设备心跳还在就保留充电状态重新拉起任务如果设备心跳也断了直接按异常结束处理退还剩余金额。代码可以放在一个实现ApplicationRunner的组件里。Component public class OrderRecoveryRunner implements ApplicationRunner { Override public void run(ApplicationArguments args) { ListChargingOrder stuckOrders orderMapper.selectByStatus(OrderStatus.CHARGING); for (ChargingOrder order : stuckOrders) { chargingService.compensate(order); } } }这段逻辑虽然简单但它能体现你对系统稳定性的理解。很多答辩老师不会问你怎么写 CRUD而是会问“线上跑的时候挂了怎么办”你如果答出这个方案印象分会明显不一样。这里还有一个细节补偿逻辑必须保证幂等不能在重复启动时给用户退两次款。可以在 compensation 记录表里加一个order_no唯一约束。5.3 测试数据要像“真运营”一样准备演示翻车往往不是代码问题而是数据问题。空数据库里只有几个测试账号充电订单全在“已结束”页面空空荡荡技术再好也讲不出彩。我建议在初始化脚本里准备一套有故事的演示数据一个电站、10 台设备其中 8 台在线、1 台故障、1 台离线订单覆盖今天、昨天、上周金额有大有小。这样演示时点开任意页面都有内容还能顺势讲运维场景。这套数据脚本要手动构造尤其注意设备状态和工单状态的关联。比如故障设备对应一张“待处理”工单这样运维端演示时可以走完整流程。另外演示前一定要清掉调试日志和临时数据尤其是不要把测试过程中产生的重复订单展示出来。干净的数据加上完整的业务闭环比多写十个接口都管用。最后分享一点个人体会。做充电服务系统最忌一上来就写代码。先把业务状态机画出来把“什么时候能做什么操作、不能做什么操作”定清楚再动手建表写接口后面返工率会低很多。我接触过的模拟项目里凡是先做了状态设计再编码的几乎都顺利跑通凡是拿到需求直接开写 CRUD 的十有八九要在联调阶段推翻重来。这个系统还有很多可以延伸的方向比如对账模块、负载均衡、消息队列削峰。但作为毕业设计先把单体闭环做扎实把状态流转、并发扣款、故障补偿这几个点讲透就足够支撑一场漂亮的答辩了。如果你正在做这个选题建议先把设备状态图贴到自己电脑前再开始写第一行代码。