企业官网建设流程全解析

简介：这是一套面向计算机专业学习者与课程设计开发者的酒店温控计费系统源码，采用Java与Qt混合技术栈，以客户端服务器架构实现中央空调集中控制与房间空调计费。服务器端作为中央空调统一响应各分控请求，通过WebSocket协议以JSON格式通信，并借助数据库记录消费明细；客户端分为房间空调端与前台管理员端，前者提供空调操作界面并实时显示资费，后者负责开房退房、打印详单及权限管理。资源包共41个文件，约5.01MB，包含Java服务端源码、C++与Qt界面文件、ui与qrc资源描述、pro工程配置，以及需求分析、用例模型、静态与动态结构设计等docx与doc文档，另附MySQL连接jar包和接口定义说明，便于理解通信协议与数据表设计。目前已有62人浏览学习，适合作为Java网络编程、Qt界面开发与数据库综合实践的参考案例，可帮助读者掌握多端通信、计费逻辑与工程目录组织方式。

1. 从一份酒店空调计费源码说起：Java 后端加 Qt 前端的真实拼法

酒店中央空调按房间计费这件事，听起来像个简单的小工具，真动手做才发现坑不少：房间空调要实时显示余额，前台要能开房退房打详单，服务器要扛住几十个房间同时上报用量，还得保证计费不重不漏。这份基于 Java 和 Qt 的酒店温控计费系统源码，正好把这条链路完整走了一遍——服务器端用 Java 处理 WebSocket 请求和计费逻辑，客户端拆成房间空调端和前台管理员端两个 Qt 程序，数据落 MySQL，通信走 JSON。它适合正在做课程设计、想找一个「客户端服务器 + 实时通信 + 计费」完整案例的开发者，也适合想看看 Qt 桌面端怎么和 Java 后端对接的熟手。下面我按拆包顺序，把结构、跑法、参数和踩过的坑一条条讲清楚。

2. 拆开压缩包：三端结构、通信协议与数据落点

拿到源码先别急着编译，把目录结构摸清楚，后面配环境才不会乱。这个包本质上是三个独立工程加一堆设计文档，理解它们怎么协作，比记住某个类名重要得多。

2.1 三端工程与文档的对应关系

解压后能看到几个明显的分块：Server目录是 Java 服务端，Client是房间空调端，Manager是前台管理员端，另外还有一批0_业务背景.docx、2_用户需求分析及领域模型.docx、4_动态结构设计.docx这类设计文档。文档不是摆设，接口定义.md和README.md里写了通信字段，4_动态结构设计.docx里有交互时序，先扫一遍能省掉大量猜字段的时间。

服务端核心类分工大致是这样：

客户端这边，Client和Manager各有一套main.cpp、.ui、.pro，说明它们是两个独立可执行程序，共用Image目录下的powerOn.png、powerOff.png做开关机图标。workthread.h是客户端的工作线程，负责把网络收发放到后台，避免界面卡死。

2.2 WebSocket + JSON 的通信约定

服务端和客户端之间走 WebSocket，数据格式是 JSON，这是整个系统能实时刷新资费的关键。房间端每次操作（开机、调温、关机）都发一条指令上去，服务端算完把余额和状态回推。Instruct.java和Response.java就是这两类报文的载体，字段名要和接口定义.md对齐，否则解析直接失败。

常见做法是让指令带一个类型字段加若干参数，比如开机带房间号，调温带目标温度。下面是我按这类项目惯例整理的一个指令结构示意，实际字段以接口定义.md为准：

{ "type": "POWER_ON", "roomId": "301", "targetTemp": 24, "timestamp": 1710000000000 }

type决定服务端走哪个分支，roomId用来定位房间和计费账户，targetTemp是设定温度，timestamp用于按时间累计费用。服务端收到后由ServeThread分发到Core计费，再把结果写进Response回推。这里有个容易忽略的点：时间戳最好由服务端生成或校验，纯信客户端时间，改个系统时间就能少扣费，这是计费系统的大忌。

2.3 数据库与依赖 jar

包里带了mysql-connector-java-8.0.16.jar，说明服务端用 JDBC 直连 MySQL，没有走 ORM 框架。DataAccess.java里应该就是建连接、拼 SQL、读写消费记录。data.json更像是启动时的初始配置，比如房间列表和基础费率，避免每次都要查库。

依赖这块要注意版本：MySQL Connector 8.0.16 对应的是 MySQL 8.x 服务端，驱动类名是com.mysql.cj.jdbc.Driver，连接串要带时区和 SSL 参数，否则连不上。这一点在下一章配环境时会具体展开。

3. 把服务端跑起来：JDK、MySQL 与连接参数

服务端是整个系统的心脏，它不通，两个 Qt 客户端连上来也是白搭。这一章按「先能启动、再能连库、最后能收发」的顺序推进，每一步都给可抄的命令和参数。

3.1 环境准备与编译

Java 端建议用 JDK 8 或 JDK 11，这两个版本对老项目的兼容性最稳。先确认版本：

java -version javac -version

如果输出是 1.8 或 11 就够用。接着把mysql-connector-java-8.0.16.jar放进 classpath。假设源码在Server目录下，编译命令大致是：

# 进入服务端源码目录 cd Server # 编译所有 java 文件，把驱动 jar 加进 classpath javac -encoding UTF-8 -cp ".;mysql-connector-java-8.0.16.jar" *.java

Windows 下 classpath 分隔符是分号;，Linux 和 macOS 下换成冒号:，这是新手最常翻车的地方之一。-encoding UTF-8也别省，源码里有中文注释或字符串时，不指定编码可能编译报错或乱码。

编译通过后运行：

java -cp ".;mysql-connector-java-8.0.16.jar" Main

Main是入口类，具体类名以Main.java里的public static void main所在类为准。启动后如果控制台打印监听端口信息，说明服务端起来了。

3.2 MySQL 建库与连接串参数

服务端要落消费记录，得先有库和表。按DataAccess.java里的 SQL 反推建表结构，常见是房间表加消费记录表：

CREATE DATABASE hotel_ac CHARACTER SET utf8mb4; USE hotel_ac; CREATE TABLE room ( room_id VARCHAR(16) PRIMARY KEY, status TINYINT DEFAULT 0, balance DECIMAL(10,2) DEFAULT 0 ); CREATE TABLE consume_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, room_id VARCHAR(16), amount DECIMAL(10,2), create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

字段名要和DataAccess.java里的 SQL 完全一致，否则运行时报Unknown column。连接串是另一个高频坑点，MySQL 8 的驱动必须带时区和 SSL 参数：

String url = "jdbc:mysql://127.0.0.1:3306/hotel_ac" + "?useSSL=false" + "&serverTimezone=Asia/Shanghai" + "&characterEncoding=utf8" + "&allowPublicKeyRetrieval=true"; String user = "root"; String password = "你的密码";

serverTimezone不设，8.0 驱动会直接抛时区异常；useSSL=false在本地开发省掉证书麻烦；allowPublicKeyRetrieval=true是 8.0 认证插件的要求。这几个参数少一个都可能连不上，血泪经验是先把连接串调通再谈业务。

3.3 验证服务端能收发

服务端起来后，别急着开 Qt 界面，先用一个最小 WebSocket 客户端压一下，确认端口和协议没问题。可以用浏览器控制台或任意 WebSocket 测试工具连上去发一条 JSON：

// 在浏览器控制台里快速验证服务端是否响应 const ws = new WebSocket("ws://127.0.0.1:8888"); ws.onopen = () => { ws.send(JSON.stringify({ type: "POWER_ON", roomId: "301", targetTemp: 24 })); }; ws.onmessage = (e) => { console.log("服务端返回:", e.data); };

端口号以Server.java里绑定的为准，别照抄。如果onmessage能收到带余额的响应，说明服务端、计费、回推这条链路是通的。收不到就回头看服务端控制台有没有异常堆栈，多半是 JSON 字段名对不上或房间号在库里不存在。

4. 编译 Qt 两端：.pro 配置、qrc 资源与界面联调

Qt 这两端是用户真正看到的东西，房间端负责操作和显示资费，管理端负责开房退房。它们各自独立编译，但共用一套图片资源，配置上有不少共性。

4.1 Qt 版本选择与 .pro 文件解读

这个项目用的是 Qt Widgets，不是 QML，所以qt qml、qt mvvm框架这些热词在这里用不上，老老实实装 Qt 5.15.2 或 Qt 6 的 Widgets 组件即可。安装时勾选对应编译套件（MinGW 或 MSVC），别只装 Qt Creator 不装套件，否则打开.pro会提示找不到 kit。

Client.pro和Manager.pro是 qmake 工程文件，里面通常声明了QT += core gui network和websockets。WebSocket 在 Qt 里是独立模块，.pro里没写QT += websockets就会报unknown module(s) in qt: websockets，这和热词里那个unknown module(s) in qt: webenginewidgets是同一类问题——模块没装或没声明。检查.pro：

QT += core gui network websockets TARGET = Client TEMPLATE = app SOURCES += main.cpp client.cpp workthread.cpp HEADERS += client.h workthread.h FORMS += client.ui RESOURCES += image.qrc

websockets必须在QT +=里，RESOURCES指向image.qrc，图片才能被打进可执行文件。少写一行，编译能过但运行时图标全空。

4.2 qrc 资源与图片路径

image.qrc和pic.qrc把powerOn.png、powerOff.png这些图片注册成 Qt 资源，代码里用:/image/powerOn.png这种带冒号的路径访问。常见翻车是图片实际路径和 qrc 里写的前缀不一致，界面能起来但按钮是空白。

<RCC> <qresource prefix="/image"> <file>powerOn.png</file> <file>powerOff.png</file> </qresource> </RCC>

prefix是虚拟目录，file是相对 qrc 文件的真实路径。改完 qrc 一定要重新执行 qmake（Qt Creator 里是「构建」→「执行 qmake」），否则资源不会重新编译进去。这个玄学问题坑过太多人：明明改了图，跑起来还是旧的。

4.3 客户端连接服务端的地址配置

客户端要连服务端，地址和端口一般写在client.cpp或某个配置常量里。本地联调时指向127.0.0.1，如果服务端在另一台机器，改成那台的 IP。这里有个边界：Qt 的 WebSocket 客户端在连接失败时不会自动重连，界面会一直显示未连接，得手动加重连逻辑或重启客户端。

// client.cpp 里初始化连接，地址按实际部署改 QUrl url("ws://127.0.0.1:8888"); webSocket.open(url); connect(&webSocket, &QWebSocket::textMessageReceived, this, &Client::onMessageReceived);

onMessageReceived里解析 JSON 更新界面余额和温度。解析建议用QJsonDocument，别用字符串截取，字段顺序一变就崩。联调顺序推荐：先起服务端，再起管理端开房，最后起房间端操作，这样房间在库里有记录，计费才有依据。

5. 避坑与排查：从连不上到算错账的五个真实问题

这套系统涉及 Java、Qt、MySQL、WebSocket 四层，任何一层出问题表现都可能是「界面没反应」，排查时容易抓瞎。下面五条是我按这类项目最常见的故障整理的，每条按现象、原因、解决走一遍。

5.1 客户端一直显示未连接

现象：Qt 客户端启动后状态栏显示未连接，点开关机没反应。

原因：服务端没起、端口写错，或者防火墙拦了 WebSocket 端口。也可能是.pro里漏了websockets模块，编译时没报错但运行时连接对象无效。

解决：先用 3.3 的浏览器脚本确认服务端端口可连；再核对客户端里的 URL 端口和服务端Server.java绑定端口是否一致；最后检查.pro的QT +=是否含websockets，改完重新 qmake。

5.2 服务端启动报数据库连接异常

现象：Main一运行就抛Communications link failure或时区相关异常。

原因：MySQL 没启动、连接串缺serverTimezone、驱动版本和服务端不匹配，或者账号密码错。

解决：先mysql -u root -p手动登一次确认库活着；再检查连接串是否带serverTimezone=Asia/Shanghai和useSSL=false；确认用的是mysql-connector-java-8.0.16.jar而不是更老的 5.x 驱动，5.x 驱动类名是com.mysql.jdbc.Driver，和 8.x 不通用。

5.3 界面图标不显示

现象：程序能跑，但开关机按钮是空白或裂图。

原因：qrc 里的路径和实际图片路径不一致，或者改了 qrc 没重新执行 qmake。

解决：打开image.qrc核对file路径，确保powerOn.png和 qrc 在同一相对目录下；改完在 Qt Creator 里执行 qmake 再重新构建。资源路径用:/image/xxx.png，冒号不能丢。

5.4 计费金额对不上

现象：房间用了很久，余额扣得比预期少或多。

原因：时间戳由客户端提供且未校验，或者Core.java里费率单位换算错（比如按分钟算却当成小时），再或者并发下多个线程同时改余额没加锁。

解决：时间戳改由服务端生成；核对Core.java里费率的单位和计费周期；余额更新用数据库行锁或synchronized保护，避免两个请求同时读到旧值。计费系统里这类并发问题最隐蔽，测试时用两个客户端同时操作同一房间能复现。

5.5 中文乱码

现象：房间号或提示文字显示成问号或方块。

原因：编译没加-encoding UTF-8，数据库字符集不是utf8mb4，或者 Qt 源码文件保存编码不是 UTF-8。

解决：Java 编译加-encoding UTF-8；建库用CHARACTER SET utf8mb4；Qt Creator 里把文件编码统一设为 UTF-8（「编辑」→「Select Encoding」）。三处都对齐，乱码基本消失。

6. 进阶：把计费逻辑做成可验证的单元测试

跑通只是第一步，计费系统最怕的是「算错了还不知道」。我一般会给Core.java的计费方法补一组单元测试，用固定输入验证输出，这样改费率或改计费周期时能立刻发现回归。下面是一个用 JUnit 写的测试骨架，思路是把「用量 + 费率 + 时长」三要素固定住，断言金额。

import static org.junit.Assert.assertEquals; import org.junit.Test; public class CoreTest { // 验证：24 度、1 小时、费率 0.5 元/小时，应扣 0.5 元 @Test public void testChargeOneHour() { Core core = new Core(); double fee = core.calculate(24, 60, 0.5); // 温度, 分钟, 每小时费率 assertEquals(0.5, fee, 0.001); } // 验证：跨费率时段，半小时按半价 @Test public void testHalfHour() { Core core = new Core(); double fee = core.calculate(24, 30, 0.5); assertEquals(0.25, fee, 0.001); } }

calculate的签名要按你实际的Core.java调整，我这里用「温度、分钟、费率」三个参数示意。断言里的0.001是浮点误差容忍度，金额计算别用==直接比。测试跑起来后，每次动计费逻辑先跑一遍，比手动开两个客户端点半天靠谱得多。

除了单元测试，验证整条链路还有个笨办法但很有效：开一个房间，记下开始时间和初始余额，让它跑固定时长（比如 10 分钟），然后查consume_record表里的记录，手算一遍金额对不对。数据库里的记录是唯一的后悔药，界面显示可以骗人，落库的数字骗不了人。

费率配置建议从data.json里读，别硬编码在Core.java里。这样改价不用重新编译，运营调价时省事。data.json的结构可以设计成房间号到费率的映射，启动时由LocalData加载进内存，计费时直接查。

从那以后我每次碰计费类项目，都强制先写一组边界测试再动业务代码——跨零点、跨费率、并发扣费这三个场景各来一条，跑绿了才敢往下做。希望帮到你。

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