JSP+SSM电信客户话费计费系统：从数据库到计费逻辑全解析-代码聚汇网

JSP+SSM电信客户话费计费系统：从数据库到计费逻辑全解析

lloydsheng·2026-08-29·阅读 23 GEO检测（免费）

SSMJSP电信计费系统

|难度：普通|阅读约 44 分钟

做计算机毕业设计，最怕的不是功能做不完，而是选了一个自己压根说不清原理的题目，最后答辩被老师一问三懵。这个“JSP基于SSM的电信客户话费计费系统”属于典型的Java Web方向老牌课题，技术栈非常固定：JSP做页面、Spring管对象、SpringMVC管请求路由、MyBatis管数据库交互。它覆盖面广，从表结构设计到业务逻辑再到前端展示全都有，非常适合用来展示你对一个完整业务系统的掌控能力。

这篇文章我按自己当年做同类项目的思路来写，从整体设计、数据库建模，到计费核心逻辑的实现，再到排查坑点，一步步拆给你看。文章里所有代码和SQL都是可以直接抄作业的级别，你只需要根据自己数据库的字段习惯微调即可。

1. 项目整体设计与技术选型拆解

1.1 为什么是JSP+SSM这套组合

很多人在选题时会纠结：Spring Boot都用得这么普遍了，为什么毕业设计还要用SSM这种“老组合”？这里我直接说结论：毕设选题，技术得分的关键不是“新”，而是“你讲得透”。

SSM（Spring + SpringMVC + MyBatis）有一个特别好的地方：每一层都“露在外面”，谁负责什么事一目了然。Spring的IoC容器管理Service层对象，SpringMVC的DispatcherServlet负责请求分发，MyBatis把Mapper接口和XML里的SQL绑定起来。老师问你“请求从页面到数据库经历了什么”，你能清清楚楚按链路讲出来。而Spring Boot很多东西是自动配置的，反而容易让答辩变成“我也不知道为什么它就跑起来了”。

JSP页面在这类管理系统里依然够用。它和Servlet是同一套体系，通过JSTL标签和EL表达式在页面上渲染数据，不需要前后端分离，也就不需要额外处理跨域、Token鉴权这些和业务无关的问题。对毕设来说，把精力花在业务闭环上，性价比更高。

1.2 系统角色与业务流程闭环

这个系统的核心业务并不复杂，但角色分工必须明确。我设计时只保留了三个核心角色：管理员、客户、以及系统本身自动执行的计费任务。

管理员：负责套餐管理、客户账号管理、账单审核、查看统计报表。
客户：登录后查看套餐余量、当前话费、历史账单、在线充值缴费。
系统任务：每天从通话详单表和流量详单表读取数据，结合客户当前套餐的计费规则，累计费用并生成账单。

完整的业务闭环是：客户办理套餐 → 产生通话/流量详单 → 系统按套餐规则计算费用 → 生成月度账单 → 客户缴费 → 更新余额。如果你能把这个闭环在论文里画成一张图，再配合数据库里对应的每一张表去讲，答辩老师基本就有了好感，因为这是“业务贯穿”的体现。

1.3 分层架构和各层职责划分

我推荐按标准的四层结构来组织代码，这和SSM框架天然匹配：

层级	代表组件	职责
表现层	JSP页面 + Controller	接收请求、参数校验、调用Service、返回视图
业务层	Service接口 + 实现类	事务控制、业务规则判断、计费逻辑编排
持久层	Mapper接口 + XML	SQL语句、结果映射
数据库	MySQL	数据存储、索引优化

一个重要的细节是：Service层接口不要写得太大。我见过很多同学喜欢写一个UserService，里面堆二三十个方法，这是非常不好的习惯。按业务拆分，比如CustomerService、PackageService、BillService、PaymentService，每个Service只关注自己那部分业务，后面的维护和Debug都会轻松很多。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 数据库设计与核心表结构

2.1 核心表设计与关联关系

电信计费系统的数据库设计是整个项目的核心支撑。我设计的表一共有8张，这里挑重点说：客户表、套餐表、通话详单表、流量详单表、账单表、缴费记录表。

客户表（customer）需要和用户表（sys_user）做关联。我在设计时让sso_user保存登录账号和密码，customer保存客户真实姓名、身份证号、手机号、套餐ID、余额和状态。这样系统将来如果扩展员工登录，不需要改动客户表结构。管理员也放在sso_user里，用role字段区分，省去单独建管理员表。

套餐表（package_info）是最容易被低估的一张表。很多同学的套餐表只有套餐名称和月费，然后把通话、流量、短信的费用都写死在代码里。这种设计一旦增加新套餐，就要改代码重新部署，非常不推荐。正确做法是这样：

sql复制CREATE TABLE package_info (
  id INT PRIMARY KEY AUTO_INCREMENT,
  package_name VARCHAR(50) NOT NULL COMMENT '套餐名称',
  package_type TINYINT NOT NULL COMMENT '套餐类型：1-语音主套餐，2-流量套餐，3-融合套餐',
  monthly_fee DECIMAL(10,2) NOT NULL COMMENT '月固定费',
  included_minutes INT DEFAULT 0 COMMENT '包含通话分钟数',
  included_data INT DEFAULT 0 COMMENT '包含流量，单位MB',
  included_sms INT DEFAULT 0 COMMENT '包含短信条数',
  excess_minute_rate DECIMAL(4,2) DEFAULT 0 COMMENT '超出通话单价/分钟',
  excess_data_rate DECIMAL(4,2) DEFAULT 0 COMMENT '超出流量单价/MB',
  excess_sms_rate DECIMAL(4,2) DEFAULT 0 COMMENT '超出短信单价/条',
  status TINYINT DEFAULT 1 COMMENT '1-在用 0-停用',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

你有没有注意到，我把计费单价字段直接放到了套餐表里。这样一来，计费系统运行时只需要查询套餐记录，就能拿到所有计费参数，新套餐上线只需要往库里插入一条数据，不用动Java代码。这是计费系统设计里非常重要的一点：把业务参数从代码中剥离，放到可配置的数据库表中。

通话详单（call_record）和流量详单（data_record）的设计逻辑类似。通话详单字段包括客户ID、主叫号码、被叫号码、通话开始时间、通话时长（秒）、通话类型（本地/长途/漫游）；流量详单包括客户ID、使用时间、流量大小（KB）、网络类型（4G/5G/WiFi）。这两类表是数据量增长最快的表，我在设计时让通话时长以秒为单位存储，计算费用时再转换为分钟，避免因为整数除法产生精度问题。

账单表（bill）是计费结果的最终体现。字段设计为账单年月、客户ID、套餐月费、语音费用、流量费用、短信费用、总费用、缴费状态（0-未缴 1-已缴）、生成时间。这里要特别注意加一个bill_month字段，格式为“2025-05”，方便做月度查询和统计。

2.2 计费规则的可扩展设计

计费规则是这个系统最核心的业务逻辑。我的实现思路是：把不同类型的套餐抽象成不同的计费策略，而不是把所有判断逻辑堆在一个方法里。比如语音主套餐只关心通话时长，流量套餐只关心流量使用量，融合套餐两者都关心。

在数据库层面，用package_type字段区分不同类型，在Java代码层面，我定义了一个FeeCalculator接口，每种套餐类型对应一个实现类。计算费用的流程是：根据客户当前套餐查package_info表拿到计费参数，再查当月的call_record和data_record统计用量，然后调用对应的实现类计算费用。

这种设计的优势在答辩时非常加分。老师问“如果我要推一个新的视频套餐，包含一定时长的视频流量，你怎么改”，你可以很自然地回答：新增一个套餐类型枚举值，写一个新的FeeCalculator实现类，不需要改任何已有代码。这就是开闭原则的现实应用。

2.3 数据库建表SQL示例

下面给出订单和账单相关的核心建表SQL，方便你直接参考：

sql复制CREATE TABLE bill (
  id INT PRIMARY KEY AUTO_INCREMENT,
  customer_id INT NOT NULL,
  bill_month VARCHAR(7) NOT NULL COMMENT '账单月份，格式YYYY-MM',
  package_fee DECIMAL(10,2) DEFAULT 0 COMMENT '套餐月费',
  call_fee DECIMAL(10,2) DEFAULT 0 COMMENT '语音费用',
  data_fee DECIMAL(10,2) DEFAULT 0 COMMENT '流量费用',
  sms_fee DECIMAL(10,2) DEFAULT 0 COMMENT '短信费用',
  total_fee DECIMAL(10,2) NOT NULL COMMENT '总费用',
  status TINYINT DEFAULT 0 COMMENT '0-未缴费 1-已缴费',
  generate_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY uk_customer_month (customer_id, bill_month)
);

CREATE TABLE payment_record (
  id INT PRIMARY KEY AUTO_INCREMENT,
  customer_id INT NOT NULL,
  bill_id INT DEFAULT NULL,
  pay_amount DECIMAL(10,2) NOT NULL,
  pay_type TINYINT DEFAULT 1 COMMENT '1-余额支付 2-在线支付 3-线下',
  pay_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  trade_no VARCHAR(64) COMMENT '流水号'
);

bill表上加了uk_customer_month唯一索引，保证同一个客户同一个月份只能有一条账单记录。这能防止定时任务重复执行时生成重复账单，是很实用的一个设计细节。

3. 核心业务模块实现与代码实战

3.1 系统登录认证与拦截器实现

登录模块看起来简单，但它是整个系统的门面，一定要做得完整。我采用的方式是：用户提交用户名密码 → Service验证 → 登录成功把用户对象放入Session → 通过SpringMVC拦截器控制页面访问权限。

拦截器是一个很容易被忽略但实现后很显功底的环节。下面给一个登录拦截器示例：

java复制public class LoginInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        HttpSession session = request.getSession();
        Object user = session.getAttribute("loginUser");
        if (user == null) {
            // 判断是否为Ajax请求，Ajax请求不能直接重定向
            String requestedWith = request.getHeader("X-Requested-With");
            if ("XMLHttpRequest".equals(requestedWith)) {
                response.setStatus(401);
                response.setContentType("application/json;charset=UTF-8");
                response.getWriter().write("{\"code\":401,\"msg\":\"登录超时，请重新登录\"}");
            } else {
                response.sendRedirect(request.getContextPath() + "/login");
            }
            return false;
        }
        return true;
    }
}

为什么我特别处理Ajax请求？因为在JSP页面里用了jQuery发起异步请求时，如果后端直接sendRedirect，前端拿到的并不是跳转地址，而是一段HTML文本，控制台会报解析错误。拦截器里区分普通请求和Ajax请求，是真实项目中一定会遇到的细节。

拦截器配置在spring-mvc.xml里，通过mvc:interceptors标签注册，并配置exclude属性放行/login、/css/**、/js/**、/images/**这些路径。资源文件一定要放行，不然会看到页面完全没有样式的尴尬情况。

3.2 计费核心逻辑的完整实现

计费模块是这个系统最应该认真写的部分。我用策略模式来实现不同套餐类型的计费差异。先定义一个接口：

java复制public interface FeeCalculator {
    /**
     * 计算某客户某月的账单费用
     * @param customer 客户信息
     * @param packageInfo 套餐信息
     * @param month 账单月份
     * @return 费用明细
     */
    MonthlyFeeDetail calculate(Customer customer, PackageInfo packageInfo, String month);
}

然后写一个融合套餐的实现类举例：

java复制@Service("compoundFeeCalculator")
public class CompoundFeeCalculator implements FeeCalculator {

    @Autowired
    private CallRecordMapper callRecordMapper;
    @Autowired
    private DataRecordMapper dataRecordMapper;

    @Override
    public MonthlyFeeDetail calculate(Customer customer, PackageInfo pkg, String month) {
        // 统计当月语音通话总时长（秒）
        int totalCallSeconds = callRecordMapper.sumDurationByCustomerAndMonth(customer.getId(), month);
        // 统计当月流量总数（KB）
        long totalDataKB = dataRecordMapper.sumDataByCustomerAndMonth(customer.getId(), month);

        double callExcessMinutes = Math.ceil(totalCallSeconds / 60.0 - pkg.getIncludedMinutes());
        double callFee = 0;
        if (callExcessMinutes > 0) {
            callFee = callExcessMinutes * pkg.getExcessMinuteRate();
        }

        double dataExcessMB = (totalDataKB / 1024.0) - pkg.getIncludedData();
        double dataFee = 0;
        if (dataExcessMB > 0) {
            dataFee = dataExcessMB * pkg.getExcessDataRate();
        }

        MonthlyFeeDetail detail = new MonthlyFeeDetail();
        detail.setPackageFee(pkg.getMonthlyFee());
        detail.setCallFee(round(callFee));
        detail.setDataFee(round(dataFee));
        detail.setTotalFee(round(pkg.getMonthlyFee() + callFee + dataFee));
        return detail;
    }

    private double round(double value) {
        return Math.round(value * 100) / 100.0;
    }
}

注意两个细节。第一，通话超出分钟数我用了Math.ceil向上取整，这是参照电信行业“不足一分钟按一分钟计费”的常见规则展开的合理设计。第二，所有费用计算结果用round保留两位小数，避免浮点运算产生类似19.999999这种精度问题。

在FeeDetail结果对象里，我建议把套餐费用、语音费用、流量费用、短信费用、总费用分别存放，这样写入bill表时可以直接对应字段，页面展示时也可以按项目展示。计费完成后再把结果插入账单表，同时更新客户余额，这两个操作必须放在同一个事务里。我用Spring的@Transactional注解来控制，一旦插入失败，余额也不会扣错。

3.3 月度账单生成与定时任务

账单生成不能依赖管理员手动点按钮，建议设计成一个定时任务。我实现了两种方式：一种是使用Spring的@Scheduled注解，在每月1日凌晨跑一次上个月的计费逻辑；另一种是在管理后台提供一个手动触发接口，方便演示时快速出效果。

定时任务的实际配置如下：

xml复制<!-- 开启定时任务支持 -->
<task:annotation-driven scheduler="taskScheduler"/>
<task:scheduler id="taskScheduler" pool-size="5"/>

java复制@Component
public class BillGenerateTask {

    @Autowired
    private BillingService billingService;

    // 每月1号凌晨1点执行，生成上个月账单
    @Scheduled(cron = "0 0 1 1 * ?")
    public void generateMonthlyBill() {
        LocalDate lastMonth = LocalDate.now().minusMonths(1);
        String month = lastMonth.format(DateTimeFormatter.ofPattern("yyyy-MM"));
        List<Customer> customers = customerService.listActiveCustomers();
        for (Customer customer : customers) {
            try {
                billingService.generateBill(customer.getId(), month);
            } catch (Exception e) {
                log.error("生成账单失败 customerId={}, month={}", customer.getId(), month, e);
            }
        }
    }
}

这里有一个我在实际开发中踩过的坑：定时任务循环调用generateBill时，如果某一条数据异常导致整个任务回滚，前面所有客户都没法生成账单。所以我在循环里单独捕获异常，保证一个客户失败不影响其他客户。还有一点，包扫描必须覆盖到@Scheduled注解所在的包，否则任务不会被注册，可以检查Spring配置文件里的component-scan配置。

定时任务做完之后，建议在管理后台放一个“手动生成上个月账单”的按钮，并把按钮放在比较显眼的位置。答辩演示时你不可能等定时任务自然触发，手动触发一下就出数据，演示流程会顺畅很多。

3.4 前端JSP页面的实现要点

JSP页面最核心的技术点有三个：EL表达式、JSTL标签、以及和服务器的数据交互。我以客户的话费查询页面为例来拆解。

首先在Controller里把数据塞进Model：

java复制@RequestMapping("/customer/bill")
public String viewBill(Model model, HttpSession session) {
    Customer customer = (Customer) session.getAttribute("loginUser");
    String month = ...; // 当前月份
    Bill bill = billService.getBillByCustomerAndMonth(customer.getId(), month);
    model.addAttribute("bill", bill);
    model.addAttribute("customer", customer);
    return "customer/billList";
}

页面端用JSTL和EL配合展示：

jsp复制<c:if test="${not empty bill}">
    <div class="card">
        <div class="card-header">
            账单月份：${bill.billMonth} 状态：
            <c:choose>
                <c:when test="${bill.status == 0}">
                    <span class="badge badge-warning">未缴费</span>
                </c:when>
                <c:otherwise>
                    <span class="badge badge-success">已缴费</span>
                </c:otherwise>
            </c:choose>
        </div>
        <table class="table table-bordered">
            <tr>
                <td>套餐月费</td><td>${bill.packageFee}</td>
                <td>语音费用</td><td>${bill.callFee}</td>
            </tr>
            <tr>
                <td>流量费用</td><td>${bill.dataFee}</td>
                <td>短信费用</td><td>${bill.smsFee}</td>
            </tr>
            <tr>
                <td colspan="3" class="text-right">合计</td>
                <td>${bill.totalFee} 元</td>
            </tr>
        </table>
        <c:if test="${bill.status == 0}">
            <button class="btn btn-primary" onclick="payBill(${bill.id})">立即缴费</button>
        </c:if>
    </div>
</c:if>

EL表达式负责输出对象属性，JSTL的c:choose处理条件分支。这里要注意，JSP页面顶部必须正确引入标签库：

jsp复制<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

否则c:if标签会原样输出在页面上，且会报错。页面风格上我选用了Bootstrap 3或者4都行，直接用CDN引入，不用下载到本地，会省去很多资源路径配置的麻烦。

分页查询是管理员页面里必须有的功能。建议把所有基础数据表（客户、套餐、账单）都加上分页，用PageHelper插件实现最方便。在pom.xml引入pagehelper依赖后，只需要在查询前调用PageHelper.startPage(pageNum, pageSize)，后面紧跟的查询语句就会被自动拼接上LIMIT。这个插件在SSM项目里很流行，而且答辩时讲起来也不难：一页显示多少条、数据量大了怎么办、怎么跳转，都是老师爱听的内容。

3.5 管理员模块设计与权限控制

管理员和客户端共用一套登录体系，通过role字段区分，但页面和功能必须分开。我在项目中设计了两个不同的目录结构：/admin/**开头的路径走管理员功能，/customer/**走客户功能。在拦截器里除了判断是否登录，还要判断角色权限。

java复制if (user != null && "2".equals(user.getRole())) {
    // 普通客户不允许访问后台
    response.sendRedirect(request.getContextPath() + "/403");
    return false;
}

管理员模块的核心页面包括：套餐列表页（可增删改查）、客户列表页（可重置密码、可禁用）、账单列表页（可按月份筛选）、统计报表页（用ECharts展示每月收入曲线）。统计报表页面建议向老师重点展示，因为它体现了你从“单表CRUD”到“数据可视化”的延伸能力。用ECharts非常容易上手，后端提供JSON接口，前端直接调用，几分钟就能出一个像样的图表。

4. 高频问题排查与避坑实录

4.1 JSP页面出现“file not found”错误

这是JSP项目里非常常见的报错。报错信息类似于javax.servlet.ServletException: File [/hotline.jsp] not found。出现这个错误的原因通常是视图解析器配置的路径不对。

我自己的排查步骤是：先看Controller返回的视图名，再看spring-mvc.xml里的视图解析器配置：

xml复制<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/views/"/>
    <property name="suffix" value=".jsp"/>
</bean>

如果Controller方法返回"admin/packageList"，那么视图解析器会去访问/WEB-INF/views/admin/packageList.jsp。如果这个文件不存在，或者目录层级不对，就会报not found。排查时优先检查文件是否真的在这个目录下，而不是直接改代码。另外还要注意大小写，Linux服务器上文件名是严格区分大小写的。

4.2 MyBatis Mapper绑定异常

org.apache.ibatis.binding.BindingException: Invalid bound statement (not found)也是SSM项目的高频问题。原因一般是Mapper接口和Mapper XML文件没有正确关联。

我排查时会检查以下四点：

XML文件里namespace是否和接口全限定名完全一致
XML文件里每个语句的id是否和接口方法名一致
Mapper接口是否被@MapperScan扫描到，或者XML文件是否在mybatis.mapper-locations配置的路径下
XML文件有没有放在resources目录下并且编译到了target/classes里

其中最后一个问题最坑。如果你用的是Eclipse或IDEA默认的Maven结构，XML文件放在src/main/java目录下可能会被排除在编译之外，导致运行时找不到XML。解决办法是在pom.xml的build节点里加resources配置，把**/*.xml包含进去。在IDEA里新建项目时，我会直接在src/main/resources目录下建mapper文件夹，从源头避免这个问题。

4.3 中文乱码问题

中文乱码在JSP + SSM项目里几乎是必现的，主要出现在三个地方：页面显示、请求参数、数据库存取。

页面显示乱码，在JSP文件头部加上：

jsp复制<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

请求参数乱码，在web.xml里配置编码过滤器：

xml复制<filter>
    <filter-name>encodingFilter</filter-name>
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>UTF-8</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>encodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

数据库存取乱码，在JDBC连接URL里加上characterEncoding=utf8：

properties复制jdbc.url=jdbc:mysql://localhost:3306/telecom_billing?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

还有个容易忽略的地方：MySQL数据库本身的字符集也要检查，建库时最好指定：

sql复制CREATE DATABASE telecom_billing DEFAULT CHARACTER SET utf8mb4;

这是我做项目时踩过最土但最费时间的坑，页面改了、过滤器也加了，数据库还是乱码，最后发现是库的默认字符集不对。

4.4 修改了JSP但页面不生效

这个问题在答辩现场出现会非常尴尬。明明改好了代码，刷新浏览器还是老页面。原因通常是浏览器缓存。开发阶段可以在JSP页面头部加一段禁用缓存的代码：

jsp复制<%
    response.setHeader("Cache-Control", "no-store");
    response.setHeader("Pragma", "no-cache");
    response.setDateHeader("Expires", 0);
%>

或者更省事的方式：浏览器按Ctrl + F5强制刷新。但如果部署到Tomcat后改的JSP，还需要注意Tomcat的webapps目录下是否同步了新文件。如果IDE自动部署到wtpwebapps目录，而你又手动改了webapps下的文件，那永远不会生效。建议统一使用IDE的部署方式，不要混着来。

4.5 会话超时与页面跳转异常

JSP项目默认Session超时时间是30分钟。如果客户页面停留太久再点按钮，Session里的用户信息可能会失效。前面拦截器里处理的Ajax超时问题，就是针对这种情况。另外在页面里，我也会加一个简单的全局定时器，提前提醒用户会话即将过期，当然这个属于锦上添花的优化，不是必做项。

5. 项目答辩准备与展示技巧

5.1 技术亮点如何提炼成答辩话术

答辩时不要笼统地说“我做了一个SSM的话费系统”，而是要把技术亮点具象化，给老师留下印象。我建议从以下三个方向准备话术。

第一，计费规则的可扩展设计。主动提策略模式，说明你写了一个FeeCalculator接口，不同类型套餐有不同的实现类，没有把所有判断堆在一个方法里。这句话比“我用了SSM”有价值得多，它证明了你有基本的软件设计意识。

第二，事务控制。讲缴费操作时强调“扣余额”和“生成缴费记录”在一个事务里，防止一个成功一个失败导致数据不一致。老师听到这个会觉得你做过真实项目的完整流程，而不只是会写增删改查。

第三，数据统计与可视化。如果你做了ECharts报表页面，一定要现场演示，不用做得特别复杂，一个“近六个月总营收趋势图”就足够加分。

5.2 演示流程准备与演示数据设计

答辩演示最关键的一点是：提前准备好看的演示数据。不要在答辩现场临时注册一个客户再等系统生成详单，那基本等不起。我的做法是写一个DataInitCommandLineRunner，项目启动时自动往数据库插入几组测试数据：3个客户、2个套餐、20条通话详单、15条流量详单，已经生成好的上个月账单。

演示流程建议按这个顺序走：

管理员登录 → 查看客户列表 → 查看套餐列表 → 展示修改套餐的操作
查看月度财务报表（ECharts折线图）
客户登录 → 查看话费余额和当前账单 → 展示缴费操作 → 缴费后余额变化
如果老师提出想看计费细节，把当月通话详单也展示出来

这样一套流程下来大概5到8分钟，每个模块都覆盖到了，节奏也比较紧凑。演示前一定要自己完整跑两遍，一旦出现“演示时发现某个按钮点了没反应”这种事故，后面再怎么解释也弥补不了。

5.3 关于代码规范和论文结构的一点点建议

最后说个容易被忽视的点：代码规范。类名用驼峰、常量用大写、方法名用动词开头，Service层加注释，Controller不要写业务逻辑——这些细节在答辩时可能不会直接加分，但因为代码太乱被扣分的情况真的极其常见。论文方面，重点写清楚“系统需求分析”、“数据库设计”、“系统实现”和“系统测试”四块，其中数据库设计部分附上完整的E-R图和表结构说明，测试部分附上功能测试用例表格。

6. 扩展方向：这个系统还能怎么改

如果你做完基础功能觉得还有余力，我建议在时间允许的范围内做一两个小扩展，这会让你的毕设从“合格”直接拉到“优秀”。我个人觉得以下三个方向是最适合在这个项目基础上延伸的。

第一个是充值优惠活动。在缴费模块里增加一个优惠活动表，比如“充100送10”，缴费时自动匹配活动规则。这个功能涉及到和支付流程的联动，逻辑不复杂但能展示业务思考能力，而且数据库只需要新增一张recharge_activity表，成本很低。

第二个是短信提醒功能。当客户话费余额低于某个阈值（比如20元）时，系统自动生成一条提醒记录，在客户登录首页时弹窗提示。这个功能有很多同学做过，但在话费系统里做尤其合理——话费余额和停机强相关，业务上非常自然。实现方式可以在系统里建一张notice_message表，也可以接第三方短信接口，但毕设阶段建议用站内信模拟，不要真的去注册短信服务商。

第三个是管理员统计报表增强。在原有按月收入趋势图的基础上，增加“套餐订购占比饼图”和“客户增长柱状图”。ECharts本身支持多种图表类型，只要后端查询SQL写对，前端配置是半小时的事。我当年就是靠这个饼图，让答辩老师多看了我系统一眼，问了一句“这个数据是怎么算出来的”。

扩展功能的选择原则是：选那些你能够清晰讲出“需求背景 + 实现方案 + 表结构变化”的，而不是选那些听起来炫但你自己都说不清楚原理的。老师不指望你的系统做得像运营商那么复杂，他更在意你面对一个业务需求时，能不能给出一个合理且可实现的设计方案。

7. 最后一小段个人体会

做完这个项目之后，我的一个明显感受是：系统越往外扩展，数据库设计和业务逻辑抽象的重要性就越高。计费系统看起来只是“算账”，但真正把计算参数从代码中解放出来、把不同套餐的计费差异用策略模式解耦之后，后面添加新功能就变得顺手很多。这个思路同样适用于以后做其他管理系统——先想清楚最容易变化的点在哪，再决定代码怎么写。

给正在做这个课题的同学一句实在话：别把时间耗在纠结用不用最新技术上，老老实实把SSM的请求链路、数据库表之间的关联关系、以及计费的核心逻辑吃透，你的毕业设计答辩就已经赢了大半。遇到问题多打断点看调用栈，多查日志，比盲目改代码高效得多。希望这篇内容能帮你少走点弯路。