基于SSM+JSP的电信计费系统毕业设计：从计费引擎到框架整合完整指南

1. 项目全貌与设计思路拆解

1.1 毕设为什么选“电信计费系统”这个方向

每年带毕业设计，我见过太多人上来就选“XX管理系统”这种题目，图书管理、学生管理、仓库管理、酒店管理……不是说这些题目不行，而是它们太泛滥了，答辩时评委一眼看过去全是同质化的CRUD，很难突出亮点。而“电信客户话费计费系统”这个题目天然就比单纯的管理系统高一个档次，原因有三：

第一，它是典型的业务闭环。从用户开户、选择套餐，到话单产生、计费计算，再到账单生成、费用缴纳，整条链路完整且有真实业务背景。评委听你讲“计费规则怎么设计”，比听你讲“增删改查做得多熟练”要有兴趣得多。

第二，它兼具管理功能和算法逻辑。管理系统通常只是把数据存起来、展示出来，而计费系统要求你真实处理通话时长、费率匹配、阶梯计费等计算逻辑。这部分能充分展示你的逻辑思维能力，也是论文里“核心技术”章节最重的素材。

第三，它后期好扩展。答辩时评委最爱问“你这个系统还能怎么改进”。计费系统可以往多级套餐、优惠活动、跨运营商结算、大数据分析等方向做，你随便说两条就能体现出思考深度。

再说直白一点，这种偏传统行业的业务系统，网上现成参考资料足够多，数据库表结构、计费规则、页面设计都有一套成熟范式可以参照，对于本科毕业设计来说，踩坑成本低、性价比高，多数人踏踏实实做完是能拿到不错成绩的。

1.2 SSM + JSP这套技术栈为什么还在“服役”

现在一聊项目，学生上来就问我“老师，用不用Spring Boot + Vue前后端分离啊”。我的回答通常是：如果你是企业实习、做商业项目，那确实该上Spring Boot；但如果是本科毕业设计，SSM + JSP不但不落伍，反而是个稳妥选择。为什么？

先看SSM本身，它的全称是Spring + SpringMVC + MyBatis，三个框架各管一摊。Spring负责对象管理和事务控制，SpringMVC负责接收请求、转发页面、返回数据，MyBatis负责数据库操作。这种分层结构非常清晰，论文里画架构图好画，答辩讲分工也好讲，评委问“你怎么理解控制反转”“MyBatis和Hibernate有什么区别”这类经典问题时，你有足够的底层可以展开。相比之下直接用Spring Boot，很多配置被自动约定藏起来了，反而问不出深度。

再看JSP，诚然它已经被很多企业抛弃了，但毕设用JSP有个实打实的好处：它把Java代码和页面渲染放在一起，后端传过来的数据模型（比如用户对象、话单列表）直接在页面上用EL表达式和JSTL标签展示，整个数据流转过程对评委来说一目了然。你不需要讲Vue的响应式原理，不需要讲跨域处理，核心精力可以全部放在业务逻辑上。说白了，毕业设计的目标是证明你掌握了Java Web开发的基本功，SSM+JSP恰好能把基本功展示得淋漓尽致。

所以我的总结是：SSM+JSP适合课业压力大、没太多时间钻研前端、想把精力放在业务逻辑和算法上的同学。技术栈不炫，但在毕设场景下足够扎实。这也是这篇文章要把重点放到计费业务和框架整合上的原因。

2. 系统功能需求与模块划分

2.1 核心业务流程：从用户开户到账单出账

在动笔写代码之前，我习惯先让学生把业务流程完整地走一遍，画清楚“谁在什么时间对什么数据做了什么事”。计费系统最核心的流转过程是这样的：

• 用户信息开户：管理员录入客户基本信息，分配账号，设置初始状态。
• 开通套餐：客户选择一个套餐（比如“月租59元，含300分钟通话，超出部分每分钟0.15元”）。
• 通话话单产生：系统通过模拟数据或接口获取通话记录，字段包含主叫号码、被叫号码、通话开始时间、通话时长、通话类型（本地/长途/漫游）。
• 计费引擎计算：对每一条话单，根据号码所属客户的套餐、费率表、通话类型，计算本次通话费用。
• 账单汇总出账：到了月底（或实时），把一个月内所有话单费用汇总，加上月租费，生成账单。
• 用户缴费：客户查询账单、缴费、充值，系统记录缴费流水并更新账户余额。

这里有一个细节值得注意：很多同学最开始会把“计费”想成一条SQL语句搞定，实际上真实的计费系统是分两段的。一段是“话单级计费”，就是对着每一条通话记录算费用，另一段是“账单级出账”，把多个话单汇总起来并结合套餐、优惠生成最终应缴金额。这一段话建议写进你的论文需求分析里，能让评委觉得你确实理解业务。

2.2 角色权限与功能模块清单

这个系统我建议设置三个角色，每个角色的功能边界要清晰：

• 系统管理员：用户管理、套餐管理、费率管理、话单管理、统计报表、系统日志。
• 客服/业务员：客户信息维护、话费查询、账单补打、缴费登记、客户投诉处理。
• 普通客户：个人信息查看、套餐详情查看、话费查询、账单查询、在线缴费（模拟）。

对应到具体的功能模块，至少要有下面这些：

顺带说一句，热词里出现的“java web + jsp项目中前端使用js+jquery如何实现设置审批流”，其实就是这里投诉审批模块要做的事。后边我会单独讲怎么用jQuery操作DOM实现一个简单的审批流页面。

2.3 页面展示与前后端交互方式

JSP项目的页面规划和纯前端项目不同，核心不是“视觉多炫”，而是“页面职责清晰”。我通常会按角色来做页面目录拆分：

• /admin：管理员专属页面，包括用户列表、套餐管理、费率管理、话单导入、统计报表。
• /customer：客服工作台，包括用户查询、缴费登记、投诉处理。
• /user：客户自助页面，包括个人信息展示页面、话费查询、账单查询、在线缴费。

特别注意“个人信息展示页面”这个小功能，别小看它，很多同学在用户表字段设计时草率了，导致页面上想展示“用户已开通套餐”“本月已用时长”时发现数据根本没地方放。建议用户表至少包含：姓名、证件号、手机号、套餐ID、开户时间、账户余额、状态（正常/停机/注销）这些字段。页面展示时用EL表达式或者jQuery发Ajax请求拉数据都行，但数据源必须先设计明白。

前端交互这一块，推荐的做法是JSP负责页面渲染，jQuery + Ajax负责局部刷新。比如用户点击“查询本月账单”，页面不整体刷新，而是用Ajax请求后端接口拿到JSON数据结构，再通过js拼接成表格显示。这个模式在答辩演示的时候效果很好，比点一下跳转再点一下返回要流畅得多。

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

3.1 数据库选型与设计原则

数据库这块不用纠结，直接MySQL 5.7或8.0，InnoDB引擎，字符集utf8mb4，排序规则用utf8mb4_general_ci就行。如果你在论文里能写清楚为什么用InnoDB（支持事务、行级锁，适合计费这种需要保证数据一致性的场景），再简单提一下为什么不用MyISAM，这是个加分点。

具体设计时有三条原则要贯穿整个建表过程：

第一，金额字段一律用DECIMAL，不要用FLOAT/DOUBLE。浮点数在二进制里无法精确表示，做加法时会产生精度误差，计费系统每天计算海量话单，一点点误差累积起来就是大事。DECIMAL(10,2)足够存大多数金额，如果涉及大批量充值，可以设计成DECIMAL(12,2)。

第二，主键尽量用INT自增或BIGINT，不要用手机号。手机号虽然业务上唯一，但作为主键会导致索引体积变大，而且如果未来支持携号转网，手机号可能变更。建议用户表内部用一个自增ID，外部再用手机号做逻辑唯一索引。

第三，所有涉及“状态”的字段都要有明确含义并写注释。比如用户状态0-正常，1-停机，2-注销；账单状态0-未出账，1-已出账，2-已缴费，3-已作废。这些状态会贯穿整个业务流程，注释不写清楚，写到后面自己都容易迷糊。

3.2 核心数据表设计

我直接给出一套经过验证的表结构，你可以在此基础上按自己的需求调整。一共七张核心表，外加一张操作日志表。

user（客户表）

package（套餐表）

这里额外加一个字段叫description，用来写套餐说明，页面上展示套餐详情时会用到。

rate（费率表）

费率表的粒度可以做得粗也可以做得细，本科毕设做到按通话类型区分就足够了。如果想增加亮点，可以再加一个时段字段，区分工作日/节假日、忙时/闲时，但要考虑话单数据是否支持，别把自己绕晕。

cdr（话单表）

话单表是整个系统的数据基座，字段设计直接影响计费逻辑。特别注意两点：通话时长建议以秒为单位存储，因为计费时需要按分钟向上取整，比如不足1分钟按1分钟算；同时一定要有status字段标记计费状态，防止同一批话单被重复计费。

bill（账单表）

bill_detail（账单明细表）

这张表的作用是关联账单和话单，让用户可以点开一张账单看到里面每一条通话记录和对应费用。答辩时这个功能很能说明你的系统做到了什么粒度。

payment（缴费记录表）

这套表结构不是唯一的方案，但它是经过实际项目验证的，覆盖了“用户→套餐→话单→计费→账单→缴费”的完整链路。你写论文时，基于这套结构扩展“充值记录表”“操作日志表”等附加表，空间也很充足。

4. 计费引擎与核心算法实现

4.1 计费规则怎么设计才合理

计费引擎是整个系统里最能体现工作量和技术含量的地方。先说规则，我建议毕设阶段实现三种计费模式就足够了，再多容易失控：

• 月租费：套餐固定费用，无论是否通话都要扣除。出账时直接加到账单总额里。
• 通话计费：先扣减套餐内的免费分钟数，超出部分按费率表计算。比如某套餐含300分钟，本月通话350分钟，那么前300分钟免费，后50分钟按每分钟0.15元计算。
• 按通话类型差异化计费：本地通话和长途通话使用不同单价。这个通过费率表实现，话单里call_type字段关联对应费率。

这里最核心的业务规则是“先扣套餐免费时长，再算超额费用”。很多同学一开始想当然地认为“所有话单直接乘单价”，这会丢掉套餐的业务意义，等于白做了套餐模块。正确的处理方式是：同一用户同一账期内，把所有话单按时长累加，先和套餐免费分钟数比较，超出部分才计费。

4.2 话单费用计算的具体实现

我给出一个可供参考的执行流程，用伪代码表述：

code复制public void calculateBillByMonth(String billMonth) {
    // 1. 查询本账期未出账的所有用户
    List<User> users = userMapper.selectAllNormalUsers();
    for (User user : users) {
        // 2. 查询用户的套餐信息
        PackageInfo pkg = packageMapper.selectById(user.getPackageId());
        // 3. 查询用户本月所有未计费的话单
        List<Cdr> cdrList = cdrMapper.selectUnbilledByUserAndMonth(user.getId(), billMonth);
        // 4. 计算总通话时长（秒）
        long totalSeconds = cdrList.stream().mapToLong(Cdr::getDurationSeconds).sum();
        // 5. 免费分钟数转换成秒
        long freeSeconds = pkg.getFreeMinutes() * 60;
        // 6. 判断是否超出免费时长
        long excessSeconds = totalSeconds > freeSeconds ? totalSeconds - freeSeconds : 0;
        // 7. 超出部分按向上取整分钟计费
        BigDecimal excessFee = calcFeeByMinuteUpRound(excessSeconds, pkg.getExcessPrice());
        // 8. 生成账单
        insertBill(user.getId(), billMonth, pkg.getMonthlyFee(), excessFee);
        // 9. 将该用户话单标记为“已计费”，防止重复出账
        cdrMapper.markBilled(cdrList);
    }
}

这里有两个细节要特别强调：

第一个是“向上取整”的问题。通话不足1分钟按1分钟计算是通信行业的常规做法，所以在计算超额时长时要把秒转换成分钟再向上取整。Java里可以这么写：

java复制public static int minutesUpRound(long seconds) {
    return (int) Math.ceil(seconds / 60.0);
}

注意这里不能用整数除法，否则45秒会变成0分钟，存在bug。

第二个是金额计算要用BigDecimal。看一个实际对比：

java复制// 错误示范：double计算，可能出现精度问题
double fee = 50 * 0.15;  // 结果可能是7.499999999999999

// 正确示范：BigDecimal计算
BigDecimal excessFee = BigDecimal.valueOf(50)
        .multiply(BigDecimal.valueOf(0.15))
        .setScale(2, RoundingMode.HALF_UP);

我把这段写进代码注释里，让看代码的人一眼明白为什么用BigDecimal而不是double。答辩时如果评委问到，你可以直接回答“浮点数在二进制中无法精确表示，计费系统对金额精度要求极高，必须用Decimal类型存储，用BigDecimal计算”。

4.3 定时出账与并发控制

出账一般发生在月初，也就是对上一个账期做集中结算。工程上可以用定时任务调度框架来实现，但如果你不想引入额外依赖，直接在项目启动时用Spring的Scheduled注解也可以。

java复制@Component
public class BillScheduleTask {

    @Scheduled(cron = "0 0 3 1 * ?") // 每月1号凌晨3点触发
    public void generateMonthlyBill() {
        String lastMonth = DateUtils.getLastMonth();
        billingService.calculateBillByMonth(lastMonth);
    }
}

注意要在spring配置文件中开启定时任务支持：

xml复制<task:annotation-driven/>

有一点一定要想明白：如果系统重启，定时任务没有执行，这个月的账单就漏掉了。所以生产环境里一般会做一个手动触发接口，管理员在后台可以点击“手动出账”，同时判断该账期是否已出账，避免重复生成。你把这个设计写到系统里，论文里可以写“为了保证数据一致性和可靠性，系统同时支持定时调度和手动触发两种出账模式”，这又是一个加分点。

5. SSM框架整合与JSP页面开发实操

5.1 框架整合步骤与配置文件要点

SSM框架的整合代码网上很多，但很多同学照抄后跑不起来，问题大多出在配置文件上。我这里用一个直白的方式把整个流程捋清楚，你就知道各配置文件的职责了。

第一步：在pom.xml中引入依赖。核心依赖有spring-context、spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid连接池、jstl、jackson（用于Ajax返回JSON）、junit。注意版本选择，建议Spring用5.x，MyBatis用3.5.x，mybatis-spring用2.0.x，太老或者太新的组合容易出现兼容问题。

第二步：配置web.xml。这个文件是Java Web项目的入口，需要配置两样东西：Spring的ContextLoaderListener（负责加载Spring容器）和SpringMVC的DispatcherServlet（负责拦截请求）。同时一定要配置字符编码过滤器，不然JSP页面上中文必乱码：

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>

第三步：配置spring-mvc.xml。这里要开启注解驱动、配置视图解析器、扫描Controller包：

xml复制<context:component-scan base-package="com.example.controller"/>
<mvc:annotation-driven/>
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/views/"/>
    <property name="suffix" value=".jsp"/>
</bean>

第四步：配置spring-mybatis.xml。这里把数据源、SqlSessionFactory、Mapper扫描整合到一起：

xml复制<context:component-scan base-package="com.example.service"/>

<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
    <property name="url" value="jdbc:mysql://localhost:3306/telecom_billing?useUnicode=true&amp;characterEncoding=utf-8"/>
    <property name="username" value="root"/>
    <property name="password" value="123456"/>
</bean>

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <property name="typeAliasesPackage" value="com.example.entity"/>
    <property name="mapperLocations" value="classpath:mapper/*.xml"/>
</bean>

<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
    <property name="basePackage" value="com.example.mapper"/>
</bean>

这里面最容易踩的坑是数据库URL里的&符号。在XML文件里&是特殊字符，不能用裸的&，必须写成&。很多同学数据库连接报错，就卡在这个细节上。

5.2 JSP页面开发：从后台传值到页面展示

JSP页面开发的核心逻辑是：“后台往Model里放数据，JSP用EL表达式和JSTL标签取出来渲染”。举个例子，用户查询自己的话费明细，Controller的写法是：

java复制@RequestMapping("/user/billDetail")
public String billDetail(Integer userId, Integer billId, Model model) {
    Bill bill = billService.getBillById(billId);
    List<BillDetailVO> detailList = billService.getBillDetailList(billId);
    model.addAttribute("bill", bill);
    model.addAttribute("detailList", detailList);
    return "user/bill_detail";
}

对应JSP页面里的展示方式：

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

<h3>${bill.billMonth} 月账单</h3>
<p>月租费：<fmt:formatNumber value="${bill.packageFee}" type="currency"/></p>
<p>通话费：<fmt:formatNumber value="${bill.callFee}" type="currency"/></p>
<p>合计：<fmt:formatNumber value="${bill.totalFee}" type="currency"/></p>

<table border="1">
    <tr>
        <th>被叫号码</th>
        <th>通话类型</th>
        <th>开始时间</th>
        <th>时长(秒)</th>
        <th>费用(元)</th>
    </tr>
    <c:forEach items="${detailList}" var="item">
        <tr>
            <td>${item.calledNumber}</td>
            <td>${item.callType}</td>
            <td>${item.startTime}</td>
            <td>${item.durationSeconds}</td>
            <td>${item.fee}</td>
        </tr>
    </c:forEach>
</table>

这里要留意的坑是：如果后台返回的是null或者list是空的，页面可能报空指针或者显示空白。稳妥的做法是在JSP里加判断：

jsp复制<c:if test="${empty detailList}">
    <tr><td colspan="5">当前账单没有明细数据</td></tr>
</c:if>

很多同学做“个人信息展示页面”，数据死活展示不出来，八成是后台Model里没放数据，或者JSP的EL表达式属性名写错了，跟实体类字段对不上。这个排查思路要记住：先看Controller有没有往Model放值，再看页面属性名是否和getter方法对应。

5.3 用jQuery + Ajax实现异步交互

JSP页面上最常见的异步场景有三个：话费查询、用户状态切换、投诉审批。这里我以“投诉审批流”为例讲一下实现方式，因为热词里也有人问到。

假设客服提交了一个投诉工单，管理员在列表中点击“通过”或“驳回”，页面用Ajax请求后端接口，然后把按钮状态更新掉，不刷新整个页面。

前端核心代码：

javascript复制$(document).ready(function () {
    // 审批通过
    $(".btn-approve").click(function () {
        var complaintId = $(this).data("id");
        $.ajax({
            url: "/admin/complaint/approve",
            type: "POST",
            data: { id: complaintId },
            dataType: "json",
            success: function (result) {
                if (result.code === 200) {
                    alert("审批通过");
                    // 更新当前行状态
                    $("#complaint-" + complaintId).find(".status-span")
                        .text("已通过").removeClass().addClass("status-approved");
                    $(this).attr("disabled", true);
                } else {
                    alert("操作失败：" + result.msg);
                }
            },
            error: function () {
                alert("请求异常，请联系管理员");
            }
        });
    });
});

Controller端对应代码：

java复制@RequestMapping("/admin/complaint/approve")
@ResponseBody
public Map<String, Object> approve(Integer id) {
    Map<String, Object> result = new HashMap<>();
    try {
        complaintService.approve(id);
        result.put("code", 200);
        result.put("msg", "操作成功");
    } catch (Exception e) {
        result.put("code", 500);
        result.put("msg", e.getMessage());
    }
    return result;
}

要特别注意，使用@ResponseBody返回对象时，spring-mvc.xml里必须配置了jackson依赖和注解驱动，否则会报406错误或者直接返回对象字符串。这也是SSM项目里特别常见的问题，建议提前把jackson-databind加入依赖。

6. 常见问题排查与避坑实录

6.1 高频问题速查表

做SSM+JSP项目，我在带学生的过程中遇到过大量重复性报错。下面这张表基本涵盖了90%的问题场景：

6.2 几个值得展开说的“深坑”

先说说404问题。有很多同学碰到报错jsp file [/hotline.jsp] not found，第一反应是去百度复制一堆过滤器配置，其实大多数情况就是视图解析器或者文件路径的问题。我的排查思路是：先在浏览器直接访问JSP文件路径，比如输入http://localhost:8080/你的项目名/WEB-INF/views/hotline.jsp——注意，WEB-INF下的资源直接访问不到是正常的，这样做是想确认文件是否存在；然后看Controller返回的字符串和文件名的对应关系。我见过最多的情况是Controller里return的是"hotline.jsp"，而解析器后缀已经写好了.jsp，结果实际寻找的路径变成了/WEB-INF/views/hotline.jsp.jsp，这不报错才怪。正确做法是只写"hotline"。

再说一个“金额精度”的坑。我记得有个学生做缴费模块时，用double写了这样一段逻辑：余额扣除缴费金额后，再存回数据库。测试时发现余额从100块扣了19.9后变成了80.09999999999999。他当时还以为是MySQL自动四舍五入的问题，折腾了一下午。后来我把他的代码改成BigDecimal后问题消失。我建议从现在开始，项目里凡是涉及加减乘除的地方，一律用BigDecimal，不给浮点数任何机会。这是计费系统的底线。

还有一个关于“并发重复扣费”的问题。虽然毕业设计不要求做高并发，但如果你在系统里写“某个客户缴费时同时被客服和管理员操作”，就可能出现扣两次的情况。解决办法是MySQL的乐观锁，在user表加一个version字段，修改时带上版本号：

xml复制<update id="deductBalance">
    update user
    set balance = balance - #{amount},
        version = version + 1
    where id = #{userId} and version = #{version}
</update>

如果更新影响行数为0，说明数据已经被别人改过，需要提示用户重试。这个方案不复杂，写进论文里能体现出你对并发问题有思考，答辩时是个不错的谈资。

6.3 项目调试阶段的三条实操建议

在项目写完后，正式提交之前，建议按下面三个步骤做过一遍自测，能省掉大量答辩时翻车的风险：

第一，全流程跑通一遍。用测试账号走完“管理员开户→分配套餐→导入话单→手动出账→用户查询账单→缴费”整个流程，确保每一步的数据都能对得上。特别要注意话单导入后，是否能在用户后台看到每条话单对应的费用；账单生成后，月租费、通话费、合计金额是否计算正确。我建议准备一批手工计算好的测试数据，比如套餐免费300分钟，导入5条话单合计400分钟，超出100分钟，按0.15元/分钟计算，超额费用应该是15.00元。拿着这个预期值去验证系统输出，比看一堆页面有没有报错重要得多。

第二，切换一个全新的数据库重新初始化。很多同学在自己电脑上一路开发下来，数据库里的测试数据七零八落，状态字段的值也改得乱七八糟。提交前把数据库删掉，用干净的SQL脚本重新初始化，再跑一遍流程，能暴露表结构不完整、初始化脚本缺失的问题。这一步尤其重要，因为毕设答辩时评委很可能会要求你演示功能，但不会允许你用开发过程中残破的数据。

第三，把浏览器控制台打开，检查所有请求有没有报红。常见的情况是某个Ajax请求的URL写错了，导致页面部分功能无法加载，但你肉眼根本看不见。按F12打开开发者工具，切到Network面板，刷新页面，逐个请求看一眼状态码，200就过了，404或者500就要去深究一下原因。

7. 写在最后：关于这套系统还能怎么扩展

系统做完以后，如果你还有余力，我建议往下面任何一个方向做一点锦上添花的工作，效果都比堆页面好得多：

• 增加“预扣费”模式：用户通话完成后，实时从余额中扣减费用，余额不足时限制主叫。这是真实电信系统的后付费/预付费双模式设计，能体现你对业务的理解。
• 做一套数据可视化页面：用ECharts画月度收入趋势图、套餐用户分布饼图、消费排行柱状图，前端页面看起来立刻不一样。
• 引入多级套餐与优惠叠加：比如“家庭套餐三个人共享1000分钟通话”，这涉及套餐组概念和共享额度扣减，逻辑比单用户计费复杂一个档次。
• 用拦截器做登录权限控制：JSP项目里很多同学只做了简单的session判断，如果能用一个Interceptor统一校验登录状态和角色权限，会让代码结构更完整。

在扩展功能之前，一个基本的原则是：先保证现有功能不出bug，再去加新特性。很多同学喜欢一开始就撸起袖子写一堆花里胡哨的功能，结果主流程反而跑不通。计费系统的核心永远是“话单进来→费率匹配→费用算对→账单出对”，这个主线稳了，其他都是加分项。我个人带项目的经验是，把基础功能做扎实，远比追求页面数量要管用，评委问到你时，你心里也更有底气。希望这篇文章能帮你把这条主线理清楚，少踩点坑。