基于Spring Boot的宽带业务管理系统设计与实现攻略

1. 项目概述

1.1 核心需求解析

先说结论：基于Spring Boot的宽带业务管理系统，是这几年Java后端毕业设计里受众最广、延展性最好的选题之一。它的业务场景覆盖了用户管理、套餐管理、业务开通、工单流转、设备管理、缴费续费、报表统计这一整条链路，天然适配Spring Boot + MyBatis Plus + MySQL这套技术栈的完整展示。比起图书管理系统、学生管理系统这类纯CRUD项目，宽带业务系统有明显更高的区分度——它带状态流转、带权限模型、带多角色协作、带时间窗口计算，而这些正好是毕业答辩时最能体现"你确实做过完整系统"的核心证据。

这个选题的另一个优势在于业务模型足够"真"。宽带业务不是抽象概念，而是每个评审老师自己都在用的服务：报装、移机、拆机、故障报修、续费、停机。你不需要额外虚构复杂场景，只需要把现实中的宽带运营流程抽象成业务实体和状态机，就能拿到一个逻辑自洽、功能完整、讲解起来有理有据的系统。对做毕业设计的同学来说，"能讲清楚业务"比"代码写得花哨"重要得多，因为这个阶段评委更关心你能否把一个完整系统的来龙去脉讲明白。

1.2 适合谁来参考

我把这篇攻略的服务对象圈定为三类人：第一类是正在选题或已经开题但还没定技术方案的计算机/软件工程专业本科生，你们需要的是一个可落地、可演示、可讲清的完整项目骨架；第二类是打算用这个项目参加实训、课程设计或找工作做项目复现的同学，你需要理解的不只是代码，还有如何把某个模块包装成"亮点"；第三类是自学Spring Boot但一直只做Demo、没有接触过真实业务状态流转的开发者，这个项目可以帮你补上"从增删改查到业务闭环"这段经验。

如果你完全零基础，还没看完Spring Boot的Hello World，建议先花两周把Spring Boot基础、MyBatis Plus的基本用法、Vue或Thymeleaf的简单页面跑通，再来看这篇攻略。宽带业务系统真正难的点不在单个技术，而在业务逻辑的串联——一个工单从提交到施工到归档，中间涉及五个角色的状态流转，你要明白每一步为什么这么设计。

2. 系统整体设计与技术选型

2.1 为什么选Spring Boot这套组合

Spring Boot能成为毕业设计首选，不是因为它"流行"，而是它解决的问题正好踩中这个阶段的核心痛点：配置简化、起步依赖、内嵌容器、自动装配。你用Spring Boot搭一个Web项目，从新建工程到能跑起第一个接口，最快不到十分钟；换成传统的Spring MVC + XML配置，光是配置Spring、MyBatis、数据源、事务管理器就要写一大堆XML，还没开始写业务代码，热情已经消了一半。

在Spring Boot的系统里，我建议的技术组合是这样的：

这个组合的关键在于"每一个选择都能被答辩时讲清楚"。比如MyBatis Plus，你选择它不是因为偷懒，而是因为项目中宽带套餐的分页检索、条件查询量非常大，用MP的LambdaQueryWrapper可以大幅减少样板代码，而自定义的工单状态流转SQL仍然由你手写，这就兼顾了效率和可控性。Redis也一样——宽带的登录token、页面验证码、套餐缓存都是高频访问数据，放在Redis里能显著降低数据库压力。

2.2 业务架构与角色权限模型

宽带业务管理系统最常见的角色模型是四类：系统管理员负责基础数据维护，包括套餐管理、区域管理、操作员账号分配；营业厅客服负责接待用户，办理新装、移机、缴费、续费业务；装维工程师负责接收工单、上门施工、回传施工结果；普通用户通过Web端或小程序自主查询宽带账号、套餐余量、在线报修。部分学校会要求把"财务人员"角色也拆出来做营收统计，如果你的数据库设计能力允许，可以把缴费记录和报表统计独立成模块。

权限模型我推荐用最经典的RBAC（基于角色的访问控制）：用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。Spring Boot的拦截器里，通过JWT携带的用户ID去查Redis中缓存的权限集合，再和当前请求的接口权限码比对。这里有个关键点：网上很多Demo只校验"有没有登录"，不校验"有没有权限"，这会让你的答辩减分——因为评委随便选个接口就能发现普通用户能调管理员接口的问题。

数据流上，核心主线是"用户申请→客服受理→生成工单→装维施工→归档回执"。宽带账号的状态机建议设计为：待开通、开通中、已开通、停机、销户、故障待修。每个状态都有对应的触发动作和前置条件，比如"已开通"状态只有在装维工程师上传施工完成回执后才会变更，而不是客服手动改状态。"停机"状态必须依赖"账户余额小于0"或"用户主动申请"这两个条件之一。

3. 数据库设计：宽带业务的核心是状态与约束

3.1 核心表结构设计

数据库是整个宽带业务系统的地基。我建议至少设计以下数据表：用户表（含客户信息）、宽带账号表、套餐表、订单表、工单表、缴费记录表、操作员表、角色表、菜单表、区域表。

宽带账号表是核心中的核心，它的字段至少应该包含：宽带账号（唯一索引）、用户ID、套餐ID、开通地址、安装时间、状态（枚举）、上下行速率、关联设备SN、最后缴费时间、到期时间。其中速率和套餐的关系要特别注意：套餐表里存的是"基准速率"，而宽带账号表里存的才是实际的"开通速率"，因为可能存在套餐升速降速的过程，历史速率不能跟着套餐变。

工单表的设计也很有讲究。字段建议包含：工单号（业务编号，格式如GD+日期+序列号）、工单类型（新装/移机/拆机/维修）、关联宽带账号、客户姓名、联系电话、施工地址、受理操作员ID、施工工程师ID、状态（待派单/已派单/施工中/已完成/已回访）、预约时间、实际完成时间、故障描述/施工备注。工单号不要用数据库自增ID，因为答辩演示时自增ID长这样：1、2、3… 你完全讲不清这个ID代表什么，商业系统里业务编号都是带规则的可读编号。

订单表与缴费记录表需要区分开：订单表记录的是"业务办理动作"，比如新装宽带、续费一年；缴费记录表记录的是"资金流水"。两者通过订单ID关联。这一点是答辩时容易出错的地方——很多同学会把订单和缴费混在一张表里，导致一个订单多次缴费时数据逻辑混乱。

3.2 状态机设计：让业务逻辑可视化

状态机是宽带业务系统设计中最能体现功力的部分。用一个简单例子来说：新装工单从营业厅客服创建后，状态是"待派单"；系统管理员或装维队长把工单指派给装维工程师后，状态变为"施工中"；工程师上门施工完成，回传现场照片和施工结果，状态变为"待回访"；客服回访确认信号正常，状态变为"已完成"。每一步的状态变更都要在表里记录"操作人、操作时间、变更前后状态"，也就是增加一张工单流转日志表，这也是答辩时可以主动讲的一个亮点。

实现上，建议在Service层用枚举定义状态，用策略模式或简单的switch分支处理状态流转合法性。不要在前端页面自由修改状态字段——必须走后端的状态流转方法，这样才能在日志表中留下完整链路。我自己做过一个"非法状态流转拦截"的工具类，核心逻辑就是预先配置好状态流转矩阵：Map<当前状态, List<允许变更到的状态>>，流转时先校验再更新。这个实现讲出来，评委立刻知道你不是只会写CRUD。

3.3 索引设计与查询优化

宽带业务系统的查询场景有三个典型：客服按手机号或宽带账号精确查询用户、列表页分页查询工单、月度缴费汇总报表。针对这三个场景，索引设计如下：宽带账号表加唯一索引uk_account（account）；工单表加联合索引idx_order（order_type, status, create_time），这个联合索引能让"按类型+状态筛选工单并排序"非常快；缴费表加索引idx_pay（account_id, pay_time）。

实际开发中容易踩的坑是MyBatis Plus的乐观锁插件。生产环境的宽带账号表建议加version字段做乐观锁，防止两个客服同时修改同一个用户的套餐导致状态错乱。但要注意：乐观锁只对"更新前版本号匹配才能更新成功"的场景有效，如果业务逻辑必须串行执行，比如同一宽带账号的并发续费操作，必须使用数据库行锁（SELECT ... FOR UPDATE）或Redis分布式锁。我这里有个典型的失误案例：某次我测试并发提交两条续费订单，两条都扣款成功但账户余额只加了一次——因为两条请求同时读取了旧余额。后来改成MySQL行锁才解决，这个案例我建议写进论文的"系统实现难点"章节。

4. 核心功能模块实现与分析

4.1 运营核心：宽带业务主流程闭环

宽带业务主流程是用户从申请到开通的全过程管理。我用它来串联系统里的用户管理、套餐管理、订单管理、工单管理四大模块。

以新装宽带为例，完整流程是这样的：

1. 用户在前台页面选择套餐，填写安装地址、联系电话，提交申请；
2. 后台生成"待受理"状态订单，营业厅客服在工单池看到这条申请；
3. 客服电话核实用户信息，确认可安装区域后点击"受理"，系统自动生成宽带账号和初始密码，同时创建一条"待派单"工单；
4. 装维队长（管理员角色）把工单分配给装维工程师；
5. 工程师上门安装，填写工单处理结果（光衰值、设备SN号、施工照片URL），状态流转为"待回访"；
6. 客服回访确认无误，状态流转为"已完成"，宽带账号状态同步变更为"已开通"。

这个闭环实现的关键在于事务控制。订单创建、宽带账号生成、初始工单创建这三个操作必须放在同一个@Transactional事务里，任何一步失败都回滚，避免出现"订单没了但宽带账号已生成"的脏数据。我在项目里专门做了一个创建宽带业务的方法链路，避免多次IO操作在事务边界外改动数据库——这是答辩时的加分细节。

4.2 工单状态流转与派单逻辑

设计工单状态机时，我用工单类型（新装、移机、拆机、报修） × 当前状态 × 操作动作建立了一张流转矩阵表。新装工单的可流转路径是：待派单→施工中→待回访→已完成，同时允许从待派单撤销为已取消；报修工单的路径则是：待派单→诊断中→施工中→待回访→已完成，多了一个诊断环节，因为维修场景需要先远程诊断再决定是否上门。这里要注意：所有的状态流转统一走service层的方法，如 assignOrder()、startWork()、completeWork()，而不是让前端直接改字段。

派单逻辑我采用了一个相对简单的策略：工单创建后默认进入待派单池，系统管理员可以手动指定工程师，也可以使用"自动派单"——按照工程师当天的未完成工单数量做负载均衡，选择工作量最少的工程师。自动派单的算法并不复杂，一个按area_id + status分组的SQL统计就能搞定，但放在答辩演示环节，点击"自动派单"时看到系统真的分配给工作量少的工程师，视觉效果和代码讲解力都很强。

回执上传环节建议接一个本地文件存储或对象存储服务：工程师在移动端上传施工照片，前端通过后端预签名接口获取可访问URL，存入工单表的photo_url字段。不要直接把图片以Base64字符串存进数据库——这种数据可读性差且非常占用存储，答辩时容易被问住。

4.3 宽带账号生命周期管理

宽带账号的状态变化是整个系统的"业务晴雨表"。生命周期设计为：创建（预开通）→ 激活（施工完成）→ 正常使用（期间可以升级套餐）→ 欠费停机（余额不足自动触发）→ 恢复正常（续费后自动复机）→ 销户（用户申请拆机）。

欠费停机和自动复机这两个功能，建议做成一个定时任务（Spring @Scheduled）。每天凌晨3点扫描所有宽带账号，把到期时间和当前时间比对，到期超过0天但未续费状态的账号自动置为停机，同时往缴费记录表插入一条"停机记录"；用户在营业厅或在线续费成功后，后台检测到该账号有最新缴费单且状态为停机，自动恢复为正常。这个"自动+手动"双通道的设计，比你手动在管理后台点按钮改状态更接近真实业务系统。

细节体验上，套餐到期前3天给用户发送短信提醒，这个在毕业设计中可以用模拟短信接口替代（控制台打印即可）。但要注意：定时任务的触发时间、执行逻辑、执行结果都要有日志记录，否则答辩时一旦现场数据没对上，你完全没有排查线索。

4.4 多条件分页检索与导出

宽带业务管理系统的典型管理场景是"筛数据、看列表、导Excel"。客服需要按宽带账号、手机号、用户姓名、区域、套餐类型、创建时间段组合检索订单。MyBatis Plus的分页插件PagionationInterceptor 配置非常简单，核心是构造LambdaQueryWrapper时动态拼接条件。以工单查询为例：

public Page<WorkOrderVO> queryOrderPage(Page<WorkOrderVO> page, OrderQueryDTO dto) { LambdaQueryWrapper<WorkOrder> wrapper = Wrappers.lambdaQuery(); wrapper.like(StringUtils.isNotBlank(dto.getAccount()), WorkOrder::getAccount, dto.getAccount()) .eq(dto.getOrderType() != null, WorkOrder::getOrderType, dto.getOrderType()) .eq(dto.getStatus() != null, WorkOrder::getStatus, dto.getStatus()) .between(dto.getStartTime() != null && dto.getEndTime() != null, WorkOrder::getCreateTime, dto.getStartTime(), dto.getEndTime()); // 联表查询后手动组装扩展字段 return workOrderMapper.selectPageWithJoin(page, wrapper); }

关于分页有一个很常见的坑：MyBatis Plus的count优化和JOIN联表冲突。如果你直接selectPage时让MP去自动count，碰到多表JOIN时生成的count SQL可能带了join和distinct，性能奇差。更稳妥的做法是手写一条专用的count SQL。导出功能我建议用EasyExcel而不是POI原生的方式，因为EasyExcel内存占用极小且API更友好，答辩演示时即使导出一万条数据也不卡。

4.5 缓存优化与分布式会话

Spring Boot集成Redis在这个项目里我规划了三个用途：会话管理、业务数据缓存、验证码存储。

会话管理：使用Redis存储JWT的token白名单。用户登录成功后，拦截器校验JWT签名和有效期，同时去Redis校验该token是否在有效白名单中；用户修改密码或管理员强制下线时，删除Redis中对应token即可实现"失效"效果。这比纯无状态JWT更安全，也是答辩时能讲的一个安全细节。

业务缓存：宽带套餐列表和区域列表属于高频读取且变化频率极低的数据，非常适合缓存。用Spring Cache注解@Cacheable(cacheNames = "packageList")即可，缓存失效策略设置为"修改套餐时主动清除该key"而不是设置固定过期时间——否则会出现后台改完套餐，前台半小时后才生效的尴尬情况。宽带账号的详情缓存同理，续费或状态变更时主动删除缓存key。

Redis在Windows环境下没有官方支持，但开发期可以用Memurai或者Docker Desktop跑一个Redis容器。如果你不想引入Redis这一层复杂度，学校允许的话也可以用Caffeine做本地缓存，效果接近，但Redis能体现在简历上，长远看收益更高。

5. 实战步骤：从零搭起一个可演示的项目

5.1 项目初始化和基础工程结构

第一步，用Spring Initializr创建项目骨架。我推荐通过IDEA自带的New Project → Spring Initializr来创建，依赖选择：Spring Web、Validation、MyBatis Plus Framework（也可以用官网的依赖自行引入）、MySQL Driver、Lombok、Redis。版本建议Spring Boot 2.7.x搭配JDK 1.8或JDK 11，不要盲目上Spring Boot 3.x——很多教学环境、答辩机器上的JDK版本不支持，而且Spring Boot 3的环境要求和不兼容问题会让毕业设计徒增风险。

工程结构上，我习惯用标准的分层包结构，但会区分"业务包"和"基础设施包"。业务包按模块划分：module/user、module/order、module/workorder、module/package、module/payment；基础设施包里放config、security、common（统一返回结果、异常处理）、utils。这种结构答辩时往投影上一放，评委一眼就能看清你的系统边界。

项目启动后第一时间做三个动作：配置跨域（如果前端用Vue独立部署）、配置统一返回结果（Result类，code/message/data结构）、配置全局异常处理器。这三个动作极其重要——所有接口的返回值格式统一，意味着前端不用做各种特殊处理，也意味着答辩演示时不会因为某个接口报错返回500页面而显得狼狈。

5.2 核心配置与JWT鉴权落地

application.yml的配置需要注意几个细节。多环境配置推荐拆成application-dev.yml和application-prod.yml，答辩演示用dev环境即可；MyBatis Plus的map-underscore-to-camel-case设置为true，自动映射下划线字段到驼峰属性；逻辑删除配置全局逻辑删除字段deleted，所有删除操作自动改成UPDATE，这是避免数据误删的最简单有效手段。

JWT方案我用的是jjwt库，核心逻辑就三步：登录成功后生成token（把用户ID、用户名、角色编码放进去），设置过期时间（建议2小时，活跃用户登录一次足够）；拦截器解析token，如果解析成功再查一次Redis白名单；角色权限校验用注解@RequiresRole("ADMIN")或自定义HandlerInterceptor去匹配权限码。这里我强烈建议在当前项目里加上方法级的@PreAuthorize权限注解，再开@EnableGlobalMethodSecurity，比纯手工判断if(user.getRole()=="ADMIN")要规范得多——答辩时提到"Spring Security + JWT组合实现无状态接口鉴权"，这个技术点就足够撑起三分之一的答辩时间。

5.3 工单模块核心代码实现演示

工单模块是答辩时的重点讲解对象，我来演示一段核心的"新装工单受理并生成宽带账号"的Service代码，这是整个系统最复杂也最有代表性的一处逻辑：

@Transactional(rollbackFor = Exception.class) public WorkOrderDTO acceptNewOrder(OrderAcceptDTO dto) { // 1. 校验订单是否存在且是待受理状态 Order order = orderMapper.selectById(dto.getOrderId()); AssertUtil.isTrue(order != null && order.getStatus() == OrderStatus.PENDING, "订单不存在或已受理"); // 2. 幂等校验：同一订单不能重复创建工单 Integer count = workOrderMapper.selectCount( Wrappers.lambdaQuery(WorkOrder.class).eq(WorkOrder::getOrderId, order.getId())); AssertUtil.isTrue(count == 0, "该订单已生成工单，请勿重复操作"); // 3. 生成宽带账号（规则：区域码 + 日期 + 自增序号） BroadbandAccount account = new BroadbandAccount(); account.setAccountNo(generateAccountNo(dto.getAreaCode())); account.setUserId(order.getUserId()); account.setPackageId(order.getPackageId()); account.setStatus(AccountStatus.PRE_ACTIVE); account.setInstallAddress(dto.getInstallAddress()); broadbandAccountMapper.insert(account); // 4. 创建工单 WorkOrder workOrder = new WorkOrder(); workOrder.setOrderId(order.getId()); workOrder.setAccountNo(account.getAccountNo()); workOrder.setOrderType(OrderType.NEW_INSTALL); workOrder.setStatus(WorkOrderStatus.PENDING_DISPATCH); workOrder.setCustomerName(order.getCustomerName()); workOrder.setContactPhone(order.getContactPhone()); workOrderMapper.insert(workOrder); // 5. 更新订单状态 order.setStatus(OrderStatus.ACCEPTED); orderMapper.updateById(order); // 6. 记录操作日志 operationLogService.record("客服受理新装订单", "OrderId=" + order.getId()); return workOrderMapper.selectWorkOrderDetail(workOrder.getId()); }

这段代码有三个值得在答辩时展开的细节：事务注解保证多表操作的一致性；幂等校验防止重复提交；业务编号生成规则体现你考虑了真实场景的编码需求。我还在类里封装了一个AssertUtil断言工具类，统一抛出带业务码的异常，配合全局异常处理器返回友好提示。

5.4 前端对接与演示准备

前端我推荐Vue 3 + Element Plus，没有时间学前端的话，用Thymeleaf模板引擎配合Bootstrap也能完成所有演示页面，只是交互效果上差一些，但胜在省时间。如果你的毕业设计时间还剩下3-4周，我建议用Vue做——因为演示时的"响应式表格刷新、模态框提交表单、状态标签颜色变化"这些交互元素，比静态刷新页面更有说服力。

演示环境的准备有几个的重要细节：提前把数据库初始化数据准备成一份"可直接演示"的数据，包括至少5个不同状态的宽带账号、3个待派单工单、2条今天的缴费记录；准备一个测试用户账号和两个不同角色的后台账号，防止演示时现场注册流程卡住；把前端打包好部署在Nginx或直接嵌入Spring Boot的static目录下。有一次我在答辩现场演示在线报修功能，结果网络受限前端资源加载不出来，后来学乖了，所有前端资源都打了本地包，一步到位。

6. 常见问题与排查技巧实录

6.1 典型Bug：事务失效与状态错乱

问题现象：客服受理订单后，刷新页面发现宽带账号已生成，但工单记录消失了；或者工单状态显示施工中，但宽带账号还是"预开通"状态。

排查思路：先查Spring事务是否生效。最常见的失效原因是类内部方法自调用导致AOP代理失效，比如Service里一个方法A调用同类方法B，B上有@Transactional但不会生效，因为事务是通过代理对象拦截的，而this.method()调用走的是原对象而非代理。解决办法是拆分Service或使用AopContext.currentProxy()，最干净的做法是让控制器层只调用一个事务方法，事务方法内部不调同类事务方法。

另一个常见错误是状态流转校验不到位。我刚做这个项目时，工程队直接在数据库里把工单状态改成了"已完成"，绕过了Service层的状态机，导致宽带账号状态没有联动更新。后来我在工单状态变更的Service方法里加了显式校验：只有当前状态等于"待回访"才允许改为"已完成"，并且在改状态的同时去更新宽带账号状态——这两个操作放在同一个事务里，从根上防止了状态错乱。

6.2 经典坑：Redis缓存与数据库不一致

问题现象：后台修改了套餐价格，前台宽带商城页面刷新后价格没变。

排查思路：这个问题的根源是缓存更新时机不对。我之前用的是"30分钟过期"策略，但套餐修改是低频操作，等缓存自然过期的时间太长。正确做法是在修改套餐的Service方法里，事务提交后主动执行缓存删除操作，即@CacheEvict(cacheNames = "packageList", allEntries = true)。更精细的做法是通过Spring的@CachePut在修改操作后把最新套餐列表重写进缓存，避免在下次查询请求到来时因为缓存未命中而产生短暂的空窗期。

关于缓存还有一个隐蔽问题：Redis的key前缀设计。如果多个环境共用一套Redis，keys容易冲突；建议统一用项目名前缀+业务模块前缀，比如bbms:package:list。此外，本机Redis挂掉后系统是否还能正常运行？建议给Redis操作做降级处理，Redis异常时直接放行请求走数据库，而不是因为缓存组件异常导致整个业务暂停——这也是生产系统里很关键的容错思想。

6.3 答辩高频问题应对

整理几个答辩评委必然会问的高频问题，提前备好答案：

Q1：为什么选择Spring Boot而不是传统SSM？答：Spring Boot通过自动配置和起步依赖大幅降低了配置成本，让开发者更专注于业务逻辑；同时它基于Spring生态，底层管理Bean的能力和SSM一脉相承，还保留了快速集成的优势。如果深入问，可以从starter机制和自动配置原理出发，解释spring.factories或AutoConfiguration.imports的加载流程。

Q2：系统如何保证并发场景下数据一致？答：核心业务操作放在数据库事务中，涉及多表更新的步骤统一提交或统一回滚；宽带账号状态变更使用乐观锁或行锁控制并发冲突；高频访问数据通过Redis缓存降低数据库压力，缓存更新采用主动删除策略保证一致性。这个问题最好能现场画一个"请求从Controller到Service到Mapper再到Redis"的调用链图，讲得很直观。

Q3：系统中有哪些业务亮点？答：一是工单状态机设计，用流转矩阵约束非法操作；二是带规则的业务编号生成，可读性好；三是自动派单策略根据工程师工作量动态分配；四是欠费自动停机和续费自动复机。结尾可以说"这些设计参考了真实运营商系统的核心思路"，比只说CRUD强得多。

6.4 时间规划建议

最后给正在赶毕设的同学一条实际的时间线参考：第一周搭建项目骨架、数据库表、统一返回结构、用户登录注册；第二周完成套餐、宽带账号、订单模块；第三周完成工单流转、装维、缴费模块；第四周做前端界面美化、报表统计、定时任务、写论文和准备PPT。如果想在答辩前稳妥起见，提前一周开始录屏演示脚本，把核心操作录成视频备用——省得答辩当天系统突然出问题手忙脚乱。数据库初始化数据建议写成一个DataInitializer类，在项目启动时自动插入，保证任何环境跑起来都有数据可看。

7. 实操总结与扩展建议

做宽带业务管理系统这个项目，给我最大的体会是：**毕业设计拿高分的分水岭，不在于用了多新的技术，而在于你能否把业务逻辑讲得闭环、把数据流转梳理清楚。**一个账号从申请到开通，订单、工单、账户、缴费四条线的状态联动，每一条链路都要说得通、演示得出来，这比堆砌一堆微服务组件但业务讲不通要强得多。

如果你做完基础版本还有余力，我给你三个扩展方向，按性价比排序：第一，引入ECharts做数据可视化大屏，展示区域宽带覆盖统计、当月新增用户趋势、工单完成率，这个对视觉冲击力提升极大而且不复杂；第二，给系统增加一个简单的模拟短信网关模块，对接阿里云短信或本地模拟，让欠费提醒和开通通知自动下发，完整性提升一个档次；第三，用WebSocket做工单实时通知，装维工程师的移动端页面能在新工单派发时收到实时弹窗提醒，这也正好符合热词里"Spring Boot集成WebSocket yml配置"相关的技能点——把yml层的websocket相关配置单独分环境管理，避免不同环境连不上消息服务导致功能失效。

还有一个说了很多次但值得反复强调的建议：从项目一开始就写开发日志，记录每个模块的实现方案、遇到的问题、解决思路，最后整理成论文的"系统设计"和"系统实现"章节时，你会发现论文写作根本不需要重新回忆。开发日志里的一句话，比如"工单状态流转遇到Service自调用导致事务失效，后通过拆分Service解决"，就是一篇项目论文里"实现难点"部分最真实的素材。

最后留一句话做项目复盘：**做宽带业务管理系统，做的不只是技术演示，更是对未来业务数字化的完整思考。**把思路理清，把每一步说透，这个项目就能成为你走向职场的第一块坚实跳板。