企业官网建设流程全解析

简介：这份文档是面向软件工程、计算机相关专业学生及课程设计指导教师的专题实训资料，围绕基于WEB的洗浴中心管理系统展开，帮助读者理解如何将JAVA、ORACLE与Apache整合为一套可运行的B/S业务系统。资源包内共1个doc文件，约515KB，内容涵盖课程设计说明书规范、中英文摘要、目录结构及正文各章节，涉及部门管理、员工管理、服务人员管理、消费管理、会员管理、服务项目管理、商品管理、结账业务与统计管理等模块，并给出系统流程分析、总体设计与关键技术选型说明。目前已有106人学习浏览。读者可借此获得完整的课程设计文档模板、功能模块划分思路、B/S架构设计要点以及数据库与服务器部署的参考方案，适合用于实训报告撰写、系统设计借鉴与答辩准备。

1. 从一份 2013 年的课程设计说起：这套洗浴中心管理系统到底能跑出什么

翻到这份《洗浴中心管理系统》课程设计说明书的时候，我第一反应是——这玩意儿能跑吗？2013 年的东西，JAVA + ORACLE + Apache，B/S 架构，手牌管理、会员卡、商品消费、结账统计一应俱全。说实话，放到今天看，技术栈确实不新，但它的业务建模思路反而比很多现在赶工出来的 CRUD 项目要完整。整套系统围绕洗浴中心的核心动线展开：客人进门开手牌、消费服务项目和商品、会员卡扣费或现金结账、后台统计经营数据。它解决的不是什么高深技术问题，而是一个真实场景下的信息流转问题——手牌状态怎么实时同步、消费记录怎么跟手牌绑定、会员余额怎么在结账时准确扣减。适合谁看？正在做课程设计需要参考完整业务闭环的软件工程学生，以及想拿一个中小型管理系统练手三层架构和数据库设计的开发者。这份文档本身是设计说明书，不是源码包，但它把数据库表结构、模块划分、界面流程都写清楚了，照着复现一套能跑的代码完全可行。

2. 技术选型与三层架构落地：为什么是 JAVA + ORACLE + Apache

2.1 选型逻辑：2013 年的技术决策放到今天还成立吗

先别急着吐槽 ORACLE。在那个年代，课程设计任务书明确写了“数据库不能使用 Access”，可选技术栈是 JSP+SSH 或 ASP.NET。作者选了 JAVA 路线，数据库用 ORACLE，Web 服务器用 Apache。这个组合在当时是主流企业级配置，放到今天看，核心逻辑依然成立——JAVA 的跨平台能力让系统不绑死在某台 Windows 机器上，ORACLE 的事务处理和并发控制能保证结账时不会出现余额扣错的情况，Apache 作为前端接入层稳定且配置透明。

但如果你现在要复现，我建议把 ORACLE 换成 MySQL 或 PostgreSQL。原因很直接：ORACLE 的安装包体积大、授权费用高、课程设计场景下完全没必要。MySQL 在事务（InnoDB 引擎）和并发控制上足够支撑这个体量的系统，而且社区资料多，踩坑成本低。Apache 可以保留，也可以用 Nginx 替代，但 Apache 跟 Tomcat 的集成方案更成熟，对新手更友好。

三层架构的划分在这份文档里没有展开写，但从模块设计能反推出来：表现层是 JSP 页面（login.jsp 以及各管理界面），业务逻辑层处理手牌状态流转、会员扣费、结账计算，数据访问层通过 JDBC 或 Hibernate 操作 ORACLE。任务书里提到的 SSH 组合——Struts 做 MVC 调度、Spring 做依赖注入和事务管理、Hibernate 做 ORM 映射——是当时的标准答案。如果你现在复现，Spring Boot + MyBatis 或者 Spring Boot + JPA 会更省事，但核心分层思想不变。

2.2 环境搭建：从零把项目跑起来的具体步骤

假设你用的是 Windows 平台，目标是搭一套能跑的最小环境。以下步骤按顺序执行，不要跳。

第一步：安装 JDK 和 Tomcat。JDK 建议用 8 或 11，Tomcat 用 8.5 或 9。安装完配好 JAVA_HOME 和 CATALINA_HOME 环境变量。

# 验证 JDK 安装 java -version # 输出类似 java version "1.8.0_381" # 验证 Tomcat 能启动 cd %CATALINA_HOME%\bin startup.bat # 浏览器访问 http://localhost:8080 看到 Tomcat 欢迎页即成功

第二步：安装数据库。如果用 MySQL，装 5.7 或 8.0 都行。建库语句如下：

-- 创建数据库，字符集用 utf8mb4 避免中文乱码 CREATE DATABASE bath DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 创建专用用户，不要直接用 root 跑应用 CREATE USER 'bath_user'@'localhost' IDENTIFIED BY 'Bath@2024'; GRANT ALL PRIVILEGES ON bath.* TO 'bath_user'@'localhost'; FLUSH PRIVILEGES;

第三步：建表。文档里列了 11 张表：operators（操作员）、operecords（操作记录）、vips（会员）、projects（服务项目）、goods（商品）、signs（手牌）、waiters（服务人员）、selectfws（选择服务）、selectgoods（选择商品）、departments（部门）、bills（账单）。核心表的手牌和账单结构大概长这样：

-- 手牌表：记录每个手牌的状态和当前绑定 CREATE TABLE signs ( sign_id INT PRIMARY KEY AUTO_INCREMENT, sign_no VARCHAR(10) NOT NULL UNIQUE COMMENT '手牌编号', status TINYINT DEFAULT 0 COMMENT '0=空置 1=使用中 2=已结账待清理', current_vip_id INT DEFAULT NULL COMMENT '当前绑定的会员ID，散客为NULL', open_time DATETIME DEFAULT NULL COMMENT '开手牌时间', FOREIGN KEY (current_vip_id) REFERENCES vips(vip_id) ) ENGINE=InnoDB; -- 账单表：一次消费对应一条账单，结账时写入 CREATE TABLE bills ( bill_id INT PRIMARY KEY AUTO_INCREMENT, sign_no VARCHAR(10) NOT NULL, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, pay_method TINYINT COMMENT '1=现金 2=会员卡 3=移动支付', pay_time DATETIME DEFAULT CURRENT_TIMESTAMP, operator_id INT, FOREIGN KEY (operator_id) REFERENCES operators(op_id) ) ENGINE=InnoDB;

参数说明：status字段用 TINYINT 而不是 BOOLEAN，是为了后续扩展“已结账待清理”这种中间状态；current_vip_id允许为 NULL，因为散客不绑会员卡；pay_method预留了移动支付选项，虽然 2013 年没有，但现在复现时可以加上。

第四步：配置数据库连接。如果用 JDBC 直连，在WEB-INF/classes/db.properties里写：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/bath?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai jdbc.username=bath_user jdbc.password=Bath@2024

注意serverTimezone参数，MySQL 8.0 不配这个会报时区错误，这是血泪经验。

第五步：部署 WAR 包。把项目打成 WAR 丢进 Tomcat 的 webapps 目录，启动 Tomcat，访问http://localhost:8080/bath/login.jsp。如果看到登录页，环境就算通了。

提示：如果登录页报 404，先检查 WAR 包是否解压成功；如果报 500，看 Tomcat 日志里有没有数据库连接异常。

3. 核心模块拆解：手牌状态机、会员扣费与结账事务

3.1 手牌管理：一个被低估的状态机设计

手牌管理看起来简单——开手牌、关手牌、查状态——但它是整个系统的状态枢纽。文档里写“当手牌处于黑白状态(空置状态)时，单击状态图片可以进行启用操作”，这背后其实是一个状态机：空置 → 使用中 → 已结账待清理 → 空置。每次状态流转都要跟数据库同步，否则前台看到的手牌状态就是错的。

我一般会把手牌状态流转封装成一个 Service 方法，而不是散落在各个 JSP 里。核心逻辑如下：

// SignService.java 核心方法 public boolean openSign(String signNo, Integer vipId) { // 先查当前状态，防止并发重复开牌 Sign sign = signDao.findByNo(signNo); if (sign == null || sign.getStatus() != 0) { throw new BusinessException("手牌不可用，当前状态：" + sign.getStatus()); } // 更新状态和绑定信息 sign.setStatus(1); sign.setCurrentVipId(vipId); sign.setOpenTime(new Date()); return signDao.update(sign) > 0; } public boolean closeSign(String signNo) { Sign sign = signDao.findByNo(signNo); if (sign == null || sign.getStatus() != 1) { throw new BusinessException("手牌未在使用中，无法结账"); } sign.setStatus(2); // 待清理 return signDao.update(sign) > 0; }

逻辑说明：openSign先做状态校验再更新，避免两个前台同时给同一个手牌开牌。closeSign把状态置为 2 而不是直接置 0，是因为客人结账后可能还有物品遗留，需要服务员确认清理后再手动置 0。这个中间状态在文档里没写，但实际运营中必须有，否则手牌会被重复分配。

参数说明：vipId为 NULL 表示散客，不为 NULL 表示会员开牌，后续消费可以走会员卡扣费。

3.2 会员管理与消费扣费：余额扣减的原子性怎么保证

会员模块包括开卡、注销、修改卡信息、查询余额。文档里提到“前台可以开卡，注销卡，根据顾客要求修改卡内容，查询卡余额”，但没有展开扣费逻辑。实际场景中，会员卡扣费必须跟消费记录写入在同一个事务里，否则会出现“钱扣了但消费记录没写”或者反过来“消费记录写了但钱没扣”的玄学问题。

常见做法是用数据库事务包住两个操作：

// ConsumeService.java 会员扣费 @Transactional public void consumeByVip(Integer vipId, BigDecimal amount, String signNo) { // 1. 查会员当前余额，加行锁防止并发扣款 Vip vip = vipDao.findByIdForUpdate(vipId); if (vip.getBalance().compareTo(amount) < 0) { throw new BusinessException("余额不足，当前余额：" + vip.getBalance()); } // 2. 扣减余额 vip.setBalance(vip.getBalance().subtract(amount)); vipDao.update(vip); // 3. 写入消费记录 ConsumeRecord record = new ConsumeRecord(); record.setVipId(vipId); record.setAmount(amount); record.setSignNo(signNo); record.setConsumeTime(new Date()); consumeDao.insert(record); }

逻辑说明：findByIdForUpdate对应 SQL 里的SELECT ... FOR UPDATE，在事务中锁住这一行，防止两个收银台同时扣同一张卡的余额。@Transactional注解保证扣余额和写记录要么都成功，要么都回滚。

参数说明：amount用 BigDecimal 而不是 double，因为金额计算不能用浮点数，0.1 + 0.2 不等于 0.3 这种坑在结账时是致命的。

3.3 结账业务：把消费项汇总成一张账单

结账是系统里逻辑最密集的地方。一次结账要汇总手牌下的所有消费——服务项目、商品、可能的会员折扣——然后生成账单、更新手牌状态、扣减会员余额（如果用会员卡支付）。文档里把结账业务单独列为一个功能模块，说明作者意识到了它的复杂性。

我一般会这样组织结账流程：

// CheckoutService.java 结账主流程 @Transactional public Bill checkout(String signNo, Integer payMethod, Integer operatorId) { // 1. 查手牌下所有未结账的消费项 List<ConsumeItem> items = consumeItemDao.findUnpaidBySign(signNo); if (items.isEmpty()) { throw new BusinessException("该手牌无消费记录"); } // 2. 汇总金额 BigDecimal total = items.stream() .map(ConsumeItem::getAmount) .reduce(BigDecimal.ZERO, BigDecimal::add); // 3. 如果有会员绑定且用会员卡支付，走扣费 Sign sign = signDao.findByNo(signNo); if (payMethod == 2 && sign.getCurrentVipId() != null) { vipService.deductBalance(sign.getCurrentVipId(), total); } // 4. 生成账单 Bill bill = new Bill(); bill.setSignNo(signNo); bill.setTotalAmount(total); bill.setPayMethod(payMethod); bill.setOperatorId(operatorId); billDao.insert(bill); // 5. 标记消费项已结账 consumeItemDao.markPaidBySign(signNo); // 6. 关闭手牌 signService.closeSign(signNo); return bill; }

逻辑说明：整个结账在一个事务里完成，任何一步失败都回滚。第 3 步的会员扣费复用了VipService的方法，保证扣费逻辑统一。第 5 步用markPaidBySign批量更新，而不是逐条更新，减少数据库交互次数。

参数说明：payMethod枚举值 1=现金、2=会员卡、3=移动支付。operatorId记录是谁操作的，方便后续对账。

注意：如果结账时会员余额不足，不要直接抛异常让整个事务回滚，而是应该提示收银员“余额不足，是否改用现金支付”，然后重新走结账流程。这个交互细节文档里没写，但实际用的时候必须处理。

4. 数据库设计与统计模块：11 张表怎么撑起经营报表

4.1 表关系梳理：从手牌到账单的数据链路

文档里列了 11 张表，但没有画 ER 图。我按业务逻辑把它们串一下：departments和operators是基础数据，waiters是服务人员，vips是会员，projects和goods是消费项定义，signs是手牌，selectfws和selectgoods是手牌下的消费明细，bills是结账后的账单，operecords是操作日志。

关键链路是：开手牌（signs 插入或更新）→ 选服务/商品（selectfws、selectgoods 插入）→ 结账（bills 插入，selectfws/selectgoods 标记已结，signs 状态更新）。这条链路上任何一环断了，统计报表就不准。

常见做法是在selectfws和selectgoods表里加一个bill_id字段，结账时回填，这样统计时可以直接按账单维度汇总，不用再关联手牌。

-- 给消费明细表加账单关联字段 ALTER TABLE selectfws ADD COLUMN bill_id INT DEFAULT NULL COMMENT '结账后回填'; ALTER TABLE selectgoods ADD COLUMN bill_id INT DEFAULT NULL COMMENT '结账后回填'; -- 建索引加速统计查询 CREATE INDEX idx_selectfws_bill ON selectfws(bill_id); CREATE INDEX idx_selectgoods_bill ON selectgoods(bill_id);

4.2 统计管理：营业收入和热门项目的 SQL 怎么写

文档里提到“统计管理：生成各类报表，如营业收入、客流量、热门项目等”。这些报表本质上就是几条聚合 SQL。

营业收入按日汇总：

-- 按日统计营业收入，支持按支付方式拆分 SELECT DATE(pay_time) AS biz_date, COUNT(*) AS bill_count, SUM(total_amount) AS total_revenue, SUM(CASE WHEN pay_method = 1 THEN total_amount ELSE 0 END) AS cash_revenue, SUM(CASE WHEN pay_method = 2 THEN total_amount ELSE 0 END) AS vip_revenue FROM bills WHERE pay_time BETWEEN '2024-01-01' AND '2024-01-31' GROUP BY DATE(pay_time) ORDER BY biz_date DESC;

参数说明：pay_time上要建索引，否则数据量大了之后这个查询会拖垮数据库。CASE WHEN用来拆分支付方式，方便财务对账。

热门服务项目统计：

-- 统计各服务项目的消费次数和总收入 SELECT p.project_name, COUNT(sf.id) AS consume_count, SUM(p.price) AS total_income FROM selectfws sf JOIN projects p ON sf.project_id = p.project_id WHERE sf.bill_id IS NOT NULL -- 只统计已结账的 GROUP BY p.project_id, p.project_name ORDER BY consume_count DESC LIMIT 10;

逻辑说明：只统计bill_id IS NOT NULL的记录，避免把未结账的消费也算进去。LIMIT 10取前十，实际报表可以做成可配置的。

提示：统计查询不要在业务高峰期跑，最好做成定时任务或者单独走从库。如果数据量不大（日账单几千条以内），直接查主库也没问题。

5. 避坑与排查：复现这套系统时最容易翻车的五个地方

5.1 中文乱码：从 JSP 到数据库的全链路编码

现象：登录页输入中文用户名，后台查不到；或者商品名称存进数据库变成问号。

原因：JSP 页面编码、Tomcat 连接器编码、数据库字符集、JDBC 连接参数，四个地方只要有一个不是 UTF-8 就会乱码。

解决：JSP 页面头部加<%@ page contentType="text/html;charset=UTF-8" %>；Tomcat 的server.xml里 Connector 加URIEncoding="UTF-8"；数据库建库时指定utf8mb4；JDBC URL 加useUnicode=true&characterEncoding=utf8mb4。四个地方都对齐，乱码问题基本绝迹。

5.2 手牌状态并发冲突：两个收银台同时开同一个手牌

现象：前台 A 和前台 B 同时给手牌 08 开牌，结果两个客人都拿到了 08 号手牌。

原因：openSign方法先查状态再更新，查和更新之间有时间窗口，两个请求都查到“空置”状态，然后都执行了更新。

解决：用数据库行锁或者乐观锁。行锁方案是在查询时加FOR UPDATE，乐观锁方案是更新时加WHERE status = 0条件，根据受影响行数判断是否成功。

-- 乐观锁更新：只有状态还是 0 才更新成功 UPDATE signs SET status = 1, current_vip_id = ?, open_time = NOW() WHERE sign_no = ? AND status = 0; -- 返回受影响行数为 0 说明被别人抢先了

5.3 结账事务超时：消费项太多导致数据库连接被占满

现象：一个手牌消费了 50 多个项目，结账时页面卡死，最后报事务超时。

原因：结账事务里逐条更新消费项状态，50 条就是 50 次数据库交互，加上锁等待，事务持有时间过长。

解决：把逐条更新改成批量更新，一条 SQL 搞定。

-- 批量标记已结账，而不是循环单条更新 UPDATE selectfws SET bill_id = ? WHERE sign_no = ? AND bill_id IS NULL; UPDATE selectgoods SET bill_id = ? WHERE sign_no = ? AND bill_id IS NULL;

同时检查数据库连接池配置，maxActive不要设太小，至少 20 起步。

5.4 会员余额扣成负数：并发扣费没有加锁

现象：会员卡余额 100，两个收银台同时扣 80，结果余额变成 -60。

原因：扣费前查余额和扣费更新之间没有锁，两个请求都查到余额 100，都认为够扣。

解决：在事务中用SELECT ... FOR UPDATE锁住会员行，或者用原子更新UPDATE vips SET balance = balance - ? WHERE vip_id = ? AND balance >= ?，根据受影响行数判断是否扣成功。

5.5 Tomcat 启动报 ClassNotFound：JDBC 驱动没放对位置

现象：Tomcat 启动时报java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver。

原因：JDBC 驱动 jar 包没有放到WEB-INF/lib目录下，或者放到了 Tomcat 的lib目录但版本冲突。

解决：把 MySQL 驱动 jar 放到项目的WEB-INF/lib下，不要放到 Tomcat 的lib下。如果用的是 Maven，在pom.xml里加依赖，打包时会自动带进去。

<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency>

6. 从能跑到好用：三个让这套系统脱胎换骨的改造技巧

第一个技巧是把登录鉴权从 Session 改成 Token。文档里的登录是login.jsp记录用户权限到 Session，这在单机部署时没问题，但如果你想让老板在任何地点查看经营情况（文档摘要里明确提到了这个需求），Session 方案在跨域和移动端上会很别扭。改成 JWT 之后，前端可以把 Token 存在 localStorage 里，后端无状态校验，部署多台服务器也不用做 Session 共享。具体做法是在登录成功后生成 JWT，后续请求在 Header 里带Authorization: Bearer <token>，后端写一个 Filter 统一校验。

第二个技巧是给统计查询加缓存。营业收入、热门项目这些报表不需要实时精确到秒，缓存 5 分钟完全可接受。我一般用 Spring Cache + Redis 或者 Caffeine 做本地缓存，在统计方法上加@Cacheable(value = "revenue", key = "#date")，第一次查走数据库，后续直接读缓存。数据量大的时候这个优化能把报表加载时间从几秒降到几十毫秒。

第三个技巧是把手牌状态变更做成事件驱动。现在的手牌状态更新是同步写数据库，如果以后要加“手牌状态变更时自动通知服务员清理”或者“同步到前台大屏”，同步逻辑会越堆越多。改成发布事件的方式，手牌状态变更时发一个SignStatusChangedEvent，需要响应的模块各自监听处理，主流程不受影响。

// 发布事件，而不是直接调用各种后续逻辑 applicationEventPublisher.publishEvent( new SignStatusChangedEvent(signNo, oldStatus, newStatus) );

验证改造是否成功的方法很简单：开两个浏览器窗口，一个用管理员账号登录，一个用前台账号登录，同时操作同一个手牌，看状态是否实时同步、有没有出现并发冲突。再跑一遍结账流程，确认账单金额和会员余额扣减都对得上。

从那以后我每次复现这类管理系统，都会先把并发场景和事务边界画清楚再动手写代码，而不是先堆页面。这份 2013 年的课程设计文档虽然老，但它的模块划分和业务闭环是完整的，照着复现一遍，对三层架构和数据库事务的理解会比看十篇教程都扎实。希望帮到你。

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