原生Servlet+MySQL企业财务管理系统：架构、事务与部署实践

简介：一套基于原生Servlet和MySQL数据库的企业财务管理系统设计与实现项目资料，面向Java Web学习者、毕业设计开发者以及需要参考完整业务场景的初中级工程师，系统遵循模块化设计，覆盖资产管理、负债管理、成本管理、财务分析等核心功能，完整展示了从数据库表设计、Servlet请求处理到JSP页面渲染的企业级开发路径。资源压缩包共14个文件、总体积117.82MB，内部包含可导入运行的SQL数据库脚本、项目源码压缩包、多份Word/PPT文档、三张界面截图以及三段操作演示视频，其中文档资料涵盖任务书、中期报告和最终毕业论文，视频演示了项目创建、部署、数据库搭建及主要功能操作流程，整体结构清晰方便按需查阅。当前已有88人学习浏览，借助完整源码、数据库脚本和配套视频文档，读者可以快速部署运行系统，深入理解财务模块的实现细节，也能为毕业设计或课程设计提供可直接扩展的代码基础和答辩参考素材。

1. 原生Servlet-MySQL企业财务管理系统：老技术栈为什么还在被选择

很多人看到“原生Servlet”四个字，第一反应是这技术早该进博物馆了，但在实际交付里，原生Servlet-MySQL企业财务管理系统仍然是中小型企业内部记账、凭证管理、科目余额查询和基础报表统计的常见选型。它不依赖任何重量级框架，请求从容器直接路由到Servlet，SQL和业务逻辑都能一眼看穿，出了问题不需要在框架的黑匣子里翻来翻去。标题里的“源码+数据库”说明这是一套完整可运行的交付物，拿到手改一改就能跑，既能当课程设计和毕业设计的技术底座，也能撑起小型团队的真实业务。

这套系统能解决什么问题？对于没有专职运维、预算有限的小公司来说，它管住了最核心的财务数据一致性：凭证借贷必须平衡、明细必须挂到有效科目、操作必须留痕。它适合三类人：正在做课程设计或毕业设计、需要把请求处理讲明白的学生；需要快速搭内部管理系统的开发者；以及那些被Spring全家桶绕晕了、想看看一次HTTP请求到底怎么被代码接住的从业者。

财务场景有个特点：宁可功能少，不能数据错。Servlet这种朴素架构恰恰把数据流的每一步都摊在明面上，没有自动注入、没有隐式约定，代码即文档。这也是为什么这么多年过去，这个组合还在被选择。

2. Servlet+MySQL架构拆解：三层职责、核心表与连接池选型

2.1 三层架构在财务系统里的落地：Servlet、Service、DAO怎么分

原生Servlet项目虽然没有框架的容器管理，但分层思想必须严格执行，甚至比框架项目更严格。财务系统的业务规则是堆在数据一致性上的，一张凭证借方总额必须等于贷方总额，这个校验如果散落在每个Servlet里，后面每加一个功能就复制一遍，早晚会漏掉某个入口。落在Service层，所有入口共用一套校验，这才是财务系统的底线。

三层职责划分是这样的：表现层的JSP管渲染，Servlet接请求、收参数、调服务、决定跳转；业务层的Service类管业务规则和事务边界；数据访问层的DAO类只做JDBC读写，一个DAO对应一张核心表。分层带来的直接好处是改动可控：会计科目编码规则变了，你只需要动科目相关的Service和DAO，而不是在多个Servlet里搜索同一段SQL。我在实际做过的模拟项目X里，最开始图省事把SQL直接写在Servlet里，三个月后被迫重构，一半时间花在找“这段SQL在哪几个Servlet里各有一份”上，血泪教训。

常见的代码结构长这样：

src ├── controller # Servlet，处理请求与跳转 │ ├── LoginServlet.java │ ├── VoucherServlet.java │ └── ReportServlet.java ├── service # 业务逻辑与事务边界 │ ├── VoucherService.java │ └── ReportService.java ├── dao # JDBC数据访问 │ ├── UserDao.java │ ├── VoucherDao.java │ └── AccountSubjectDao.java ├── entity # 实体类 │ ├── User.java │ └── Voucher.java └── util └── DBUtil.java

Servlet只做三件事：取参数、调Service、回JSP或JSON。凡是出现Servlet里直接拼SQL、直接处理事务的，都属于边界失控。一个反例是某同事把八百行逻辑全塞进一个Servlet，功能看着齐全，但改任何一个字段都要在里面翻半天，这种代码在财务系统里是灾难——因为字段是跟着会计准则走的，改动频率远高于普通管理系统。

2.2 核心数据表：科目、凭证、明细账的字段设计与索引

数据库设计决定业务能不能跑通。一个最小可用的财务管理系统，至少需要四张核心表，我一般还会建议加一张期间余额表用于月末结转和余额查询：

先说金额字段。所有涉及金额的列一律用DECIMAL(14,2)，这是财务系统的铁律。用double存金额，1.1 + 2.2会得到3.3000000000000003，账面不平的时候你根本分不清是真错了还是浮点精度丢了。DECIMAL(14,2)表示最多 12 位整数加 2 位小数，对绝大多数企业内部账目绰绰有余。

科目表为什么要单独建？因为科目有层级和方向。1001 库存现金是借方余额，2001 短期借款是贷方余额，记账时凭证必须按科目的余额方向填写。这个方向如果靠代码里硬编码，科目一多就无法维护，所以balance_direction字段（D借/C贷）是科目表的核心。我还见过把科目表砍掉、直接在凭证里写VARCHAR科目名的设计，查询汇总时连“管理费用一共多少”都统计不出来，这是典型的反面教材。

索引方面，凭证表按凭证号和时间查询最频繁，建(voucher_date, status)联合索引；明细表按凭证ID关联查询，voucher_id必须建索引，外键约束会自动建隐式索引，但显式写出来更利于理解。我见过一个翻车现场：某公司内部系统凭证积累到两万张后，明细账查询从 300 毫秒退化到 8 秒，原因就是voucher_detail表的voucher_id没建索引，每次都全表扫描。加上索引后直接回到 200 毫秒以内。

2.3 数据库连接：从DriverManager裸连到连接池改造

原生Servlet项目里，数据库连接有两种做法。裸连代码最简单，适合学习和低并发场景，一个工具类搞定：

public class DBUtil { // URL里必须带 characterEncoding 和 serverTimezone，缺一个都容易出乱码或时区报错 private static final String URL = "jdbc:mysql://localhost:3306/finance_db" + "?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai"; private static final String USER = "root"; private static final String PASSWORD = "123456"; static { try { Class.forName("com.mysql.cj.jdbc.Driver"); } catch (ClassNotFoundException e) { throw new ExceptionInInitializerError("找不到MySQL驱动，检查WEB-INF/lib下的jar包"); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } public static void close(Connection conn, Statement st, ResultSet rs) { if (rs != null) { try { rs.close(); } catch (SQLException ignore) {} } if (st != null) { try { st.close(); } catch (SQLException ignore) {} } if (conn != null) { try { conn.close(); } catch (SQLException ignore) {} } } }

这段代码的几个参数是踩坑高发区：characterEncoding=utf8保证中文不乱码；serverTimezone=Asia/Shanghai解决新版驱动时区报错；MySQL 8.x 的驱动类名是com.mysql.cj.jdbc.Driver，老项目里如果写的是com.mysql.jdbc.Driver，在 MySQL 8 下直接 ClassNotFound。

裸连的问题在于每次请求都重新建TCP连接、认证、断开，高并发下连接数会快速打满数据库。生产环境要换连接池。连接池的核心参数就那么几个：

把DBUtil.getConnection()从裸连换成从池子取连接，只动工具类这一个类，Service和DAO完全不用改——这是分层带来的第二个好处。要注意的是，用完的conn.close()在池子场景下不是真关闭，而是归还连接，所以DAO里的 try-with-resources 写法依然成立。

注意：连接池的“最大连接数”不是越大越好，财务管理系统并发本来就不高，20 足够，设成 200 反而会把数据库连接数打爆，报 “Too many connections” 时先从池子参数查起。

3. 把核心模块写成代码：登录鉴权、凭证录入与分页查询

3.1 登录与Session管理：会话超时与角色控制的实现细节

财务系统的登录和普通网站登录有个明显区别：必须区分角色。会计录凭证、出纳管现金、审核员审凭证、管理员建用户。角色权限如果只靠页面隐藏按钮，那纯属自欺欺人——直接拼URL就能绕过。正确做法是登录成功后把用户和角色写进Session，然后在Servlet入口统一校验。

登录Servlet的常见写法：

@WebServlet("/login") public class LoginServlet extends HttpServlet { @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 先统一编码，再做参数校验，顺序不能反 req.setCharacterEncoding("UTF-8"); String username = req.getParameter("username"); String password = req.getParameter("password"); // 参数为空的场景必须在Servlet层拦一道 if (username == null || username.trim().isEmpty() || password == null || password.isEmpty()) { req.setAttribute("error", "用户名和密码不能为空"); req.getRequestDispatcher("login.jsp").forward(req, resp); return; } User user = new UserDao().findByUsernameAndPassword(username, password); if (user == null) { req.setAttribute("error", "用户名或密码错误"); req.getRequestDispatcher("login.jsp").forward(req, resp); return; } HttpSession session = req.getSession(true); // 登录成功后重新创建session，防止会话固定攻击 session.invalidate(); session = req.getSession(true); session.setAttribute("loginUser", user); session.setMaxInactiveInterval(30 * 60); // 30分钟无操作自动失效 resp.sendRedirect(req.getContextPath() + "/index.jsp"); } }

这里有两个容易忽略的细节。第一，密码校验不要拿数据库明文直接equals，生产做法是存加盐哈希，登录时把输入密码哈希后再比对。很多教学项目直接存明文，如果这个系统要真给公司用，这是第一个要改的地方。第二，setMaxInactiveInterval单位是秒，30分钟是财务系统比较常见的会话超时时间——太短，会计填一张凭证的功夫就被踢出登录页；太长，财务数据在无人值守电脑上暴露过久。

另一个细节是session.invalidate()再重新创建，用来防会话固定攻击。攻击者先拿到一个会话ID诱导用户登录，登录成功后如果不换会话ID，攻击者就能冒用身份。这个写法在框架项目里是标配，原生Servlet里容易被漏掉。

3.2 凭证录入Servlet：参数校验、事务边界与批处理

凭证录入是整个系统最核心的写操作。一张凭证包含一条主表记录和至少两条明细记录（一借一贷），必须同时成功或同时失败，这就是典型的事务场景。如果主表插进去了、明细插入失败，账面上就会出现一张“只有借贷总额没有明细”的脏凭证。

Service层的保存方法示例：

public boolean saveVoucher(Voucher voucher, List<VoucherDetail> details) { Connection conn = null; PreparedStatement psVoucher = null; PreparedStatement psDetail = null; try { // 1. 业务校验：借贷必须平衡，这是财务铁律 BigDecimal debitTotal = BigDecimal.ZERO; BigDecimal creditTotal = BigDecimal.ZERO; for (VoucherDetail d : details) { debitTotal = debitTotal.add(d.getDebitAmount()); creditTotal = creditTotal.add(d.getCreditAmount()); } if (debitTotal.compareTo(creditTotal) != 0) { throw new BusinessException("凭证借贷不平衡，借方=" + debitTotal + " 贷方=" + creditTotal); } voucher.setDebitTotal(debitTotal); voucher.setCreditTotal(creditTotal); conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 关闭自动提交，事务开始 // 2. 插入凭证主表，并声明要返回自增主键 psVoucher = conn.prepareStatement( "INSERT INTO voucher(voucher_no, voucher_date, summary, debit_total, credit_total, status) " + "VALUES(?, ?, ?, ?, ?, ?)", Statement.RETURN_GENERATED_KEYS); psVoucher.setString(1, voucher.getVoucherNo()); psVoucher.setDate(2, new java.sql.Date(voucher.getVoucherDate().getTime())); psVoucher.setString(3, voucher.getSummary()); psVoucher.setBigDecimal(4, debitTotal); psVoucher.setBigDecimal(5, creditTotal); psVoucher.setString(6, "已审核"); psVoucher.executeUpdate(); // 3. 取出自增主键，供明细表做外键关联 long voucherId; try (ResultSet rs = psVoucher.getGeneratedKeys()) { rs.next(); voucherId = rs.getLong(1); } // 4. 明细表用批处理，避免逐条executeUpdate的多次网络往返 psDetail = conn.prepareStatement( "INSERT INTO voucher_detail(voucher_id, subject_code, summary, debit_amount, credit_amount) " + "VALUES(?, ?, ?, ?, ?)"); for (VoucherDetail d : details) { psDetail.setLong(1, voucherId); psDetail.setString(2, d.getSubjectCode()); psDetail.setString(3, d.getSummary()); psDetail.setBigDecimal(4, d.getDebitAmount()); psDetail.setBigDecimal(5, d.getCreditAmount()); psDetail.addBatch(); } psDetail.executeBatch(); conn.commit(); // 全部成功才提交 return true; } catch (Exception e) { if (conn != null) { try { conn.rollback(); } catch (SQLException ex) { ex.printStackTrace(); } } throw new RuntimeException("凭证保存失败", e); } finally { DBUtil.close(conn, psDetail, null); DBUtil.close(null, psVoucher, null); } }

这段代码的关键点。第一，setAutoCommit(false)必须在同一个Connection对象上执行，如果主表和明细分别调DBUtil.getConnection()拿不同的连接，事务就变成两个独立事务，commit和rollback都管不到对方——这是事务最常见的翻车姿势。第二，BigDecimal比较不能用equals，1.0和1.00的 scale 不同，equals返回 false，必须用compareTo。第三，executeBatch()一次提交一批明细，比循环executeUpdate()快很多，凭证明细动辄十几条时差异明显。第四，用getGeneratedKeys()拿自增主键，不要用SELECT MAX(id)再查一次，并发插入时会拿到别人的主键。

凭证保存前还要校验科目是否存在、科目余额方向和分录方向是否匹配，比如贷方科目如果是个借方余额科目，大概率是录错了。这些校验放在同一个方法里，有异常就 rollback，保证脏数据进不了库。

3.3 明细账查询：JOIN聚合与分页在原生Servlet里的写法

查询场景比写入更频繁：按期间查凭证、按科目查明细账、按摘要模糊搜索。原生Servlet没有现成分页组件，但分页本身不复杂，核心是 SQL 的LIMIT ?, ?加总数统计。

public List<Voucher> findVouchersByPage(int page, int pageSize, String startDate, String endDate) { // 半开区间写法：开始日期当天00:00:00，结束日期传下个月的1号 // 这样能完整覆盖结束日期当天的全部凭证，且不依赖 DATE() 函数 String sql = "SELECT id, voucher_no, voucher_date, summary, debit_total, credit_total, status " + "FROM voucher " + "WHERE voucher_date >= ? AND voucher_date < ? " + "ORDER BY voucher_date DESC, id DESC " + "LIMIT ?, ?"; int offset = (page - 1) * pageSize; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, startDate); // 例如 2024-06-01 ps.setString(2, endDate); // 例如 2024-07-01，即含6月1日至6月30日全天 ps.setInt(3, offset); ps.setInt(4, pageSize); try (ResultSet rs = ps.executeQuery()) { List<Voucher> list = new ArrayList<>(); while (rs.next()) { Voucher v = new Voucher(); v.setId(rs.getLong("id")); v.setVoucherNo(rs.getString("voucher_no")); v.setVoucherDate(rs.getDate("voucher_date")); v.setSummary(rs.getString("summary")); v.setDebitTotal(rs.getBigDecimal("debit_total")); v.setCreditTotal(rs.getBigDecimal("credit_total")); list.add(v); } return list; } } catch (SQLException e) { throw new RuntimeException("凭证分页查询失败", e); } }

配套的总数查询是SELECT COUNT(*) FROM voucher WHERE voucher_date >= ? AND voucher_date < ?，页面总页数用(total + pageSize - 1) / pageSize计算。分页参数有个常见错误：page从 1 开始，offset = (page - 1) * pageSize，直接把page当 offset 会导致第一页跳过前几条数据。

日期条件用了voucher_date >= ? AND voucher_date < ?的半开区间，而不是BETWEEN ? AND ?。原因是如果哪天字段从DATE改成DATETIME，BETWEEN '2024-06-01' AND '2024-06-30'会漏掉 6 月 30 日 00:00:00 之后的全部记录。半开区间没有这个边界问题。科目汇总查询则用GROUP BY subject_code聚合当月发生额，按科目维度生成发生额及余额表，这也是后面做报表的基础。

4. 让系统第一次启动就能跑通：建库脚本、初始化数据与部署配置

4.1 建库建表脚本：字符集、金额类型与索引的落地细节

拿到一个“源码+数据库”的财务系统项目，第一步永远先看数据库脚本，而不是先跑代码。脚本里藏着系统真正的设计意图：用什么字符集、金额字段用什么类型、外键怎么建、索引落在哪些列。一份合格的建库脚本至少包含下面这些：

CREATE DATABASE IF NOT EXISTS finance_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE finance_db; CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '用户内部ID', username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(64) NOT NULL COMMENT '密码哈希值，不要存明文', real_name VARCHAR(50) DEFAULT NULL COMMENT '真实姓名', role VARCHAR(20) NOT NULL DEFAULT 'accountant' COMMENT '角色: admin/accountant/auditor', created_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_role (role) ) ENGINE=InnoDB COMMENT='系统用户表'; CREATE TABLE account_subject ( id BIGINT PRIMARY KEY AUTO_INCREMENT, subject_code VARCHAR(20) NOT NULL UNIQUE COMMENT '科目编码，如1001', subject_name VARCHAR(100) NOT NULL COMMENT '科目名称，如库存现金', category VARCHAR(10) NOT NULL COMMENT '类别: 资产/负债/权益/成本/损益', balance_direction CHAR(1) NOT NULL COMMENT '余额方向: D借 / C贷', status TINYINT NOT NULL DEFAULT 1 COMMENT '1启用 0停用' ) ENGINE=InnoDB COMMENT='会计科目表'; CREATE TABLE voucher ( id BIGINT PRIMARY KEY AUTO_INCREMENT, voucher_no VARCHAR(30) NOT NULL COMMENT '凭证字号，如记-2024-06-001', voucher_date DATE NOT NULL COMMENT '记账日期', summary VARCHAR(200) DEFAULT NULL COMMENT '摘要', debit_total DECIMAL(14,2) NOT NULL DEFAULT 0 COMMENT '借方合计', credit_total DECIMAL(14,2) NOT NULL DEFAULT 0 COMMENT '贷方合计', status VARCHAR(10) NOT NULL DEFAULT '草稿' COMMENT '草稿/已审核/已记账', create_by BIGINT DEFAULT NULL COMMENT '录入人ID', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_date_status (voucher_date, status), KEY idx_voucher_no (voucher_no) ) ENGINE=InnoDB COMMENT='记账凭证主表'; CREATE TABLE voucher_detail ( id BIGINT PRIMARY KEY AUTO_INCREMENT, voucher_id BIGINT NOT NULL COMMENT '所属凭证ID', subject_code VARCHAR(20) NOT NULL COMMENT '会计科目编码', summary VARCHAR(200) DEFAULT NULL COMMENT '分录摘要', debit_amount DECIMAL(14,2) NOT NULL DEFAULT 0 COMMENT '借方金额', credit_amount DECIMAL(14,2) NOT NULL DEFAULT 0 COMMENT '贷方金额', KEY idx_voucher_id (voucher_id), KEY idx_subject_code (subject_code), CONSTRAINT fk_detail_voucher FOREIGN KEY (voucher_id) REFERENCES voucher(id) ) ENGINE=InnoDB COMMENT='凭证明细表';

脚本里的落地细节：整库用utf8mb4而不是utf8，因为MySQL的utf8最多存3字节，遇到生僻字会写入失败，凭证摘要里出现特殊字符时只有utf8mb4能存下。金额统一DECIMAL(14,2)，不允许出现FLOAT或DOUBLE。凭证表建(voucher_date, status)联合索引，覆盖“某时间段内某状态凭证”这个最高频查询；明细表的voucher_id显式建索引。所有表用InnoDB，支持事务和外键，财务场景缺一不可，MyISAM不支持行级锁和事务，用它做财务表是硬伤。

注意：如果脚本里出现SET FOREIGN_KEY_CHECKS = 0;，通常是导入时为了不受外键顺序限制。导入完成后一定恢复为 1，否则后续插入不受外键约束保护，删除父表记录时子表会留下悬空引用。

4.2 初始化数据：管理员账号、会计科目与演示凭证

建完表后系统还是空的，必须初始化一批数据才能登录和演示。初始化数据分三类：用户、科目、演示凭证。

-- 管理员账号：admin / admin123（这里存的是MD5哈希，实际项目应加盐） INSERT INTO sys_user(username, password, real_name, role) VALUES ('admin', 'e10adc3949ba59abbe56e057f20f883e', '系统管理员', 'admin'), ('acc001', 'e10adc3949ba59abbe56e057f20f883e', '张会计', 'accountant'); -- 一级会计科目：资产、负债、权益、成本、损益 INSERT INTO account_subject(subject_code, subject_name, category, balance_direction) VALUES ('1001', '库存现金', '资产', 'D'), ('1002', '银行存款', '资产', 'D'), ('1122', '应收账款', '资产', 'D'), ('2001', '短期借款', '负债', 'C'), ('2202', '应付账款', '负债', 'C'), ('4001', '实收资本', '权益', 'C'), ('5001', '生产成本', '成本', 'D'), ('6001', '主营业务收入', '损益', 'C'), ('6601', '销售费用', '损益', 'D'), ('6602', '管理费用', '损益', 'D'); -- 一张演示凭证：收到股东投资款，借贷必须平衡 INSERT INTO voucher(voucher_no, voucher_date, summary, debit_total, credit_total, status, create_by) VALUES ('记-2024-06-001', '2024-06-01', '收到投资款', 500000.00, 500000.00, '已审核', 1); INSERT INTO voucher_detail(voucher_id, subject_code, summary, debit_amount, credit_amount) VALUES (1, '1002', '收到投资款存入银行', 500000.00, 0), (1, '4001', '收到投资款', 0, 500000.00);

初始化数据的坑在于密码哈希必须和登录校验逻辑匹配。很多项目给的脚本存的是明文admin123，而登录代码里做了MD5加密，两边一比对，永远登录不进去。拿到别人的项目先确认登录校验是明文比对还是哈希比对，再决定初始化数据里放什么。演示凭证的金额要保持借贷平衡，否则第一个演示操作就报“借贷不平衡”，第一印象直接垮掉。

4.3 导入数据库与部署：从命令行导入到容器发布

数据库脚本准备好后，导入推荐用命令行而不是图形工具复制粘贴，因为命令行能明确指定字符集：

# 1. 先确认 MySQL 服务在运行 mysql -uroot -p # 2. 在 mysql 命令行里执行脚本 mysql> source /path/to/finance_db.sql; # 3. 或者不进入交互，直接用重定向导入 mysql -uroot -p --default-character-set=utf8mb4 < /path/to/finance_db.sql # 4. 验证导入结果 mysql -uroot -p -e "USE finance_db; SHOW TABLES; SELECT COUNT(*) FROM account_subject;"

导入过程中文变问号时，优先排查两件事：文件本身编码是否为 UTF-8（Windows 记事本默认可能存成 GBK，用编辑器转成 UTF-8 无 BOM 再导）；导入命令有没有带--default-character-set=utf8mb4。这两个坑症状完全一样，原因完全不同，按顺序排查基本十分钟定位。

部署方面，原生Servlet项目最终打成 war 包，放到 Servlet 容器的应用发布目录下。war 包的正确结构长这样：

finance.war ├── index.jsp ├── WEB-INF │ ├── web.xml │ ├── classes │ │ ├── controller/*.class │ │ ├── service/*.class │ │ ├── dao/*.class │ │ └── util/*.class │ └── lib │ └── mysql-connector-java-xxx.jar └── css/js/jsp文件

最典型的部署翻车点：JDBC 驱动 jar 没放在WEB-INF/lib下，而是放在容器公共目录，本地 IDE 开发时 classpath 正常，一部署就报ClassNotFoundException。第二个翻车点是 context path：部署名是finance，访问地址必须带/finance/前缀，代码里跳转如果写死/index.jsp，登录成功后必然 404。写跳转统一用req.getContextPath()拼接，从根上避开。用注解@WebServlet的类要求 Servlet 3.0 以上容器，老容器只认web.xml配置，这也是 A同学当时在老旧环境部署失败的原因。

5. 财务系统踩坑排查：5个高发故障的现象、原因与修复

5.1 页面乱码与金额精度丢失：字符集和BigDecimal的锅

现象：登录成功后页面中文全部变成问号“???”，或者金额100.10显示成100.1，更严重的，凭证两张明细加起来借贷差几分钱。

原因：乱码是字符集不一致——JSP 页面用 GBK 输出、Servlet 里setCharacterEncoding没写、数据库表是 latin1，三处只要一处不一致中文必乱。金额问题则是用了double或float做金额运算，二进制浮点数存不精确，累计到一定量账面就不平。

解决：字符集三层统一——数据库连接 URL 带characterEncoding=utf8，Servlet 和 Filter 里统一request.setCharacterEncoding("UTF-8")、response.setContentType("text/html;charset=UTF-8")，JSP 页面声明pageEncoding="UTF-8"。金额一律用BigDecimal，数据库字段DECIMAL(14,2)，查出来用rs.getBigDecimal()取而不是rs.getDouble()。排查顺序我一般固定为：先看响应头编码，再看连接串，最后看表结构，按这个顺序走很快能定位。

5.2 事务像没写一样：连接管理和自动提交的坑

现象：代码里明明写了setAutoCommit(false)和commit()，凭证主表插入成功的同时明细表报错，主表记录却留在库里没回滚。

原因：主表 DAO 和明细 DAO 各自调用DBUtil.getConnection()，拿到了两个不同的物理连接，commit 和 rollback 各管各的连接，事务自然失效。另一种隐蔽情况是finally块里有人提前把连接 close 了，连接一关，后续操作被隐式提交。

解决：事务的黄金法则是“一个业务操作全程只用同一个连接”。常见做法是 Service 层获取连接后通过方法参数传给 DAO，或者用线程绑定连接的方式传递。同时检查finally里的关闭顺序：先ResultSet、再Statement、最后Connection，反了会掩盖真实异常。排查时可以给连接打个日志输出 hashCode，主表和明细的 hashCode 不一样，问题就实锤了。

5.3 SQL注入与XSS：财务数据安全的第一道红线

现象：登录框输入' or '1'='1加任意密码能直接登录；在摘要框输入<script>alert(1)</script>，下次打开页面弹窗。

原因：登录 SQL 用了字符串拼接，比如SELECT * FROM sys_user WHERE username='+ username +'，输入值变成了 SQL 的一部分。XSS 则是用户输入原样输出到页面，被浏览器当脚本执行。财务系统里这两者都不可接受——注入能拖库，XSS 能劫持管理员会话。

解决：SQL 层全部用PreparedStatement占位符传参，这是硬性要求不是可选项。输出层，用户可控的内容（摘要、科目名）输出到页面时做 HTML 转义，<转<、>转>。还有容易漏的地方：导出 Excel 时摘要字段以=开头会触发公式注入，导出前也要做清洗。

5.4 跨月查询结果不对：日期边界与期间结转的处理

现象：查询 6 月凭证，发现 7 月 1 日凌晨的数据被统计了，或者 6 月 30 日下班后录入的几条凭证死活查不出来。

原因：日期条件写成了voucher_date <= '2024-06-30'，但表里如果是DATETIME类型，'2024-06-30'会被解析成2024-06-30 00:00:00，6 月 30 日 0 点之后的记录全被漏掉；反向场景是用了BETWEEN把边界日重复算了一遍。

解决：统一用半开区间voucher_date >= '2024-06-01' AND voucher_date < '2024-07-01'，结束日期传下月 1 号。既覆盖 6 月 30 日 23:59:59，又不带进 7 月数据。关联问题是月末结转：把损益类科目余额结转到本年利润，循环逐张凭证处理非常慢，常见做法是用一条GROUP BY subject_code汇总 SQL 生成结转凭证，性能差一个数量级。

5.5 部署后404和驱动找不到：war包结构与路径问题

现象：本地 IDE 运行正常，部署到服务器后要么访问直接 404，要么登录成功后跳到 404，要么启动时ClassNotFoundException: com.mysql.cj.jdbc.Driver。

原因：404 大概率是 context path 没对上——部署名是finance，访问路径必须带/finance/前缀，代码里跳转写死成了/index.jsp。ClassNotFound 是 JDBC 驱动 jar 没打进 war 的WEB-INF/lib。

解决：所有 Servlet 内跳转统一用req.getContextPath()拼前缀；用jar tf finance.war | grep mysql检查驱动 jar 是否在包里，没有就重新打包；对老容器，@WebServlet注解不生效，要在web.xml里补 Servlet 声明。部署后先看容器日志再试 URL，绝大多数原因日志里直接写了，比瞎试高效得多。

6. 从能跑到能交付：权限Filter、备份脚本与操作日志三件事

系统能跑通之后，离“能交付”还差三件事，这三件决定了它是演示 Demo 还是能真用的工具。

6.1 用Filter统一处理编码与登录校验

前面几章的编码和登录校验分散在各个 Servlet 里，每写一个重复一遍，迟早漏一个。收敛到一个 Filter：

@WebFilter("/*") public class EncodingAuthFilter implements Filter { @Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; // 1. 编码统一在这里处理，Servlet里不用再重复写 request.setCharacterEncoding("UTF-8"); response.setContentType("text/html;charset=UTF-8"); String uri = request.getRequestURI(); // 2. 放行登录接口和静态资源，其余全部拦截 if (uri.endsWith("/login") || uri.endsWith("login.jsp") || uri.contains("/css/") || uri.contains("/js/")) { chain.doFilter(req, resp); return; } // 3. 会话过期或未登录，一律回登录页 HttpSession session = request.getSession(false); Object loginUser = (session == null) ? null : session.getAttribute("loginUser"); if (loginUser == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } chain.doFilter(req, resp); } }

有了这个 Filter，新写的 Servlet 不用再关心编码和登录校验，只管业务。这是把横切逻辑从业务代码里拆出来的最朴素做法。

6.2 mysqldump定时备份与还原验证

财务数据丢不起，备份是义务不是选项。最小成本方案是mysqldump加定时任务：

#!/bin/bash BACKUP_DIR=/data/backup/finance DATE=$(date +%Y%m%d_%H%M%S) mkdir -p "$BACKUP_DIR" mysqldump -uroot -p'数据库密码' \ --single-transaction \ --default-character-set=utf8mb4 \ finance_db > "$BACKUP_DIR/finance_$DATE.sql" find "$BACKUP_DIR" -name "finance_*.sql" -mtime +30 -delete echo "备份完成: $BACKUP_DIR/finance_$DATE.sql"

--single-transaction是 InnoDB 一致性快照备份，不锁表，不影响业务读写。更安全的做法是不把密码写进脚本，改用 MySQL 配置文件里的[client]段或环境变量，避免脚本泄露密码。备份脚本写完必须做一次还原演练，导入到空库确认表和数据都在。没有验证过的备份等于没有备份。

6.3 操作日志表：让每一次记账都能追溯

财务系统区别于普通管理系统的硬要求是审计：谁在什么时间改过哪张凭证、改前改后各是什么值，都要留痕。实现上不复杂，建一张操作日志表，记录操作人、操作时间、操作类型、操作详情四个要素，插入日志的代码放进业务事务里，和业务操作同生共死。这样操作失败日志也不落库，保证日志和业务数据的一致性。再加一张日志查询页面，管理员能按时间、按操作人、按凭证号筛选，这套系统才具备真正交付的样子。

说到这想起我自己的一个习惯：几年前给某实验室做内部报销系统时，功能做完就交付，结果第二周对方打电话说数据对不上。查到最后是我把备份脚本写进了 crontab 但从来没验证过恢复流程，备份出来的文件本身就是坏的。从那以后我给自己立了规矩——凡是涉及数据的功能，交付前必须做一次从零恢复演练。这个习惯后来帮我避掉了不止一次麻烦。希望帮到你。

本文还有配套的精品资源，点击获取