外币兑换最近整理了一个社区水电费管理系统的完整实现过程，这是个典型的 Java Web 项目，适合课程设计、毕业设计，也适合刚学完 Java 基础想找个完整项目练手的朋友。整个过程下来，我对 JSP/Servlet、MySQL、Tomcat、会话管理这些东西的理解比啃三个月书都扎实。标题里写的是"设计与实现"，所以这篇博文不只贴代码，我会把为什么这么设计、有哪些坑、怎么排查都讲清楚，你能直接照着复现出来。
整个系统解决的是传统社区水电费收缴靠手工记账、Excel 统计的痛点：抄表员挨家挨户记录，月底再汇总计算，用户想查自己用了多少度电、多少吨水，要么跑物业，要么打电话问，非常低效。这套管理系统把抄表、计费、缴费、账单查询、数据统计全部线上化，角色分成管理员、抄表员和普通住户，每个角色有自己的操作界面和权限边界。
1. 项目概述与需求分析
1.1 这个系统到底解决什么问题
先明确业务场景。一个社区可能有几百到几千户居民，每个月需要抄水表、电表，生成账单，通知住户缴费，最后还要统计收缴率、总用水用电量。手工模式下最烦的是几个问题：抄表数据容易抄错或漏抄，Excel 公式写错导致当月费用全乱，缴费状态靠纸质单据标记，住户找物业对账时翻半天票据也不一定说得清。
系统要解决的核心问题就是三件事：第一，抄表数据能及时准确地录入和保存；第二，系统能按规则自动计算本期费用；第三，缴费记录和账单状态能被住户随时查询、管理员统一管理。围绕这三件事，功能模块就被自然拆解出来。
1.2 功能模块与角色划分
我实现的时候把用户分为三个角色，这是需求分析阶段和实际踩坑之后确定的。管理员负责全局：管理住户信息、设置单价、查看统计报表、重置用户密码；抄表员负责录入每期水表电表读数；住户负责查询自己的账单、在线缴费、查看历史用量。
角色划分不是拍脑袋定的。最初我考虑过只分管理员和住户两种角色，但后来发现抄表员如果拥有住户管理权限，数据风险很大，而且实际业务里抄表员的工作非常单一，就是录表底数。所以最终拆成三套权限体系，登录后根据角色显示不同菜单，后端每个接口也要做角色校验，不能只靠前端隐藏按钮。
功能清单如下：
- 住户管理：添加、编辑、删除住户，绑定房间号和联系方式
- 抄表管理：按楼栋筛选抄表任务，录入本期水表/电表读数
- 账单管理：根据抄表读数自动生成账单，支持手工调整和作废
- 缴费管理：记录缴费操作，支持线下现金缴费登记和线上支付回调
- 查询统计：按时间、楼栋、住户维度筛选，展示应收、实收、欠费数据
- 系统管理：管理员密码修改、单价设置、用户角色分配
1.3 技术选型：为什么选 Java Web 而不是其他方案
标题限定为 Java Web，技术栈其实有两种主流选择。一种是传统 JSP + Servlet + JDBC + Tomcat，另一种是 Spring Boot + MyBatis + Thymeleaf。我最终选择的是传统 JSP + Servlet 方案，原因很直接：这种项目大多出现在课程设计和毕业设计里，需要展示你对 Web 基础原理的掌握程度，Servlet 的生命周期、请求转发与重定向、过滤器链、Session 管理这些内容是面试和答辩都绕不开的考点。
如果直接上 Spring Boot，很多底层细节会被框架屏蔽，答辩时老师问一句"你的过滤器是怎么生效的"，你说不出来原理就很被动。传统 JSP + Servlet 虽然写起来繁琐，但每个环节都手动控制，能真正把 Java Web 体系走通一遍。数据库用 MySQL，连接池用 C3P0，前端用 JSP + JSTL + jQuery，分页用 PageHelper 这类轻量工具也可以，但为了控制依赖我选择自己写分页。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计：水电费系统的地基
2.1 核心表结构拆解
数据库设计是这种管理系统的灵魂，我第一版随便建了三张表，结果做到后面一直别扭，后来重构了一版。最终稳定运行的核心表有六张：用户表、角色表、住户表、抄表记录表、账单表、缴费记录表。用户表和角色表做关联，住户表存房屋地址和当前表底数，抄表记录表存每期读数，账单表存计算后的费用，缴费记录表存实际缴纳情况。
这里的关键在于"用户"和"住户"要拆开。住户可能换租客，但房间是固定的，水电费挂在房间上更合理。用户表存 login_name、password、role_id、user_info_id，其中 user_info_id 关联到住户表或员工表。如果合到一张表里，后期换租客改用户信息会连带历史账单出问题。
具体字段设计上，我贴一下最核心的两张表结构。
sql复制CREATE TABLE meter_record (
id INT PRIMARY KEY AUTO_INCREMENT,
house_id INT NOT NULL COMMENT '住户ID',
meter_type TINYINT NOT NULL COMMENT '1电表 2水表',
prev_read DECIMAL(10,2) NOT NULL COMMENT '上期读数',
curr_read DECIMAL(10,2) NOT NULL COMMENT '本期读数',
read_date DATE NOT NULL,
reader_id INT NOT NULL COMMENT '抄表员ID',
create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_house_type_date (house_id, meter_type, read_date)
);
CREATE TABLE bill (
id INT PRIMARY KEY AUTO_INCREMENT,
house_id INT NOT NULL,
meter_rec_id INT NOT NULL COMMENT '抄表记录ID',
bill_month VARCHAR(7) NOT NULL COMMENT '账单月份，如2025-06',
water_amount DECIMAL(10,2) NOT NULL DEFAULT 0,
electric_amount DECIMAL(10,2) NOT NULL DEFAULT 0,
total_amount DECIMAL(10,2) NOT NULL,
status TINYINT NOT NULL DEFAULT 0 COMMENT '0待缴费 1已缴费 2作废 3部分缴纳',
pay_time DATETIME DEFAULT NULL,
UNIQUE KEY uk_house_month (house_id, bill_month)
);
meter_record 表加唯一索引最关键，防止同一户同一月份同一表型重复录入。bill 表通过 meter_rec_id 关联抄表记录，这样以后有纠纷时，能追溯到当时的读数和抄表人。
2.2 数据关系与字段设计细节
关系梳理清楚以后，字段设计也有一些细节值得注意。金额字段统一用 DECIMAL(10,2)，不用 float 或 double，二进制浮点数在累加和比较时有精度问题，一笔两笔看不出区别，整个社区几百户统计报表时差值就出来了。用 DECIMAL 后，Java 代码里也统一用 BigDecimal 接收，避免字符串转 double 再转回来出现 0.1 + 0.2 不等于 0.3 的尴尬。
所有时间字段用 DATETIME 而不是 TIMESTAMP，TIMESTAMP 上限是 2038 年，虽然这个系统大概率活不到那时候，但数据类型语义上 DATETIME 更直观。录入时间设置 DEFAULT CURRENT_TIMESTAMP，就不用每次插入都手动传时间。
还有一个很多人忽略的字段：账单表里的 bill_month。不要直接根据录入时间算月份，因为抄表录入可能滞后，比如 7 月初录入的是 6 月的水电数，如果按系统时间生成账单月份，整个 6 月数据就乱了。我在录入抄表记录的时候，会让抄表员选择抄表月份，或者根据上一个账单周期自动推导，这样月份永远和业务周期对齐。
2.3 抄表计费的数据模型陷阱
这里必须单独说一个我踩了两次的坑：阶梯计费怎么建模。很多社区电费不是固定单价，而是分档收费，比如每个月 200 度以内每度 0.5 元，超过 200 度部分每度 0.8 元。如果我把单价字段只设计成一个数字，阶梯计费就完全没法支持。
我最后的方案是建一个 fee_config 表：
sql复制CREATE TABLE fee_config (
id INT PRIMARY KEY AUTO_INCREMENT,
meter_type TINYINT NOT NULL,
tier_min DECIMAL(10,2) NOT NULL COMMENT '档位下限',
tier_max DECIMAL(10,2) DEFAULT NULL COMMENT '档位上限，NULL表示无限',
price DECIMAL(10,2) NOT NULL,
effective_date DATE NOT NULL
);
计算费用时，先查出当期的阶梯配置，再根据区间分段计算。比如用电量是 350 度，配置是 0-200 度 0.5 元，201-500 度 0.8 元，那么费用就是 200 * 0.5 + 150 * 0.8 = 220 元。水费同理，但阶梯区间可能不一样。
这个模型的另一层好处是支持调价。如果下个月单价变了，直接在 fee_config 里加一条新记录，通过 effective_date 区分，不影响历史账单。如果你的项目明确说不需要阶梯计费，那可以在 bill 表里直接冗余一个 price 字段，方便对账时展示单价，但我还是建议按 fee_config 来做，答辩和实际扩展都好说。
3. 核心功能实现：从登录到缴费的完整链路
3.1 用户登录与权限控制
登录模块是所有 Web 系统的门面，也是我花时间最多的地方。最开始我用最简单的方式：登录成功后把用户 ID 放在 Session 里，页面通过判断 session 里的 role 值显示不同菜单。后来测试时发现一个问题，用户直接访问 /admin/list.jsp 这样的路径，后端并不会拦截，意味着别人可以绕过登录页访问内部页面。
解决方案是写一个过滤器（Filter），在 web.xml 里配置拦截规则，或者用注解方式。过滤器的逻辑是：放行登录页、静态资源，其他请求都检查 Session 是否存在用户对象；不存在就重定向到登录页。如果是管理员接口，再额外校验 role 字段。
java复制@WebFilter("/*")
public class AuthFilter implements Filter {
public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest request = (HttpServletRequest) req;
HttpServletResponse response = (HttpServletResponse) resp;
String uri = request.getRequestURI();
if (uri.endsWith("/login.jsp") || uri.endsWith("/login")
|| uri.contains("/static/")) {
chain.doFilter(req, resp);
return;
}
Object user = request.getSession().getAttribute("loginUser");
if (user == null) {
response.sendRedirect(request.getContextPath() + "/login.jsp");
return;
}
chain.doFilter(req, resp);
}
}
密码存储上，明文存储是绝对不行的。我用 MD5 加盐的方式，盐值取用户名加固定字符串，这样即使数据库泄露也不能直接还原密码。虽然 MD5 不算安全，但这种小项目够用，如果你用 Spring Security 或者 BCrypt 会更规范，但传统 Servlet 里自己写个加盐 MD5 是常见做法。
3.2 抄表录入与费用计算逻辑
抄表流程是业务核心。抄表员进入抄表页面后，系统按楼栋列出待抄表的住户，显示该户上期表底数和本期录入框。这里有一个容易忽略的细节：上期表底数怎么取？不能靠抄表员自己翻记录，而是系统自动查询该户该表型最新一条 meter_record 的 curr_read 显示出来，防止录入时看错。
录入本期读数时要做几个校验：读数必须大于等于上期读数，否则直接提示异常；如果读数异常大，比如上期 1000 度这期突然 99999 度，很可能是误录，需要弹窗确认。这些校验在前端做一层，后端 Servlet 里再做一层，防止绕过页面直接用接口提交。
费用计算逻辑我封装在 BillService 里，核心代码是这样：
java复制public BigDecimal calcFee(BigDecimal currRead, BigDecimal prevRead, int meterType) {
BigDecimal usage = currRead.subtract(prevRead);
if (usage.compareTo(BigDecimal.ZERO) < 0) {
throw new BizException("本期读数不能小于上期读数");
}
List<FeeConfig> configs = feeConfigDao.findByTypeAndDate(meterType, new Date());
BigDecimal totalFee = BigDecimal.ZERO;
BigDecimal remaining = usage;
for (FeeConfig cfg : configs) {
if (remaining.compareTo(BigDecimal.ZERO) <= 0) break;
BigDecimal tierUsage = BigDecimal.ZERO;
if (cfg.getTierMax() == null) {
tierUsage = remaining;
} else {
BigDecimal tierTotal = cfg.getTierMax().subtract(cfg.getTierMin());
tierUsage = remaining.min(tierTotal);
}
totalFee = totalFee.add(tierUsage.multiply(cfg.getPrice()));
remaining = remaining.subtract(tierUsage);
}
return totalFee.setScale(2, RoundingMode.HALF_UP);
}
这里有个关键点：计算结果保留两位小数时，用 RoundingMode.HALF_UP，也就是四舍五入。不要用 BigDecimal.setScale(2) 默认模式，那个在某些情况下会抛异常或者做四舍五入之外的舍入，跟业务期望不一致。另外，如果用量为负数或者配置缺失，要及时抛出业务异常，由全局异常处理器转成友好提示。
生成账单后，系统会往 bill 表插入一条待缴费数据。为了保持计量数据不变，如果生成后发现算错了，不要直接改 meter_record，而是新建一条负向记录冲正，或者让 bill 状态变成作废再重新生成，这样审计起来清清楚楚。
3.3 缴费管理与账单状态流转
缴费模块有两条路径：住户在线缴费，以及管理员/收银员线下登记缴费。在线缴费我模拟的是支付宝/微信的回调流程，没有真正接入支付渠道，而是写了一个模拟支付接口，付款时直接把账单状态改成已缴费并记录支付流水。如果你需要真实接入，可以把支付调发起和回调确认做成两步，收到支付平台回调后再更新数据库状态，不要在前端跳转成功页就立即改状态，那样容易被伪造。
账单状态我用整数表示，只有 0 待缴费、1 已缴费、2 作废、3 部分缴纳。部分缴纳这个状态刚开始我没设计，后来物业反馈有的住户先交电费不交水费，或者只交一半，所以加上了一个 part_pay_amount 字段和部分缴纳状态。完整流程如下：
- 住户点击缴费，进入账单详情页
- 后端检查账单状态必须是 0 或 3，否则提示已缴费或已作废
- 发起缴费请求，后台开启事务
- 更新 bill 状态和缴费时间，插入 pay_record 记录
- 事务提交，返回缴费成功页面
事务处理非常关键。如果更新 bill 成功但插入 pay_record 失败，或反过来，就会出现账实不符。传统 Servlet 里手动管理事务比较繁琐，我封装了一个 TransactionTemplate 类，把连接绑定到当前线程，业务层里通过 try-catch 控制 commit 和 rollback。原理也不复杂，就是从一个自建的数据源工具类里获取连接，设置 autoCommit 为 false，业务成功后 commit，异常时 rollback 并还原 autoCommit。
3.4 数据可视化与统计报表
统计报表这趴是一开始最容易被忽略的，但做出来之后整个项目的完成度提升了一个档次。管理员首页需要展示本月应收总额、实收总额、收缴率、总用水量、总用电量，我用 ECharts 做了柱状图和折线图。数据来源是 SQL 的聚合查询，比如按月统计每个楼栋的应收实收：
sql复制SELECT h.building, SUM(b.total_amount) AS total_should,
SUM(CASE WHEN b.status = 1 THEN b.total_amount ELSE 0 END) AS total_paid
FROM bill b JOIN house h ON b.house_id = h.id
WHERE b.bill_month = ?
GROUP BY h.building
前端用 AJAX 请求这个接口，拿到 JSON 数组后 dispatch 到 ECharts 的 series 里。这里有个经验点：JSON 格式的字段名不要用驼峰和数据库字段混着来，最好在 SQL 里取别名，JavaBean 字段和 JSON key 一一对应，否则前端拿到数据还要做一层 map 转换，很啰嗦。
统计报表的 SQL 要特别注意空值处理。如果某个月完全没有账单，SUM 返回 NULL，前端图表会显示空值或异常。我在查询时用 IFNULL(SUM(...), 0) 做兜底。另外，不同楼栋可能有空置房，这些房间没有用量，统计时可以过滤掉，或者单独显示"空置"。
4. 实操过程：搭建、编码、部署的完整记录
4.1 环境准备与项目初始化
我用的是 JDK 8 + Tomcat 8.5 + MySQL 5.7，这个组合兼容性最好，网上资料也多。如果你电脑上装的是 JDK 17，会发现 Tomcat 版本和部分旧项目会有兼容问题，建议直接 JDK 8。集成开发环境用 IDEA 2024 版本，创建 Web 项目的方式和旧版略有不同，很多人卡在这一步。
IDEA 里创建传统 Web 项目，我一般不在向导里新建 Java EE 项目，而是自己手动搭目录结构。先在 IDEA 新建一个普通的 Java 项目，然后在项目结构里添加 Web 支持：点 File - Project Structure - Facets - Web，配置 Web 资源目录为 webapp，并添加 Artifacts 里的 Web Application Exploded。配置好后，开发时用 Tomcat 集成插件启动，或者把 war 包丢到 Tomcat 的 webapps 目录下。
项目的目录结构建议按规范分层：
text复制src/main/java
├── com/community
│ ├── common （过滤器、工具类、异常类）
│ ├── dao （JDBC 数据访问层）
│ ├── service （业务逻辑层）
│ ├── controller （Servlet 控制器）
│ ├── model （实体类）
src/main/resources
├── db.properties
├── c3p0-config.xml
webapp
├── static （css/js/images）
├── WEB-INF （web.xml，jsp）
└── index.jsp
为什么 controller 层叫 Servlet 而不叫 Controller？因为传统 Java Web 里 Servlet 就是控制器，角色等同 Spring MVC 的 Controller。我在项目里把所有 Servlet 的 URL 映射统一写成 /api/xxx 或 /xxxServlet，方便过滤器和管理。
4.2 前端页面设计与交互细节
JSP 页面我用了 JSTL 标签库和 EL 表达式，没有引入前端框架。主要原因是不想为了这个项目额外搞一套 Vue 或 React 环境，JSP 服务端渲染对常规 CRUD 页面完全够用。列表页用 JSTL 的 <c:forEach> 循环输出表格行，分页导航用 <c:url> 拼接查询参数。
细节上要注意，JSP 页面里如果直接用 ${param.page} 读取分页参数，需要判空和默认值，否则第一次加载时页码变成 null，SQL 拼接会出错。我在 Servlet 里统一接收并转换参数：
java复制int pageNum = 1;
String pageStr = request.getParameter("pageNum");
if (pageStr != null && pageStr.matches("\\d+")) {
pageNum = Integer.parseInt(pageStr);
}
前端提交表单时，所有必填项都要做校验。就用 HTML5 的 required 属性加 jQuery 的校验，比如水电表读数必须填写，且必须是数字。除了不能为空，我还把读数的输入框限制为只能输入数字和小数点，用 jQuery 绑定 input 事件过滤非法字符。这些小细节会让系统体验好很多，也减少后端不必要的异常处理。
缴费成功页面不要用 request.getRequestDispatcher().forward() 转发到成功页，否则用户刷新页面会重复提交。我用的 sendRedirect() 重定向到账单列表页，并且在列表页显示一个"缴费成功"的提示参数，这样刷新不会重复扣费。
4.3 后端接口与事务处理
每个核心业务我至少提供一个 Servlet 接口，接口命名保持动词风格，例如 /house/add、/meter/read、/bill/calc、/pay/submit。Servlet 里我用一个 baseServlet 做统一分发，通过 action 参数决定调用哪个方法，这样不用每个功能写一个 Servlet，目录数量可控。
实际书写时，这种分散的 doGet/doPost 里尽量只做参数解析、调用 service、结果转发三件事。所有业务逻辑放进 service，所有数据库操作放进 dao。曾经为了图省事，我在 Servlet 里直接写 JDBC 查询，后来想加个事务逻辑时发现代码已经引不出来了，只能推倒重来。分层设计前期看着麻烦，后期改需求时真的太省心了。
事务处理的细节我前面提过，再展开说下连接管理。我写了一个 JdbcUtils 类，基于 ThreadLocal 保存当前线程的 Connection：
java复制public class JdbcUtils {
private static final ThreadLocal<Connection> LOCAL = new ThreadLocal<>();
public static Connection getConnection() throws SQLException {
Connection conn = LOCAL.get();
if (conn == null) {
conn = DataSourceUtil.getDataSource().getConnection();
LOCAL.set(conn);
}
return conn;
}
public static void begin() throws SQLException {
getConnection().setAutoCommit(false);
}
public static void commit() throws SQLException {
Connection conn = LOCAL.get();
if (conn != null) conn.commit();
}
public static void rollback() throws SQLException {
Connection conn = LOCAL.get();
if (conn != null) conn.rollback();
}
public static void close() throws SQLException {
Connection conn = LOCAL.get();
if (conn != null) {
conn.setAutoCommit(true);
conn.close();
LOCAL.remove();
}
}
}
使用事务时，service 方法里用 try-catch-finally 包裹，finally 里调 close 归还连接。这套代码是我从项目迁移经验里总结出来的，虽然硬核但非常好用，你如果选用 Spring 的事务管理可以忽略，但理解这个原理后，框架的事务管理文档看起来也会轻松很多。
4.4 部署到 Tomcat 的注意事项
本地开发时用 IDEA 的 Tomcat 集成启动没问题，但给答辩或演示准备时，建议导出 war 包部署到独立 Tomcat。导出 war 在 IDEA 里选 Build Artifacts - Build，生成后在 target 目录下找到 war 文件，丢到 Tomcat 的 webapps 目录，启动 Tomcat 会自动解压部署。
这里有几个经典坑。第一，数据库驱动版本要匹配。MySQL 5.7 用 mysql-connector-java 5.1.x，MySQL 8.0 要用 8.0.x，驱动类名也不同，老项目用 com.mysql.jdbc.Driver 连 MySQL 8 会直接报类找不到。第二，c3p0 配置文件的数据库 URL 里的 characterEncoding=utf8 要写对，否则中文全变问号。第三，部署后浏览器访问会出现静态资源 404，检查 web.xml 的欢迎页配置和项目路径，访问地址必须是 http://localhost:8080/项目名/。如果是 ROOT.war 部署根路径，那就访问 http://localhost:8080/，不要多输项目名。
5. 常见问题与排查技巧实录
5.1 数据库连接失败与中文乱码
数据库连接失败是最常见的启动期问题，报错基本围绕着 com.mysql.jdbc.exceptions.jdbc4.CommunicationsException 或者 Access denied for user。前者多半是 MySQL 没有启动，或者端口不对，后者是用户名密码错误。排查思路先看 MySQL 服务状态，再确认 URL 里的 ip、port、库名。如果 MySQL 安装在本机，URL 里 localhost 和 127.0.0.1 可能有权限差异，我遇到过 localhost 连接正常、127.0.0.1 连接被拒的情况，因为 MySQL 用户表里 host 字段只授权了 'user'@'localhost'。
中文乱码分两类：页面乱码和数据库数据乱码。页面乱码多数是 JSP 文件编码和浏览器解码不一致，统一在 JSP 头部声明 <%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" %>，同时保证文件本身以 UTF-8 保存。数据库乱码则是连接 URL 没加 characterEncoding=utf8，或者表结构的字符集不是 utf8mb4。我统一把数据库连接参数写成：
text复制jdbc:mysql://localhost:3306/community_fee?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
serverTimezone 这个参数在 MySQL 8.x 上必须有，否则 JDBC 驱动会报时区错误。useSSL=false 是因为本地开发用不到 SSL，避免驱动额外校验。
5.2 金额精度丢失与重复缴费问题
金额精度问题我在开发中真实遇到过：统计报表算出的总金额比明细相加多了几分钱。最后定位到是 double 累加导致。比如 0.1 + 0.2 用 double 计算结果是 0.30000000000000004，页面显示时被格式化成了 0.3，但累加结果传接口或者导出 Excel 时会露馅。解决办法前面说过，数据库用 DECIMAL，计算用 BigDecimal，连前端传入的金额参数都用字符串接收再转 BigDecimal，不要用 Double.parseDouble。
重复缴费问题也很典型。我最初实现的缴费接口逻辑是：
- 查询账单状态
- 如果待缴费，更新状态为已缴费
- 插入支付记录
在高并发或用户连续点击提交时，两个请求同时查到"待缴费"，然后都执行更新和插入，就会产生两条缴费记录，账单状态覆盖混乱。解决方式是使用数据库乐观锁或唯一约束。我用的是「更新时带条件」的方式，SQL 写成：
sql复制UPDATE bill SET status = 1, pay_time = NOW()
WHERE id = ? AND status IN (0, 3)
更新影响行数为 0 说明状态已经被别人改了，此时直接提示"该账单已缴费，请勿重复操作"。这个方式简单可靠，不需要引入额外的锁机制。
5.3 会话过期与并发扣费
用户登录后挂在 Session 里的用户对象，默认 30 分钟不操作就会过期。前台用户可能填表填了半小时，提交时发现跳回登录页，体验很差。解决办法是给 Session 设置更长的超时时间，在 web.xml 里配置：
xml复制<session-config>
<session-timeout>60</session-timeout>
</session-config>
单位是分钟，我设的是 120 分钟。如果系统要更细致，可以在用户每次 AJAX 请求时刷新 Session 的 lastAccessTime，但一般情况下全局配置就够了。
并发扣费问题，除了前面说的更新条件判断，还牵扯到一个补偿逻辑：当支付回调已经被确认成功，但数据库更新的那一步抛异常了，怎么处理？我在模拟支付接口里做了状态机驱动，所有状态迁移都记录日志。某一步失败时，会触发定时任务去检查支付记录和账单状态是否一致，不一致就做补偿。对于演示项目你可以不用写那么重，但建议在支付记录表里加一个 status 字段，和 bill.status 分开管理，这样出问题的时候能快速定位。
5.4 排查工具与日志分析心得
说实话，传统 JSP/Servlet 项目的排查方式比 Spring Boot 原始一些，没有统一异常处理，所以日志规范尤其重要。我在项目里引入了 slf4j + logback，在 Servlet 的过滤器里打印每个请求的处理耗时，在 service 层打印关键业务参数。比如：
java复制logger.info("生成账单: houseId={}, month={}, water={}, electric={}, total={}",
houseId, month, waterAmt, elecAmt, total);
这样一旦账单金额不对，翻日志就能直接看到输入输出，不用靠猜。打印日志有讲究，业务关键参数要打，但密码、手机号这些敏感信息不能打。另外，异常堆栈不能只 e.printStackTrace()，要记录到日志文件，否则 Tomcat 控制台日志一滚屏，早先的报错就找不到了。
排查问题时我常用三把刀：第一看日志文件，重点是异常类型和 SQL 语句；第二连数据库手动执行出问题的 SQL，确认是数据问题还是代码问题；第三在关键 Servlet 方法入口临时加断点，用 DEBUG 模式跑一次完整请求，看参数和返回结果。我遇到过很多次"页面显示报错但日志没记录"的情况，基本都是因为异常被 try-catch 吞掉了，所以从写代码一开始就要禁止空 catch。
最后再说一个部署环境的细节。如果你把项目放到云服务器上演示，记得把 Tomcat 的 AccessLog 打开，这个日志能记录所有请求路径和状态码，对于排查用户反馈的"某个页面打不开"很有用。我用的配置是 Tomcat 默认的 Valve 方式，在 server.xml 的 Host 标签里放开对应注释即可。整个项目做下来，我的体会是：别急着追求花哨的前端效果和高深的技术栈，把数据库关系理清楚、把状态状态流转设计好，这个系统就已经成功了大半。代码量看起来不小，但每块都能讲清楚为什么这么写，这才是做项目最有收获的地方。