每年到了毕设开题季Java、SpringBoot、管理系统这组词就是计算机专业搜索榜的常客。电力营销系统作为典型的行业信息化项目既不像图书管理、学生系统那样烂大街又能把Java Web开发的核心技能完整串起来所以热度一直很高。我帮不少学弟学妹把这个选题从需求分析做到项目答辩自己也完整复现过一套基于SpringBoot的电力营销管理平台。今天就把整个过程中的系统设计、技术选型、核心功能实现和踩过的坑一次说清楚给准备做这个题目的人一份能直接参考的实操笔记。1. 项目定位电力营销系统的核心要解决什么做项目之前我习惯先问一个问题这个系统到底服务谁、解决什么业务问题电力营销不是一个泛泛的“管理系统”它有非常明确的行业业务背景。只有把业务逻辑吃透代码和数据库设计才不会跑偏。1.1 电力营销业务的全流程闭环电力营销管理的核心是围绕“电”这种特殊商品展开的客户服务与交易管理。它和普通电商系统最大的区别在于电是先使用、后计量、再付费的商品而且价格不是固定值可能按阶梯计价还分峰谷时段。因此系统需要支撑的业务闭环大致是这样的业扩报装新装、增容、减容→ 装表接电 → 抄表核算 → 电费发行 → 电费收缴 → 客户服务与统计分析。也就是说用户想用电得先提交申请业扩报装供电公司审批通过后安装电表然后每个抄表周期读取电表读数计算用电量和电费生成账单用户缴费最后系统汇总分析。一个完整的电力营销系统至少要覆盖这个链条的后半段也就是抄表、核算、收费、统计。做得完整一些的会把业扩报装也纳入进来形成全流程管理平台。我当时做技术方案时核心就围绕“抄表核算 收费管理 业扩报装 统计分析”四个模块展开。这也正好呼应了项目标题里的“全流程管理系统”。1.2 为什么这个选题适合作为计算机毕业设计这个题目我在不同场合推荐过很多次理由是它完美卡在“像样”和“能做出来”之间的平衡点。第一技术覆盖面全。它天然涉及CRUD基础操作、复杂业务规则阶梯电价、违约金计算、流程审批状态机、定时任务月度结账、报表导出、权限控制。这些几乎是Java岗位面试中最高频考察点的集合。面试官问“做过什么项目”你能拿这套系统把每个点讲清楚说服力很强。第二业务复杂度适中。医疗系统、金融系统的业务规则太深学生短时间啃不下来学生管理、图书借阅又太单薄撑不起一篇像样的论文和答辩。电力营销恰好介于两者之间业务规则足够支撑论文的“创新点”和“难点”比如阶梯电价算法、按供电所的数据权限隔离但又不至于让本科生几个月写不完。第三行业背景清晰容易被理解。电力行业是每个评审老师都接触过的领域你说“分时电价”“阶梯电费”“欠费停电”老师一听就明白答辩时不用费劲解释业务背景。1.3 系统的核心用户与角色边界系统角色划分直接决定了权限模块怎么做。我建议不要做成简单粗暴的“管理员/普通用户”两级而是贴近真实供电营业厅的岗位设置。系统管理员负责用户管理、角色权限分配、系统参数配置。业务受理员处理业扩报装申请、客户档案管理。抄表员负责抄表任务、录入电表读数。核算员/收费员电费核算、账单发行、缴费确认、退费处理。普通用电客户查询用电量、查看账单、在线缴费、发起报装申请。实际编码时如果做RBAC权限模型工作量稍大很多毕设会选择“用户表加角色字段拦截器校验”的方式。我做的版本是基于Sa-Token实现登录认证再用拦截器做接口级权限控制效果接近RBAC但代码量可控。这个小设计在答辩时能算一个亮点。2. 技术选型与项目搭建技术选型的原则只有一条不要追新要追稳。毕设项目最怕的是技术版本太新导致网上资料对不上其次是太老显得没技术含量。下面是我实测下来最稳妥的一套组合。2.1 后端框架SpringBoot版本怎么选SpringBoot现在主流的两个大版本是2.x和3.x。我在这件事上吃过亏一开始图新鲜用了SpringBoot 3.2结果发现很多教程和依赖都还停留在javax命名空间时代SpringBoot 3.x把javax.servlet换成了jakarta.servlet导致网上大量代码直接粘贴后编译报错。对毕设来说这是完全没有必要的麻烦。最终我推荐的版本组合是JDK 1.8不要用17SpringBoot 2.x对JDK8支持最好且JDK8环境下运行最稳定SpringBoot 2.7.18这是2.x分支最后一个版本修复了大量已知问题Maven 3.6.3MySQL 5.7 或 8.0 均可建议8.0连接串记得加serverTimezoneAsia/Shanghaiapplication.yml里几个关键配置我贴一下server: port: 8080 servlet: context-path: / spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/power_marketing?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: your_password jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl注意allowPublicKeyRetrievaltrue这个参数MySQL 8.0默认使用 caching_sha2_password 认证插件不加这个参数JDBC连接偶尔会报Public Key Retrieval is not allowed。这个坑非常隐蔽我卡了半个多小时才找到原因。2.2 持久层与代码生成MyBatis-Plus实战毕设项目用MyBatis-Plus几乎是标配它比原生MyBatis省掉大量重复的CRUD代码而且自带分页插件、条件构造器、代码生成器。不过要注意MyBatis-Plus的代码生成器在不同版本里API差别很大3.5.2之后的版本把AutoGenerator的很多方法标记为弃用但用起来反而简单了。我的做法是先用代码生成器生成entity、mapper、service、controller全套代码然后在此基础上手工改业务逻辑。生成器配置项很多核心只需要改数据库连接、包名、表名前缀即可。FastAutoGenerator.create(jdbc:mysql://localhost:3306/power_marketing?serverTimezoneAsia/Shanghai, root, password) .globalConfig(builder - builder.author(yourname).outputDir(System.getProperty(user.dir) /src/main/java)) .packageConfig(builder - builder.parent(com.example.power).entity(entity).mapper(mapper).service(service).controller(controller)) .strategyConfig(builder - builder.addInclude(customer, meter, electricity_bill, payment_record)) .execute();生成完之后我强烈建议把Controller里的逻辑清空重写因为自动生成的Controller只是空壳真正需要花心思的业务逻辑阶梯电价、账单状态流转必须手工实现。代码生成器的意义是帮你把20%的重复体力活干掉剩下80%的设计与实现才是项目的核心价值。2.3 前端、数据库与部署的整体方案前端的方案我第一个推荐的是Vue 2 Element UI。虽然Vue 3已经是主流但Element Plus对新手不算友好网上能找到的电力系统管理后台模板大多是Vue 2 Element UI。而且Vue 2的生态资料极其丰富遇到问题随手一搜就有答案。如果你不想写前端也可以直接采用Thymeleaf Bootstrap的服务端渲染方式整个项目变成一个纯粹的SpringBoot工程部署时无需Node环境。但这样的弊病是项目看起来不够“现代化”答辩演示时效果差一些。我做的是前后端分离版本前端工程单独开发npm run build之后把dist目录内容复制到SpringBoot的src/main/resources/static下最终仍然打包成一个jar运行。这样既保留了前后端分离的开发体验又避免了部署两个服务的麻烦。数据库方面MySQL单库即可表数量控制在10张左右比较合理。Redis不是必须的毕设时间紧的话可以不引入把缓存相关的点放在论文的“可扩展性”里说明即可。3. 数据库设计与核心模块拆解数据库设计是电力营销系统的地基。表结构设计得是否合理直接决定后面写业务代码时是顺畅还是痛苦。我在设计时坚持几个原则业务表与流程表分离、金额字段统一用DECIMAL、所有表都带create_time和update_time。3.1 核心数据表设计整个系统我设计了11张核心表覆盖全流程管理的需要。挑最重要的几张说一下设计思路。客户表customer存放用电户的基础档案包括户号、客户姓名、身份证号、联系电话、供电所ID、用电地址、用电类别居民/商业/工业、电表ID。户号我采用“供电所编码6位流水号”的格式比如GD01000001这个字段要做唯一索引。设计时注意把“客户”和“电表”分开因为现实中存在一个客户名下多块电表的情况虽然毕设里不一定会用到但表结构要预留这种可能性。电表表meter记录电表的基本信息包括电表编号、型号、额定电压、电流互感器变比、初始读数、安装日期、状态正常/停用/故障。这里有个行业细节电表的读数存在倍率问题高压计量用户装了互感器表上走1度实际可能是几十度。因此计算用电量时不能简单用“本次读数-上次读数”还要乘以倍率。我在表里设计了multiplier倍率字段默认值1这个细节在论文里可以作为一个“业务难点”来写。抄表记录表meter_reading记录每个抄表周期电表的读数字段包括抄表ID、电表ID、上月读数、本月读数、用电量、抄表人、抄表时间、抄表方式。抄表这个动作在真实业务里可能是人工上门或远程采集在系统里就是一次insert操作但计算逻辑要严谨本月读数小于上月读数时说明电表被重置或者发生倒走系统必须拦截并提示异常不能直接算出负数用电量。电费账单表electricity_bill是系统的核心表字段包括账单ID、客户ID、电表ID、账单月份、抄表记录ID、用电总量、一档电量、二档电量、三档电量、电费金额、滞纳金、应付金额、账单状态待支付/已支付/已作废、发行时间。把各档位电量单独存字段是为了后续统计各档位占比也方便审计。缴费记录表payment_record记录每笔缴费流水字段包括缴费单号、账单ID、客户ID、缴费金额、缴费方式柜台/微信/支付宝、流水号、缴费时间。缴费单号我采用“时间戳4位随机数”生成确保并发时不重复。此外还要考虑一笔账单支持多次缴费部分缴费的情况设计时需要记录已缴金额和未缴金额。其余几张表用户表sys_user、角色表sys_role、角色权限关联表、业扩报装申请表business_apply、电价表tariff。电价表单独建的好处是不同地区、不同用电类别的电价规则可以灵活配置不用把阶梯电价参数硬编码在Java代码里。3.2 电价计费规则建模电价计费是电力营销系统区别于普通管理系统的核心亮点。国内居民用电普遍采用阶梯电价不同地区分档标准不一样我以某地居民阶梯电价为例建模一档月用电量0至240度电价0.52元/度二档月用电量241至400度电价0.57元/度三档月用电量400度以上电价0.82元/度数据库里的tariff表结构可以这样设计字段名类型说明tariff_idbigint电价IDtariff_namevarchar电价名称例如居民阶梯电价electricity_typevarchar用电类别居民/商业/工业gradeint档位1/2/3min_valuedecimal该档电量下限0/240/400max_valuedecimal该档电量上限240/400/999999pricedecimal该档单价effective_datedate生效日期计费时根据账单月份的用电总量按档位分段计算。这个逻辑用代码实现很直观我在第4章会给出具体实现代码。3.3 权限与数据隔离设计权限设计能体现项目的完整度。我的方案是sys_user表存登录账号、密码BCrypt加密、角色IDsys_role表存角色编码和名称sys_role_permission表存角色拥有的权限标识比如customer:add、bill:pay这样的字符串。后端接口在Controller方法上用自定义注解RequirePermission标注权限标识通过拦截器校验当前用户是否拥有对应权限。数据隔离指的是抄表员只能看到自己供电所管辖的客户数据。做法很简单sys_user表里增加org_id供电所ID字段查询客户列表时如果当前用户不是系统管理员就自动追加where条件org_id 当前用户org_id。这一行代码在毕设论文里可以扩展成一节“基于供电所的数据权限控制方案”非常拿得出手。4. 核心功能实现与关键代码这一部分挑几个含金量最高的功能来讲。我不打算把Controller、Service、Mapper三层都列一遍那样太啰嗦只讲最核心的算法与流程实现。4.1 阶梯电价计算实现阶梯电价计算的输入是当月总用电量输出是各档位电量和总电费。实现方式是一个纯函数不依赖数据库查询方便单独测试。我用Java实现如下public TariffResult calculate(int totalPower, ListTariff tariffs) { TariffResult result new TariffResult(); result.setTotalPower(totalPower); int remaining totalPower; BigDecimal totalFee BigDecimal.ZERO; for (Tariff tariff : tariffs) { if (remaining 0) { break; } int segment Math.min(remaining, tariff.getMaxValue() - tariff.getMinValue()); BigDecimal fee tariff.getPrice().multiply(BigDecimal.valueOf(segment)); totalFee totalFee.add(fee); // 记录各档位电量 if (tariff.getGrade() 1) { result.setGrade1Power(segment); } else if (tariff.getGrade() 2) { result.setGrade2Power(segment); } else if (tariff.getGrade() 3) { result.setGrade3Power(segment); } remaining - segment; } result.setTotalFee(totalFee); result.setPayableFee(totalFee); return result; }注意几个实现要点。第一Tariff是按grade升序排列的如果数据库里没有排序代码里必须先sort否则计算全乱。第二所有的金额计算必须用BigDecimal不能用double否则会出现0.999999这种精度问题财务系统出现这个是很严重的错误。第三maxValue - minValue代表这个档位的容量比如一档容量是240-0240二档是400-240160。我在计算前还会对用电量做合法性校验。如果本次抄表读数小于上次读数说明数据异常直接返回错误提示不允许生成账单。这段校验写在Service层的Transactional方法里保证出异常时数据能够回滚。4.2 抄表与账单生成流程抄表到生成账单的过程是系统所有流程中最能体现“全流程管理”价值的一段。抄表员在系统中选择本月抄表任务输入电表本次读数。系统自动计算用电量本次读数-上次读数乘以倍率写一条meter_reading记录。保存抄表记录之后立刻触发账单生成查电价表算阶梯电费生成electricity_bill记录账单状态为待支付。这个流程建议放在一个Service方法里顺序执行并且加上Transactional。为什么因为抄表和生成账单必须是原子操作。如果抄表成功但账单生成失败轻则数据不一致重则下个月无法正常结算。用一个事务包住要么全部成功要么全部回滚。实际编码时我还会在生成账单前校验账期唯一性同一块电表在同一个账单月份只能存在一条有效账单。这个校验可以防止重复点击抄表按钮导致重复计费。这是一个非常容易忽略但特别重要的逻辑。月度结账还有一种场景是“批量月结”。系统定时任务Scheduled每月1号自动扫描上个月没有生成账单的电表批量执行抄表默认读数为上次读数即用电量为0并结账。这部分代码完成后我在论文里把它描述为“基于定时任务的自动抄表结账机制”也算是系统智能化程度的一个体现。4.3 缴费、退款与对账逻辑缴费模块的难点在于处理“并发”和“流水”两个点。用户的缴费动作在系统里实际上包含两步插入一条payment_record缴费记录然后更新electricity_bill的可缴状态。这两步必须在同一个事务中完成。Transactional(rollbackFor Exception.class) public PayResult pay(PayRequest request) { // 1. 锁定账单防止并发重复缴费 ElectricityBill bill billMapper.selectByIdForUpdate(request.getBillId()); if (bill null || !待支付.equals(bill.getBillStatus())) { return PayResult.fail(账单不存在或已支付); } // 2. 生成缴费单号 String payNo String.format(%s%04d, LocalDateTime.now().format(DateTimeFormatter.ofPattern(yyyyMMddHHmmss)), ThreadLocalRandom.current().nextInt(1000)); // 3. 插入缴费记录 PaymentRecord record new PaymentRecord(); record.setPayNo(payNo); record.setBillId(bill.getBillId()); record.setCustomerId(bill.getCustomerId()); record.setPayAmount(bill.getPayableFee()); record.setPayMethod(request.getPayMethod()); record.setPayTime(LocalDateTime.now()); paymentRecordMapper.insert(record); // 4. 更新账单状态 bill.setBillStatus(已支付); bill.setActualPayAmount(bill.getPayableFee()); bill.setPayTime(LocalDateTime.now()); billMapper.updateById(bill); return PayResult.ok(payNo); }这里面最关键的是第1步selectByIdForUpdate。这个语句会锁定该账单对应的数据库行直到事务提交或回滚。当两个用户同时支付同一笔账单时第二个请求会被阻塞事务结束后读到的最新状态是“已支付”于是直接返回失败从而避免重复扣费。这个点是我在模拟并发测试时发现的不加锁的话真的会出现同一张账单被支付两次的情况。退款逻辑我做成反向操作插入一条退款记录金额为负账单状态从已支付变为已退款。为了方便对账我在缴费记录表里增加了trade_type字段区分缴费和退款统计日报时按类型汇总即可。4.4 业扩报装与流程审批业扩报装是电力营销业务链条的起点。用户提交新装申请后系统要走“受理→审批→装表→归档”的流程。毕设里不需要接入工作流引擎Activiti、Flowable用状态机的方式就行business_apply表里设一个status字段用数字表示流程节点0待审批、1审批通过、2已装表、3已归档、-1已驳回。流程操作里有个隐含业务规则需要注意当业扩报装流程推进到“已装表”时系统要自动创建对应客户的电表档案并把电表初始读数写入meter表同时建立customer和meter的关联关系。这一步是抄表流程能够开始的前提。我用一个Service方法完成Transactional(rollbackFor Exception.class) public void completeInstall(Long applyId) { BusinessApply apply businessApplyMapper.selectById(applyId); apply.setStatus(2); // 已装表 businessApplyMapper.updateById(apply); // 创建电表档案 Meter meter new Meter(); meter.setMeterNo(generateMeterNo(apply.getOrgId())); meter.setCustomerId(apply.getCustomerId()); meter.setInitialReading(BigDecimal.ZERO); meter.setStatus(正常); meterMapper.insert(meter); // 关联客户 Customer customer customerMapper.selectById(apply.getCustomerId()); customer.setMeterId(meter.getMeterId()); customerMapper.updateById(customer); }这个功能把“业扩报装”和“抄表核算”两个模块串起来了正好呼应“全流程管理”这个定位。答辩时如果你能画一张业务流程图说明申请单状态每流转一步系统做了哪些联动操作整套系统的完整度就非常高了。5. 常见问题、坑点与答辩准备最后这部分是整篇博文的精华。下面每个问题都是我自己实际踩过或者帮别人排查过的按出现频率从高到低排列。5.1 SpringBoot版本太高引发的一系列问题这是今年我遇到最多的咨询。很多人从网盘里下载的老教程全套是基于SpringBoot 2.x的但自己创建项目时IDEA默认选择了3.x版本结果代码复制进来后full of红叉。典型症状有三个javax.servlet不存在。解决办法是全局把javax替换成jakarta或者直接换回SpringBoot 2.7.x。Java 8不兼容。SpringBoot 3.x要求JDK17起步如果你的电脑只有JDK8项目根本启动不了。解决办法是装JDK17或者降级SpringBoot。部分依赖没有3.x版本。很多小众jar包还是基于2.x开发的升级后找不到对应的groupId/artifactId。我的建议非常明确做毕设一律SpringBoot 2.7.18 JDK8。不是3.x不好而是3.x带来的版本升级负担对毕设来说完全没收益。答辩老师问为什么不用SpringBoot3你可以回答“项目技术选型要保证稳定性生产环境主流仍是SpringBoot 2.x且JDK8的生态更成熟”。这个回答比“我不会”显得专业得多。5.2 MyBatis-Plus与实体类建表SQL“根据Java实体类生成创建表的SQL语句”这个话题不少人在搜。MyBatis-Plus本身不提供自动建表功能但有两个常用方案。方案一用MyBatis-Plus的代码生成器反着走。先建好数据库表再生成实体类这是正向流程也是我推荐的做法。建表SQL手工写一遍然后让代码生成器读取表结构自动生成entity这样实体类字段与表结构一定是完全对应的不需要再处理“实体类和表对不上”的问题。方案二如果你已经写好了实体类想快速得到建表SQL可以自己写一个小工具方法通过反射遍历实体类的字段、类型、注解拼出DDL语句。核心代码如下public static String generateCreateTableSql(Class? clazz) { TableName tableName clazz.getAnnotation(TableName.class); StringBuilder sb new StringBuilder(CREATE TABLE IF NOT EXISTS ) .append(tableName.value()).append( (\n); Field[] fields clazz.getDeclaredFields(); for (Field field : fields) { TableField tf field.getAnnotation(TableField.class); if (tf ! null !tf.exist()) { continue; } String columnName camelToUnderline(field.getName()); String columnType mapJavaTypeToSqlType(field.getType()); sb.append( ).append(columnName).append( ).append(columnType).append(,\n); } return sb.substring(0, sb.length() - 2) \n);; }这个方法在毕设中足够用实际开发还是建议用数据库迁移工具Flyway但这就是进阶话题了。实体类上一定要写清楚TableName和TableField注解尤其是字段名和列名不一致的时候否则自动拼接SQL会出现栏位找不到的错误。5.3 Vue打包放进SpringBoot的细节前后端分离项目最后要部署成一个jar操作本身很简单但有两个点容易出错。第一个是路由模式。Vue Router默认使用history模式这种模式下刷新页面时浏览器会向SpringBoot请求真实路径比如/admin/dashboardSpringBoot返回404。解决办法是Vue Router改用hash模式const router new VueRouter({ mode: hash, routes });改完之后URL会多一个#号但刷新不再404。或者在SpringBoot里写一个controller转发所有未匹配路径到index.html但实现成本高一些hash模式是最省事的方案。第二个是静态资源缓存。前端改完重新npm run build覆盖static目录后浏览器经常还是访问旧的JS文件。我在application.yml里配置了静态资源不缓存效果不错spring: web: resources: cache: period: 0还有个细节记得做把dist目录复制进resources/static之前先清空旧文件避免残留旧JS导致奇怪的问题。我见过一个同学因为没清空新旧两个JS文件同时存在页面一直加载到旧版本的全局变量排查了半天。5.4 答辩高频问题与准备思路答辩决定了项目最终成绩很多项目做得好但讲不清楚很吃亏。我这里罗列几个电力营销系统必然会被问到的问题。为什么不用SSH而用SpringBoot回答思路SSH是XML配置时代的产物SpringBoot通过自动配置和起步依赖大大简化了项目搭建成本同时内嵌Tomcat让部署变成单jar运行。这体现的是工程化效率的提升。你是怎么做权限控制的回答思路登录成功后签发token前端请求携带token后端通过拦截器统一校验再结合自定义注解校验具体接口的权限标识。数据层面按供电所ID做了行级隔离。阶梯电价是怎么实现的回答思路把电价参数表独立出来通过配置驱动计费算法计费用BigDecimal保证精度分段计算各档位电量与金额。遇到并发支付怎么处理回答思路用select for update锁定账单行配合数据库事务保证同一时间只有一个请求能完成支付动作。每个问题准备一个30秒左右的回答不要照读代码要讲清楚“它是什么、为什么这么设计、有什么效果”。我在答辩前的模拟练习中重点就练这几个问题的表述实际答辩效果很好。最后再分享一个小经验整个项目从零到完成千万不要按“先搭框架再写代码”的顺序。正确顺序是先把数据库表设计好然后写一个最小可运行的登录流程再逐步补充抄表、计费、缴费、报装模块。每完成一个模块就立即测试不要攒到最后一起联调。这样到项目后期你的代码库是稳定递增的而不是某个晚上突然堆出几千行代码然后被一堆Bug淹没。电力营销系统这个题目上限很高认真做完无论技术能力还是答辩表现都能让你在整个毕设季里保持从容。