企业官网建设流程全解析

宽带业务管理系统，听起来就是一套再普通不过的增删改查。但你真把一个营业厅的日常业务捋一遍就会知道：开户要签套餐、缴费要走账务、到期要提醒、欠费要停机、移机拆机都有状态流转，中间还有装维工单要派发。这套东西如果用SpringBoot+Vue从零写出来，涉及的其实不只是CRUD，而是实实在在的业务建模、状态机设计、权限控制和前后端联调问题。我最近整理了一套完整的宽带业务管理系统源码，后端SpringBoot+MyBatis+MySQL，前端Vue，所有模块都跑通了，这篇文章就把它掰开揉碎讲清楚：从数据库表设计到核心业务流程落地，从后端Service层到前端页面路由，再到源码拿到手之后怎么改成自己能用的项目。适合正在做JavaWeb课程设计、想要一份完整管理系统项目的同学，也适合第一次用SpringBoot+Vue前后端分离做实战练手的人。

1. 宽带业务系统到底在“管”什么：需求梳理与业务边界

做管理系统第一步不是写代码，而是把业务流程看透。宽带业务的本质，是“用户与运营商之间的服务合同持续履约”：用户申请一条宽带线路，运营商负责安装、提供网络服务，用户按周期支付费用。这就决定了系统管理的核心不是设备，而是“账户”和“订单”。

1.1 从营业厅到后台：业务单据与资费状态流转

一个典型的宽带业务场景是这样的：用户在营业厅办理宽带开户，选择套餐（比如300M单宽带、融合套餐），留下客户资料，系统生成一个“开户工单”。装维师傅拿着工单上门安装，安装完成后在系统里回单。回单之后，宽带账户正式变成“使用中”状态，同时开始计费。每个月生成账单，用户缴费后更新账务记录。如果到期没续费，账户进入“欠费停机”状态，再往后可能就销户了。

所以这套系统里最核心的表，是客户表、宽带账户表、套餐表、工单表、账单表、缴费记录表，外加系统登录用的用户表和角色权限表。和普通库存管理系统最大的区别在于：宽带账户有一个随生命周期变化的状态字段，而且这个状态不是用户手动随便改的，而是经过一系列业务动作之后自然流转过去的。

很多人拿到这类项目会觉得表太多了记不住，实际上你把它拆成两条线就清楚了：

• 资产线：客户 -> 宽带账户 -> 套餐，描述“谁装了多少钱的宽带”。
• 流水线：工单 -> 账单 -> 缴费记录，描述“这个宽带干了什么事、花了多少钱”。

业务动作要么打在资产线上，要么打在流水线上，最后通过宽带账户ID关联起来。这是整个系统设计的出发点，也是数据库表结构规划的底层逻辑。

1.2 这套技术组合为什么合适

SpringBoot+Vue前后端分离的组合在这个场景里算是最舒服的选择。SpringBoot把配置、内嵌服务器、依赖管理全包了，适合快速把后端服务跑起来；MyBatis负责SQL控制，宽带业务的账单、统计查询经常需要手写复杂SQL，用MyBatis比JPA更直观可控；MySQL存储关系数据；Vue做页面交互，表格、表单、弹窗这类管理后台交互正好是它的强项。

我见过不少同学用传统JSP+Servlet做这类系统，不是说不行，但前后端代码耦合在一起，页面逻辑与业务逻辑互相牵制，后期扩展很痛苦。用Vue把前端页面拆成组件之后，管理后台的体验会好很多，而且这套技术栈出去找工作也通用。

2. 数据库建模：把计费和工单状态“钉死”在表设计里

这一节是整个项目最值得细看的地方。很多看似跑通了的宽带系统，一遇到续费、停机、换套餐的业务就逻辑混乱，根子都在表设计时没有把状态和关联关系想清楚。

2.1 核心表结构与字段取舍

我用实际代码来说明表结构。以下是建表SQL的关键部分：

CREATE TABLE customer ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '客户ID', customer_name VARCHAR(50) NOT NULL COMMENT '客户姓名', phone VARCHAR(20) NOT NULL COMMENT '联系电话', id_card VARCHAR(18) COMMENT '证件号码', address VARCHAR(200) COMMENT '安装地址', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE package ( id BIGINT PRIMARY KEY AUTO_INCREMENT, package_name VARCHAR(50) NOT NULL COMMENT '套餐名称', bandwidth_mbps INT NOT NULL COMMENT '带宽(Mbps)', monthly_fee DECIMAL(10,2) NOT NULL COMMENT '月租金额', cycle_days INT DEFAULT 30 COMMENT '计费周期天数', status TINYINT DEFAULT 1 COMMENT '1启用 0停用' ); CREATE TABLE broadband_account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, account_no VARCHAR(32) NOT NULL UNIQUE COMMENT '宽带账号', customer_id BIGINT NOT NULL COMMENT '客户ID', package_id BIGINT NOT NULL COMMENT '当前套餐ID', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待安装 1使用中 2欠费停机 3已销户', install_address VARCHAR(200), balance DECIMAL(10,2) DEFAULT 0.00 COMMENT '账户预存款余额', expire_date DATETIME COMMENT '到期时间', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

几个容易被忽略的细节：

• account_no必须唯一，这是宽带账号，业务上天然具有唯一性。把它设置为唯一索引，可以在并发开户时从数据库层面兜底，防止重复开户。
• package_id是存当前套餐ID。业务上需要保留“开户时套餐的历史快照”，账单明细表里还要冗余一份套餐名称和月租金额。因为套餐价格会变，你不能两个月后查账时发现以前的价格被改掉了。
• status字段用TINYINT数字类型，不要用字符串枚举。MySQL对数字的索引效率更好，业务代码里写常量映射也比散落的字符串更安全。

2.2 工单与账单：业务动作的“流水账”

工单表记录开户、续费、移机、拆机等操作，账单表记录每个计费周期的费用：

CREATE TABLE work_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, account_id BIGINT NOT NULL, order_type TINYINT NOT NULL COMMENT '1开户 2续费 3移机 4拆机', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待处理 1已完成 2已取消', content VARCHAR(500), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, finish_time DATETIME ); CREATE TABLE bill ( id BIGINT PRIMARY KEY AUTO_INCREMENT, account_id BIGINT NOT NULL, bill_month VARCHAR(7) NOT NULL COMMENT '账期，如2025-03', amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0未缴 1已缴', pay_time DATETIME, UNIQUE KEY uk_account_month (account_id, bill_month) );

这里我特别想强调bill_month和(account_id, bill_month)唯一索引。账单是按账期生成的，一个账户一个月只允许存在一张账单。如果不加唯一索引，定时任务和用户操作同时触发时可能出现同一账号同一个月生成两条账单，账就对不上了。这种隐藏问题在开发环境很难发现，一到生产环境有并发压力就开始冒出来。

2.3 状态机与“欠费停机”的自动流转

宽带账户的状态不是孤立的，业务规则驱动它流转：

• 待安装：开户工单创建时进入，装维回单后变成使用中。
• 使用中：到期未续费自动变成欠费停机。
• 欠费停机：补缴费用后恢复为使用中；超过一定时间（比如90天）未处理则销户。

自动状态变更建议用一个定时任务来扫描，而不是写在前端操作里。原因很简单：欠费停机不依赖用户有没有来营业厅，它是由时间驱动的。用Spring Boot自带的scheduling注解就能实现，不需要额外引入框架：

@Component public class AccountStatusSchedule { @Scheduled(cron = "0 15 2 * * ?") public void autoStopDueAccounts() { // 查询 expire_date 小于当前时间且状态为使用中的账户 // 批量更新状态为 2（欠费停机） // 同时生成提醒记录或发送通知 } }

定时任务里只负责扫描和更新状态，具体校验逻辑仍然放在Service层，避免多个入口操作状态时逻辑不一致。

2.4 MyBatis映射层里容易踩的坑

用MyBatis操作多表关联，最容易出的问题有两个：

第一个是resultMap的嵌套映射写错。查出宽带账户时关联客户和套餐信息，如果直接返回实体对象，MyBatis会要求你配置好关联映射：

<resultMap id="AccountDetailMap" type="BroadbandAccount"> <id column="id" property="id"/> <result column="account_no" property="accountNo"/> <association property="customer" javaType="Customer"> <id column="cid" property="id"/> <result column="customer_name" property="customerName"/> <result column="phone" property="phone"/> </association> <association property="pkg" javaType="Package"> <id column="pid" property="id"/> <result column="package_name" property="packageName"/> <result column="monthly_fee" property="monthlyFee"/> </association> </resultMap>

SQL查询时注意给关联字段起别名，否则列名冲突会让客户ID覆盖账户ID，查出来的数据张冠李戴。我当时调试这个问题花了整整一个晚上，最后打印SQL才发现是列名重复了。

第二个是分页插件和嵌套查询的兼容性问题。如果用了PageHelper做分页，SQL里又写了嵌套子查询，在某些版本下会产生count语句解析错误。建议多表分页查询时统一用JOIN写单层查询，避免深度嵌套子查询，分页更稳，执行效率也更好。

3. 后端核心逻辑落地：开户、续费、拆机与权限控制

数据库设计好后，后端的重点就放在Service层。Controller层只是参数接收与返回，真正的业务规则、事务控制、状态流转全在Service层里。

3.1 业务核心代码：开户与续费的完整逻辑

开户流程不是简单的“插入一条账户记录”，它至少要完成四件事：创建客户、创建宽带账户、生成开户工单、生成首期账单。这四步必须在一个事务里完成，任何一步失败都要整体回滚。

@Service public class BroadbandAccountService { @Transactional(rollbackFor = Exception.class) public void openAccount(OpenAccountRequest request) { // 1. 创建或查询客户 Long customerId = saveCustomer(request.getCustomer()); // 2. 创建宽带账号 BroadbandAccount account = new BroadbandAccount(); account.setAccountNo(generateAccountNo()); // 按规则生成唯一账号 account.setCustomerId(customerId); account.setPackageId(request.getPackageId()); account.setStatus(0); // 待安装 account.setExpireDate(calcExpireDate(request.getPackageId())); accountMapper.insert(account); // 3. 生成开户工单 WorkOrder order = new WorkOrder(); order.setAccountId(account.getId()); order.setOrderType(1); order.setStatus(0); workOrderMapper.insert(order); // 4. 生成首月账单 generateMonthlyBill(account.getId(), request.getPackageId()); } }

generateAccountNo()在实际项目中最好做成一个独立服务，用日期加随机数，或者利用数据库唯一索引重试机制生成，避免并发重复。好多同学喜欢用UUID直接截取前几位当账号，这样出来的号码用户根本记不住，营业厅实际使用也难操作。建议用时间戳后六位加三位随机数，加上业务前缀，看起来更正规。

续费的逻辑是：新增一笔缴费记录，延长账户的expire_date，同时把当前账期账单标记为已缴。如果账户处于“欠费停机”状态，续费后要恢复为“使用中”状态。这里要特别小心：续费的金额和当前账单金额不一定相等。因为用户可能提前续费，也可能补缴欠款，所以缴费记录要记录实收金额，账单和缴费记录之间是“多笔缴费冲抵一张账单”的关系。

3.2 登录认证与权限控制：JWT还是Session

宽带业务系统有营业员、管理员、装维人员等角色，权限必须区分。单体应用传统上用Session，前后端分离后用JWT更顺手。

JWT的核心逻辑是：用户登录成功后，后端生成一个带过期时间的令牌，前端把令牌存起来，每次请求在Authorization头里带上。后端用一个拦截器校验令牌，解析出用户角色信息。这样做的好处是后端无需保存会话，天然支持多实例部署。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token)) { throw new BusinessException("未登录或登录已过期"); } LoginUser loginUser = JwtUtil.parseToken(token); request.setAttribute("loginUser", loginUser); return true; } }

拦截器里解析令牌后，把用户信息放到请求上下文里。后续Service层直接从请求上下文获取当前用户，就能实现“营业员只能操作自己所在营业厅的数据”这样的权限过滤。JWT要重点处理的一个问题是过期时间不能设置太长也不能太短，管理后台一般设24小时比较合适。要不要做自动续签，看需求，课程设计层面不做也问题不大。

3.3 数据权限与多营业厅隔离

很多宽带业务管理系统实际部署时会有多个营业厅，每个营业厅的数据要隔离。实现方式有两种：一个营业厅一套数据库太笨重，通常只用一张“营业厅”表，业务表里加office_id字段。查询时默认带上当前用户所属营业厅的过滤条件，这样既保证了数据隔离，又不影响统计汇总。

后端做数据权限时，我建议把当前用户上下文封装成一个ThreadLocal对象，在拦截器里初始化，这样Service层写代码时可以直接调用，不需要每个接口都从Controller传参。请求结束时要记得清理ThreadLocal，否则线程池复用时用户数据会串到下一次请求里，这是非常隐蔽的问题。

4. 前端Vue页面搭建：从登录到业务单据的闭环

前端部分我按Vue2+Element UI的路子来讲，这也是目前这类完整源码里最常见的技术方案。如果你用的是Vue3+Element Plus，思路完全一样，只是部分语法有差异。

4.1 页面结构划分与路由设计

管理后台的页面结构是典型的“左侧菜单栏 + 右侧内容区”。路由可以分成两大部分：

• 登录页：独立路由，/login，不进入整体布局。
• 主页：/下面挂载客户管理、套餐管理、开户办理、工单管理、账单缴费、统计报表等子页面。

路由守卫负责登录校验。每次路由跳转前，检查本地存储里有没有JWT令牌。没有就强制跳转登录页：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.path !== '/login' && !token) { next('/login'); } else { next(); } });

这里有个细节：不能只在访问“需要登录的页面”时判断，因为有些人会直接通过地址栏访问/login。我做的时候还加了反向判断，如果用户已经登录还访问/login，直接跳回主页，体验会好很多。

4.2 封装axios请求：统一处理Token与错误码

前端发送请求时，如果每个页面都手写Headers、手写错误提示，代码会非常乱。正确做法是把axios封装成一个统一实例，在请求拦截器里加Token，在响应拦截器里统一处理异常：

import axios from 'axios'; const service = axios.create({ baseURL: '/api', timeout: 10000 }); service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = token; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { this.$message.error(res.message); if (res.code === 401) { router.push('/login'); } return Promise.reject(new Error(res.message)); } return res; }, error => { this.$message.error('网络异常'); return Promise.reject(error); } );

后端返回给前端的统一响应结构要有约定，一般用{ code: 200, data: ..., message: "操作成功" }这种格式。前端拿数据时直接res.data就是业务数据，不会有歧义。这套联动需要前后端配合设计，源码项目里通常已经定好了，二次开发时保持格式一致是最基本的。

4.3 表格、表单与状态标签的页面化处理

宽带的业务页面，核心交互是“表格展示 + 弹窗表单操作”。这里有几个很实用的小经验：

• 状态字段不要直接显示数字。后端返回status: 1，页面上如果直接显示“1”，用户根本看不懂。建议在Vue里定义一个映射对象，用computed方法渲染成文字标签，配合Element UI的el-tag控制不同状态的颜色。
• 开户表单要有关联联动。选择套餐后，自动展示套餐的月租金额和带宽信息，这样营业员操作时可以减少输入错误。实现上监听套餐下拉框的change事件，从套餐列表数据里找到对应对象，填充到表单展示区。
• 表格操作列要按状态控制按钮显隐。比如“续费”按钮只对“使用中”和“欠费停机”状态的账户显示；“拆机”按钮只对“使用中”状态显示。这样可以避免用户误操作，也在交互层面保护了业务规则。

前端还有个容易忽略的地方：列表数据的刷新时机。开户成功后，打开工单管理页面，看到的还是旧数据。要在页面跳转或弹窗关闭后重新调用加载列表的方法，或者用activated钩子配合keep-alive在页面激活时自动刷新数据。很多Demo源码里这一步做得不到位，你拿到手之后要特别注意检查。

5. 跑通完整源码后必须检查的几个点：从联调到二次开发

源码给你了，怎么跑起来、怎么改成自己的项目，这一步卡住的人其实很多。大部分问题不是代码跑不通，而是不知道启动顺序和几个关键配置位置。

5.1 本地启动顺序与环境配置

以我整理的这套为例，完整启动流程是：

1. 安装并启动MySQL，执行项目里的.sql脚本初始化数据库。
2. 配置后端的application.yml，修改数据库地址、账号、密码。不同机器上的数据库密码不一样，这一步几乎必改。
3. 启动后端SpringBoot项目，确认控制台没有报错，端口正常启动。
4. 进入前端目录，执行npm install安装依赖，然后npm run dev启动开发服务器。
5. 浏览器访问前端开发服务器地址，用系统初始化管理员账号登录。

需要注意的有两个点：

• 前端开发服务器访问后端：Vue开发环境默认通过Vite或Webpack的服务器转发接口请求。配置baseURL: '/api'之后，还要在vite.config.js里配置服务器转发规则，把/api开头打给后端地址。不配置会报跨域错误。
• 数据库文件编码：导入SQL文件时尽量用命令行或数据库管理工具，并确认字符集是utf8mb4。用记事本打开SQL再复制粘贴执行，偶尔会出现乱码问题，原因就是文件编码和数据库连接编码不一致。

5.2 把Demo改造成自己项目的八个替换点

拿到任何一套完整源码，如果没有自己的需求，只是一个Demo。要把它变成能写进简历、能用于答辩的项目，下面这些地方必须改：

写论文或文档时，你可以把这些地方标注为“项目优化改进点”。比如“使用BCrypt对密码进行加密存储”，这比单纯把功能跑通显得专业得多。

5.3 基于这套系统的扩展方向

如果你做完基础功能还想再往前走一步，我比较推荐以下几个方向，工作量适中、效果明显：

• 消息通知模块：到期提醒、欠费通知，从单纯的系统展示变成主动推送，可以在“营业厅引导”的场景里补上短消息或站内消息。
• 数据可视化看板：统计各套餐用户数、月收入趋势、欠费占比，用图表组件画大屏。这类内容放到毕业设计展示环节非常加分。
• 多角色工作台：装维人员登录后只看到自己的工单列表，营业员看到办理业务，管理员看到统计报表。路由仍然保留，页面层面做菜单权限控制。

我自己做这类系统时最深的体会是：业务管理系统难的不是某个技术点，而是把“业务规则”翻译成“代码逻辑”。比如欠费停机那个状态机，你用if-else写也能跑，但它散落在各个Service方法里，出了问题只能一点点查。把它建模成状态加动作的流转，之后每一次业务变更，你只改一张状态流转表就够了。

最后分享一个小技巧：给账户表加一个remark字段，每次状态变更或关键操作都把原因写进去。比如“2025-03-01 自动停机，欠费72.5元”。表面上看只是多一个备注字段，但系统在线上跑一个月后，你排查账务纠纷时就会感谢它。这比任何日志文件都直观，也算是这类系统里最实用的小设计。