又到了毕业设计选题的季节，这类题目年年都会出现：基于JSP的社区用电服务管理系统。我自己当年做毕设时选的就是这类Java Web管理系统，后来也帮不少学弟学妹看过相似题目。很多人一看“JSP”三个字母就开始犹豫，觉得技术太老，担心论文和答辩都没面子。但我的看法恰恰相反：JSP加Servlet这套经典Java Web组合，是做管理类毕设最稳的选择。这篇文章就围绕“社区用电服务管理系统”这个题目，把需求分析、数据库设计、核心代码实现、常见坑点、打包部署整个流程原原本本铺开，帮你把这个项目彻底吃透，顺带也能回答一部分“基于jsp的毕设选题”该怎么下手的问题。
1. 从选题到落地：这个毕业设计到底在做什么
1.1 需求背景：为什么社区用电需要一套管理系统
社区用电服务管理，拆开看其实特别直白：一个小区里住着几百上千户居民，每户都有电表，每个月要有专人查表、算电费、通知缴费；用户遇到电表异常、线路故障要上报维修；物业或管理方还要不定期发布停电通知和用电政策公告。这个闭环如果全靠Excel表格加微信群，效率非常低，而且特别容易出岔子——单子漏录了、电费算错了、报修没人跟进，都是日常操作。
毕设里的“社区用电服务管理系统”，核心就是把上面这套手动流程搬上Web：管理员在后台录入电表读数、生成账单、发布公告、处理报修；居民用户登录之后查看自己的用电量、账单明细、缴费记录，还能在线提交报修诉求。本质上，这是一个典型的管理信息系统，覆盖了数据采集、业务处理、服务响应三条主线，麻雀虽小，五脏俱全。对计算机专业的学生来说，这个题目最难得的地方在于，它既有明确的管理对象，又有完整的数据流转过程，不用像做商城项目那样硬编造一个“买买买”的需求出来。
一个能跑通全流程的社区用电系统，放在毕业设计里其实属于“小而完整”的典型样本：规模不大，但该有的技术点都有，该踩的坑也一个不少。这也是我后来帮人改代码时反复看到的结论——愿意把这个题目好好做完的人，毕业设计这一关基本都过得很轻松。
1.2 我的选题理由与整体技术选型思路
选题这一步我要说点实在话。很多同学看到“JSP”三个字母，第一反应是“这都什么年代了，JSP早过时了”。但毕业设计考察的从来不是技术新旧，而是你能不能把系统完整地做出来、讲清楚。JSP + Servlet + JavaBean 这套组合，恰好能把 Web 开发的完整主链路摊开在你面前：浏览器发起请求、Servlet接收处理、JavaBean承载业务逻辑、JDBC读写MySQL、数据回填到JSP页面渲染输出。整个流程没有黑盒，做完一遍，你对 Java Web 的认知会是立体的，而不是“调API调出来的”那种感觉。
我当时的技术栈是：JSP + Servlet + JavaBean + MySQL 8.0 + Tomcat 9，页面端用Bootstrap做基础布局，循环输出统一走JSTL和EL表达式。选这套组合有两个理由。第一，JSP动态页面表现力足够，特别适合这种页面数量较多的管理类系统，用户信息展示页、账单列表页、报修表单页都是它的主战场。第二，答辩时老师最爱问“页面和服务端怎么交互”“Session和Request什么区别”这类基础问题，用JSP项目来答，每个环节都有真实代码支撑，不会慌。
还有一个现实因素：这种JSP项目前端要求极低，基本用Bootstrap套一套模板就能把界面撑起来，不需要学React、Vue那套构建流程。对Java基础还不牢固、又想保住毕业设计的同学来说，这反而是最大的优势。项目周期大概安排三到四周：第一周搞需求分析和数据库，第二周写登录和用户模块，第三周攻抄表、账单、缴费这条主链路，最后一周补报修、公告、测试和文档，节奏是非常明确的。
2. 需求拆分与模块设计：两类角色六条业务链
2.1 角色权限设计：管理员与居民用户
系统整体分成两类角色：管理员和普通居民用户。管理员的职责写在四个字上——“管”：维护用户信息、管理电表档案、录入每月抄表数据、生成并发布电费账单、处理居民提交的报修单、发布公告通知。普通居民用户的核心是“用”：注册登录、查看个人信息、查询历史和当前用电量、查看电费账单、在线模拟缴费、提交报修并跟踪进度。
权限设计的落点在登录认证和角色拦截。我的做法是：登录成功后把用户对象放进Session，再写一个自定义Filter在每次请求时做登录检查，根据请求路径判断当前用户的角色是否允许访问。比如所有以/admin开头的页面只接受 role=admin 的用户，普通用户直接访问就返回403或重定向回登录页。这部分逻辑的细节我会在后面第四章专门展开。
这里有一个值得提前想清楚的问题：管理员和居民到底算一张表还是两张表？我的答案是一张表再加role字段。原因很简单，登录逻辑可以统一写一次，用户管理模块也只要维护一套增删改查，省掉大量重复代码。有的同学喜欢把两张表拆开，认为更符合“面向对象直觉”，但结果是登录时要先判断走哪张表，管理员也要维护居民账号，反而绕了一圈。
2.2 核心业务模块拆解
按功能我给系统拆成了六个模块，每一块对应一组页面和一组Servlet处理逻辑：
- 用户模块：注册、登录、个人信息修改、密码修改。
- 电表管理模块：管理员维护电表档案，包括电表编号、安装位置、所属用户。
- 抄表与用电模块：管理员按月录入电表读数，系统自动计算当月用电量。
- 账单与缴费模块：根据用电量乘以单价生成账单，用户查看账单并模拟缴费。
- 报修服务模块：用户提交报修，管理员接单、处理、结单。
- 公告模块：管理员发布公告，居民登录首页即可看到最新通知。
这些模块单独看都不复杂，但组合起来就是一条完整的业务链：从电表档案，到抄表读表，到账单生成，再到缴费和报修，每个页面都有明确的数据来源，每个Servlet都有明确的任务。做页面时也不会有“这块数据不知道从哪来、要显示到哪去”的迷茫感。
模块拆分还有个隐藏好处：答辩的时候，你可以直接按“业务链+模块”的方式介绍系统，老师一听就知道你是真的设计过，而不是把网上Demo改个标题就交上来。我建议你也按这个思路整理一份模块清单，提前写在答辩PPT里。
在页面规划上，居民端建议围绕“个人信息”做聚合展示，把手机号、地址、角色信息集中在一个页面；管理员端则建议做一个首页统计面板，展示待处理报修数、本月总用电量、未缴费账单数这几个核心数字。这些内容都属于锦上添花，但能明显提升整体完成度。
3. 数据库设计与表结构：7张表怎么关联最合理
3.1 数据库设计要点：表、字段、冗余与精度
先把结论放前面：这个系统的表数量控制在7张左右，就能把核心业务全部跑通。表一多容易把自己绕晕，表太少又会造成逻辑耦合。我最终的库设计如下：
| 表名 | 用途 | 关键字段 |
|---|---|---|
| user | 用户表（管理员+居民） | id, username, password, role, name, phone, address |
| meter | 电表档案表 | id, meter_no, user_id, address, install_date, status |
| reading | 抄表记录表 | id, meter_id, record_month, old_num, new_num, usage_kwh |
| bill | 电费账单表 | id, user_id, bill_month, usage_kwh, unit_price, total_amount, status |
| payment | 缴费记录表 | id, bill_id, user_id, pay_amount, pay_time |
| repair | 报修工单表 | id, user_id, device_type, fault_desc, status, create_time, handle_time |
| announcement | 公告表 | id, title, content, create_time |
设计上有几个点值得特别注意。首先，user表用role字段区分管理员和居民，登录逻辑统一在一块，减轻工作量。其次，reading表保存每个月的“抄见数”，当月用电量等于本月新读数减去上月旧读数，这个差值在录入时就计算好，冗余存入usage_kwh字段。这样生成账单时直接读取，SQL简单，也避免临时算错。第三，bill表的status字段只有两个值：0未缴费、1已缴费；缴费完成后由payment表记录实际流水，两表用bill_id关联。
还有精度问题：涉及钱和电量的字段，一律用DECIMAL而不是FLOAT或DOUBLE。很多同学做项目时图省事把金额存成double，结果算出来一堆0.30000000000000004这种怪数字，答辩时被老师当场指出，特别尴尬。数据库字段精度定好了，Java端配合BigDecimal，浮点误差问题就能从源头杜绝。
3.2 关键表结构与关联关系
下面贴两张核心表的建表SQL，可以直接拿来改。第一张是用户表：
CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) UNIQUE NOT NULL, password VARCHAR(64) NOT NULL, role VARCHAR(20) DEFAULT 'user', real_name VARCHAR(50), phone VARCHAR(20), address VARCHAR(200), create_time DATETIME DEFAULT CURRENT_TIMESTAMP );第二张是账单表，也是业务核心：
CREATE TABLE bill ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, bill_month VARCHAR(7) NOT NULL, usage_kwh DECIMAL(10,2) DEFAULT 0.00, unit_price DECIMAL(6,4) DEFAULT 0.5200, total_amount DECIMAL(10,2) GENERATED ALWAYS AS (usage_kwh * unit_price) STORED, status TINYINT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES user(id) );这里有实用技巧：total_amount用MySQL的生成列，只要usage_kwh和unit_price写入，总金额自动算好，省一层Java代码出错的可能。如果不想用生成列，也可以在Service层用BigDecimal手动计算再写入，效果一样。
各表关联关系简单过一遍：user是主表，meter.user_id指向user主键，记录“这台电表归谁”；reading.meter_id指向meter主键，记录“这台电表每个月查了几度”；bill.user_id直接指向user主键，查询用户账单时不必多联一张电表表；payment和repair表也都以user_id作为业务归属。announcement表相对独立，不参与外键关联，因为公告和业务没有直接绑定关系，硬加外键反而增加维护负担。
4. JSP核心功能实现：EL、Filter拦截与电费计算
4.1 JSP页面开发：EL表达式和JSTL替代Java脚本
很多初学者写JSP最顺手的就是<% %>脚本段，但一个项目里如果到处都是脚本段，页面会非常难维护，老师也容易给“分层不清晰”的评价。我的建议是：Servlet先把数据封装成对象放到request里，页面只用EL表达式和JSTL标签渲染。
比如普通用户查看本月账单，核心代码可以长这样：
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <c:forEach items="${billList}" var="bill"> <tr> <td>${bill.billMonth}</td> <td>${bill.usageKwh}</td> <td>${bill.unitPrice}</td> <td>${bill.totalAmount}</td> <td> <c:if test="${bill.status == 0}">未缴费</c:if> <c:if test="${bill.status == 1}">已缴费</c:if> </td> </tr> </c:forEach>要让这段代码正常工作，项目里必须导入jstl-1.2.jar和standard.jar这两个依赖，否则使用c标签时页面直接报错。除此之外，每个JSP页面顶部都建议加上<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8"%>，这句既是乱码预防也是页面规范。
EL表达式还有个常被忽略的坑：Servlet往request里放的属性名如果带大小写，EL访问时要完全一致。比如放的是billList，页面写${billList}没问题；一旦某处手滑写成${billlist}，大概率拿不到值，页面显示一个空白。建议项目里统一属性命名规则，别今天驼峰明天下划线，给自己留着排查线索。
4.2 登录认证与权限拦截：Session和Filter的配合方式
登录逻辑本身不复杂，查库比对用户名密码，通过后把用户对象放进Session。真正麻烦的是“每个请求都要校验登录状态，不同角色只能访问不同页面”。如果每个Servlet里都手写判断，代码会大量重复，而且很容易漏判。
正确做法是写一个Filter，统一拦截请求，核心逻辑如下：
public class LoginFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; HttpSession session = request.getSession(false); Object loginUser = session == null ? null : session.getAttribute("loginUser"); String uri = request.getRequestURI(); String contextPath = request.getContextPath(); String target = uri.substring(contextPath.length()); // 放行白名单：登录页、登录接口、注册接口、静态资源 if (target.startsWith("/login") || target.startsWith("/register") || target.startsWith("/static") || target.endsWith(".css") || target.endsWith(".js")) { chain.doFilter(req, resp); return; } if (loginUser == null) { response.sendRedirect(contextPath + "/login.jsp"); return; } // 角色判断：进入admin路径必须管理员 if (target.startsWith("/admin") && !"admin".equals(((User) loginUser).getRole())) { response.sendError(HttpServletResponse.SC_FORBIDDEN); return; } chain.doFilter(req, resp); } }这段代码我直接搬到项目里就能用。提醒一个细节：session判空这步千万别省，否则用户第一次访问没有session时，直接调用session.getAttribute()会抛NullPointerException。Filter写好后，后续每个Servlet都不用再管“用户有没有登录”，只管自己的业务，重复代码量会大幅下降。
在web.xml里注册Filter时，url-pattern建议写/*，让它覆盖所有请求。有些同学只写了/admin/*，结果普通用户的页面漏洞百出，各种“未登录也能打开详情页”的问题，都是拦截范围没覆盖导致的。
4.3 用电费用计算与展示：从抄表到账单
电费计算是整个系统业务味道最浓的地方。我的实现思路：管理员在抄表页面选择月份，录入某个电表的新读数，程序自动查上一次抄表记录里的旧读数，算出差值得到当月用电量，然后把用电量、单价、总金额写入该用户的当月账单。
计算精度是重点。用法：usage_kwh用DECIMAL(10,2)，unit_price用DECIMAL(6,4)，Java端不要用double相乘再转回BigDecimal，精度会丢。正确写法：
BigDecimal usage = new BigDecimal("213.50"); BigDecimal price = new BigDecimal("0.5200"); BigDecimal total = usage.multiply(price).setScale(2, RoundingMode.HALF_UP);如果要支持阶梯电价，写一个分段累加函数就行。比如200度以内0.52元/度，超过200度的部分按0.80元/度；算法类似个税累进，先用if判断落在哪个梯度，再拆段计算。逻辑不复杂，但答辩时讲清楚能加分。
页面展示上，居民端有一个“我的账单”列表，按月份倒序，已缴费的显示灰色状态，未缴费的旁边放一个“去缴费”按钮。缴费流程做成模拟支付即可：用户点击缴费，系统创建一条payment记录，同时把对应bill的status置为1，不接真实支付接口。数据库事务上，这两步操作应该放在一个事务里，要么都成功要么都失败，避免出现“钱交了但账单还是未缴费”的不一致。
5. 开发中的经典坑：环境、乱码和JDBC连接
5.1 环境配置：从IDEA新建JSP项目到Tomcat
网上搜“idea新建jsp项目”的人非常多，说明这步就卡住了不少人。我推荐直接用IDEA创建Java Enterprise项目，选Web Application模板，不要自己在普通Java项目里硬凑web目录，那样容易漏结构。项目创建后，先确认有webapp/WEB-INF/web.xml这个标准结构，再配置Tomcat：Run/Debug Configurations里选Tomcat Server—Local，Deployment里把项目的war exploded artifact加上即可。
启动后浏览器404，九成是访问路径问题。IDEA默认的部署名是工程名，建议改成简短英文名，不带中文和空格。比如部署名是jspElectricity，访问路径就是http://localhost:8080/jspElectricity/。少了这层工程名直接404，新人最容易在这个地方卡住。
还有Tomcat和JDK的版本匹配。JSP项目如果本地JDK是8，Tomcat用8.5或9比较稳；如果装了Java17，Tomcat9勉强能跑，但Tomcat7这种老版本直接启动失败。装环境之前先看一眼自己JDK版本，别下了个不兼容的Tomcat白折腾半小时。顺带一提，网上有人搜“springboot2 集成jsp 目录”，那属于另一个方向，毕设里没必要绕这个弯，直接用传统Tomcat项目结构更顺畅。
5.2 中文乱码：三个处理点缺一不可
JSP中文乱码是经典问题，表现形式百出：页面显示问号、数据库存进去乱码、请求参数变成%3F。根据我的经验，三个处理点缺一个都可能出乱码。
第一，所有JSP页面顶部统一加<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8"%>。第二，写一个编码过滤器，在请求进入Servlet之前调用request.setCharacterEncoding("UTF-8")，注意这个必须在第一次调用getParameter()之前执行，所以要放在Filter的doFilter最前面。第三，数据库连接串要带编码参数：
String url = "jdbc:mysql://localhost:3306/electricity_system?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai";还有一点容易被忽略：MySQL建库时要指定默认字符集。建库SQL后面加DEFAULT CHARSET=utf8mb4，否则插入中文直接变问号。如果库已经建错了，可以用ALTER DATABASE xxx CHARACTER SET utf8mb4;补救，表也要同步转换。这些设定看着琐碎，但一个环境不对，后面所有页面都会带着乱码问题，排查起来比写功能还费时间。
5.3 JDBC数据访问：连接管理与PreparedStatement
JDBC写DAO的时候，最容易踩的坑是重复连接数据库和忘记关资源。我建议写一个DBUtil工具类，用静态代码块加载驱动，封装getConnection()方法；读取数据用try-with-resources自动关闭结果集、Statement和连接。这一步看起来不起眼，但能避免大量“连接过多导致服务挂掉”的问题。
另一个更关键的习惯：所有SQL都走PreparedStatement，严禁字符串拼接。登录查询如果写成"SELECT * FROM user WHERE username='" + username + "' AND password='" + password + "'"，用户输入一个' OR '1'='1就把系统直接打穿。正确写法：
String sql = "SELECT * FROM user WHERE username=? AND password=?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, md5Password);密码存储也要提一句：不要明文存密码，建议MD5加盐后再存。答辩时老师问“你的系统安全性怎么保证”，你能说出PreparedStatement防注入、密码加密存储这两点，至少证明你有安全意识，而不是只会写业务功能的搬砖工。
6. 测试、打包与答辩：把项目完整收尾
6.1 功能测试要点：全链路跑通和边界数据
项目做完一定要站在用户视角走一遍全流程测试。我整理了一张测试主线表，照着走基本能把主要bug排干净：
| 测试场景 | 操作步骤 | 预期结果 |
|---|---|---|
| 注册 | 访问注册页，填写信息，提交 | 跳转登录页，数据库新增用户 |
| 登录 | 输入正确密码 | 跳转首页，Session写入用户 |
| 登录拦截 | 未登录直接访问用户中心 | 被重定向到登录页 |
| 抄表 | 管理员录入本月新读数 | 用电量正确计算 |
| 账单生成 | 管理员推送某月账单 | 用户端显示新账单，金额正确 |
| 缴费 | 居民点击缴费 | 账单状态变为已缴费，生成payment记录 |
| 报修 | 居民提交报修，管理员处理 | 状态流转：待处理到已处理到已结单 |
| 权限校验 | 普通用户直接访问/admin | 返回403或被拦截 |
建议把这条主线跑两遍：一遍正常数据，一遍边界数据。边界数据比如用电量为0、单价为0、密码全空、超大数值，最容易暴露页面展示层的异常。页面上的空指针异常，绝大多数都是在这种“临界情况”下冒出来的。
测试不只是盯着页面看，还要学会看后端日志。IDEA控制台里的Exception堆栈，对应到具体是哪个Servlet、哪一行代码，能精准定位问题。很多同学调试时只会用System.out.println，遇到空指针就懵了，其实把堆栈日志从头看到尾，技术点熟悉以后，排查速度会快很多。
6.2 打包部署：WAR包的生成与上线
“传统jsp项目打包war”是很多同学临近提交才搜的关键词，因为平时IDEA开发都是WAR exploded直接跑，根本不接触最终部署包。在IDEA里操作不复杂：打开Project Structure，选Artifacts，新建Web Application Archive，然后Build → Build Artifact，out目录下就会生成一个.war文件。把这个war放进Tomcat的webapps目录，启动Tomcat后会自动解压部署。
部署时要注意两件事。第一，war包名就是访问路径，比如jspElectricity.war打成后，访问地址是http://localhost:8080/jspElectricity/。第二，部署前检查数据库连接串，把地址、用户名、密码改成目标机器的MySQL配置，并且提前建好库和表。很多同学打包完部署起来连不上数据库，十有八九是连接串写死成开发环境地址，换台电脑就废了。
顺便回答一个经常被搜到的问题：nginx支持jsp吗？答案是否定的，nginx本身只处理静态资源，动态请求要反向代理到Tomcat去解析。不过毕业设计阶段一般不需要nginx，Tomcat单机直接跑起来就能演示，不要给自己增加额外的部署复杂度。
6.3 答辩时老师最常追问的五个问题
项目做出来只是上半场，答辩是下半场。我把我和身边同学被老师实际问过的问题整理出来，提前准备答案会从容很多：
- 为什么选择JSP而不是前后端分离？可以从毕业设计重在考察完整Java Web流程、JSP支持服务端渲染、分离架构增加部署复杂度这几个角度回答。
- 数据库为什么这么设计？讲清楚每条外键的设计理由，比如bill表直接关联user是为了减少查询链路。
- 角色权限怎么控制的？直接描述Filter和Session的实现，再把第四章的代码逻辑复述一遍。
- 电费怎么算的？把从抄表到账单的链路讲清楚，顺便说自己用BigDecimal避免精度丢失。
- 你遇到的最大难点是什么？别说什么难点都没有，讲一个你真实解决过的坑，比如中文乱码、Tomcat部署都行，真实感永远比完美值钱。
答辩前一晚再把全流程操作一遍，确保演示时不出岔子。从注册、登录到抄表、生成账单、缴费、报修，整套流程在两分钟内能走通的话，底气基本就足了。我自己当年答辩前也是这样反复演示，真正站上讲台其实十几分钟就讲完了，但因为每个页面都跑过无数遍，老师问什么都接得住，最后顺利通过。
