简介面向北邮软件工程相关课程设计压缩包内提供了一套完整的“空调”主题项目内含基于Qt的C桌面程序源码涵盖登录、主界面、多线程、房间管理等功能模块适合正在完成软件工程课设或初学Qt开发的同学参考。资源共113个文件其中16个cpp和13个h构成核心逻辑4个ui与2个qrc负责界面与资源编排另有65张jpg图片用于界面预览与文档说明3个docx为报告材料整体约2.68MB目录结构清晰便于快速定位代码。已有392人学习下载项目代码结构分明适合对照源码理解MVC分层与多线程服务器设计思路也可结合现有图片和文档快速搭建属于自己的课程设计。对于希望整体复现或二次开发空调管理系统的读者能省去大量从零搭建的时间。1. 高校宿舍空调软件工程项目到底在做什么先想清楚这不是“做个网页”一个宿舍空调管控项目最容易翻车的不是空调而是软件侧的表设计和定时任务。很多同学把这个题目理解成“给空调做个开关页面”结果设备接入、计费对账、断电重连三个环节全都塌了。这个软件工程项目的核心是把一台物理空调变成可以被多个角色宿管、学生、维修员安全、稳定、可审计地操作的业务对象它同时涉及硬件通信、服务端任务调度和财务级的数据准确性。适合谁做正在选软件工程课设方向的同学或者想独立完成一个从串口到 Web 全链路项目的开发者。读完之后你能拿到的是一套能跑通的最小系统方案以及那些文档里永远不会写的坑。2. 需求拆解与总体架构把宿舍空调项目切成设备、计费、Web 三个子系统2.1 从一张床位的空调谈起角色、场景与边界空调项目听起来小但一旦落到宿舍场景角色至少有三类学生要远程开关、定时、看账单宿管要批量控制、查看运行状态维修员要定位异常设备。每个角色对“空调”这个对象的操作权限完全不同。另一个被忽略的维度是“边界”宿舍空调是壁挂机没有网络模块你要在空调和系统之间补一层硬件网关网关负责红外或 RS485 通信。边界问题直接决定项目工作量。如果只做“模拟数据网页展示”那这个项目只是 CRUD 练习评不出来如果做真实红外控制需要硬件烧录和现场调试时间成本又不受控。我建议你走中间路线设备侧和服务器之间用 MQTT 协议网关层做成可替换的模拟器——本地开发时用脚本模拟空调上报答辩时再切换成真实网关。这样软件工程的核心流程需求、设计、编码、测试、部署都在又不必赌硬件不出问题。功能清单上至少要覆盖这四件事远程开关机与温度设定、定时任务按宿舍时段统一控温、计费按时长或电量、状态监控在线/离线/故障。再往上的“智能控温”“能耗预测”属于加分项不建议在一开始就引入因为它们会把需求边界撑大导致主流程做不完。软件工程课设的评分点从来不是功能多而是“你说要做的东西是否真正闭环”。2.2 总体架构与数据流控制指令怎么从浏览器走到压缩机我习惯把系统分为三层Web 应用层、消息接入层、设备网关层。Web 应用层负责展示和业务规则比如计费、权限、报表消息接入层用 MQTT Broker 承担设备连接和指令转发设备网关层是物理空调与网络的交界。第一次做这个项目的人最容易砍掉消息接入层直接让 Web 后端通过网络请求去调设备这在宿舍场景是走不通的空调在校园网内 IP 不固定而且 NAT 背后你根本找不到设备。正确路径是浏览器操作 → Web 后端写库 → 后端发布 MQTT 消息 → 网关订阅后转红外/485 → 空调执行 → 网关回报状态 → MQTT 回传 → 后端更新数据库。这里有两个关键设计第一控制指令必须异步化后端发布消息后不能立刻认为“操作成功”要等设备回报第二数据库里的状态不能作为实时状态只能作为“最近一次已知状态”。这两个设计决定了系统会不会出现“界面开了、空调没开”的经典事故。数据流设计的另一个重点是消息格式。我建议直接定义一个统一的 JSON 协议所有设备上报和控制指令都走同一个结构。比如{msgId:uuid,deviceId:ac_001,type:cmd/status,payload:{power:on,temp:26}}。msgId 是每次操作的唯一标识后面计费、幂等、日志全靠它。不要在项目里出现“A 类设备一套格式、B 类设备另一套格式”的分叉否则网关一多逻辑就霉化了。2.3 技术选型为什么用 MQTT 定时任务而不是直接用轮询每年都有人问为什么不做成 Web 后端轮询空调状态原因很简单宿舍场景下空调数量多、网关在线状态不稳定轮询要么频率低没实时性要么频率高把网关打爆。MQTT 是发布/订阅模式空调状态变化时主动上报服务器不用反复去问控制指令下行也是一次发布、多端订阅宿管批量控制就和单台控制走同一套逻辑。另一个好处是 MQTT 自带 QoS 分级和离线遗嘱Last Will设备掉线时 Broker 能替设备发出“离线”信号这正是下一章状态管理的地基。后端和 MQTT 的配合上我推荐 Java Spring Boot 加 Eclipse Paho 客户端理由不是它比 Node.js 更高级而是事务管理和定时任务生态更完整。计费、锁、对账都要依赖数据库事务这一块 Spring 的成熟度远高于自己拼 Promise。定时任务则用 XXL-Job 或 Spring 自带的Scheduled都行但要注意一句话定时任务只负责“触发”具体能不能执行要靠分布式锁防止多个实例重复跑。如果你们只有一个后端实例Scheduled够用如果上了集群就得加锁。MQTT Broker 的选择常见方案是 EMQX 或 Mosquitto。我用 EMQX 多一些因为它自带的 Dashboard 可以直接看设备连接数和消息流对排查问题很直观。版本号不用刻意追求新稳定版即可。数据库用 MySQL表结构见第 4 章。Redis 在这个项目里不是必需品只有做实时在线状态展示时才建议用 Redis 的 key 过期来做心跳判断。选型的关键不是“哪个最强”而是“哪个能支撑你把从控制到下线的链路讲清楚”。3. 核心实现从设备接入到远程开机的关键代码3.1 设备接入层用 MQTT 订阅空调上报的基础结构设备接入是整个系统第一个要落地的模块。你要让后端点开就能收到空调的上报最朴素的写法就是订阅一个主题。但主题命名必须提前设计我见过太多人写ac/status这种把所有设备混在一起的主题后面一上线就发现无法区分宿舍。推荐结构dorm/{dormId}/device/{deviceId}/report。主题本身带了隔离性网关侧只需要按规则发布服务端订阅时也能用通配符dorm//device//report接收所有设备上报互不干扰。下面是接入层的核心代码结构用 Spring Boot Eclipse Paho 实现。它做的事情是启动时连接 EMQX订阅所有宿舍的设备上报主题收到消息后反序列化成统一对象再分发给对应的处理器。Component public class MqttSubscriber { private static final String TOPIC_PATTERN dorm//device//report; private final MqttClient client; public MqttSubscriber(Value(${mqtt.broker}) String broker, Value(${mqtt.client-id}) String clientId) throws MqttException { this.client new MqttClient(broker, clientId, new MemoryPersistence()); } PostConstruct public void connect() { MqttConnectOptions options new MqttConnectOptions(); options.setCleanSession(false); options.setAutomaticReconnect(true); options.setConnectionTimeout(10); client.setCallback(new MqttCallback() { Override public void connectionLost(Throwable cause) { // 网络抖动时保持线程自动重连由 AutomaticReconnect 处理 } Override public void messageArrived(String topic, MqttMessage message) { String payload new String(message.getPayload(), StandardCharsets.UTF_8); DeviceReport report JSON.parseObject(payload, DeviceReport.class); handleReport(topic, report); } }); client.connect(options); client.subscribe(TOPIC_PATTERN, 1); // QoS 1至少一次 } }这段代码里两个参数值得说明setCleanSession(false)表示会话持久化Broker 会保存该客户端的订阅关系后端程序重启后不需要重新订阅如果设成 true会出现“服务挂了一下恢复之后收不到任何设备消息”的诡异情况排查半天发现是订阅丢了。client.subscribe(TOPIC_PATTERN, 1)中的 QoS 1 表示消息至少送达一次适合状态上报场景。设备主动上报本身允许重复因为服务端处理时要做幂等后面会讲。如果你用 QoS 0在校园网弱网环境下丢消息概率不小到时你会发现计费时长达标、设备状态却是旧的。3.2 控制指令下发带幂等处理的启停命令控制下行比上行更容易翻车因为你要面对“发成功了但设备没执行”“设备执行了但没回执”“回执丢了”三种情况。处理这三类问题统一答案是指令要带唯一 msgId服务端要保存指令状态同时要把“执行中”和“已完成”分清楚。在下发之前先查设备的在线状态但注意在线状态也是缓存的最终以网关回报为准。这里给出一段控制下发的示例包含幂等检查和数据库状态更新。这是整个系统里事务最密集的地方一定不要只发布 MQTT 而忘记落库。Service public class ControlService { Transactional public void sendCommand(String dormId, String deviceId, ControlCommand cmd) { // 1. 生成全局唯一的指令ID String msgId createMsgId(); // 2. 幂等键设备指令类型内容三分钟内相同指令不重复执行 String idempotentKey buildIdempotentKey(deviceId, cmd); if (commandRedis.has(idempotentKey)) { throw new DuplicateCommandException(指令重复请勿频繁操作); } // 3. 更新数据库中的待执行指令表 commandLogDao.insert(new CommandLog(msgId, deviceId, cmd.commandType(), PENDING)); // 4. 发布控制topic带上msgId MqttMessage message new MqttMessage(buildControlPayload(msgId, cmd).getBytes()); message.setQos(1); MqttTopic topic mqttClient.getTopic(dorm/ dormId /device/ deviceId /cmd); topic.publish(message); // 5. 写入幂等标记过期时间三分钟 commandRedis.set(idempotentKey, msgId, 180, TimeUnit.SECONDS); } Transactional public void onDeviceAck(String msgId, DeviceAck ack) { CommandLog log commandLogDao.findByMsgId(msgId); if (log null) { // 网关注销了一条我们从未发出的指令多为测试消息直接忽略 return; } // 只有状态为 PENDING 时更新避免覆盖 ACK/FAIL if (PENDING.equals(log.getState())) { commandLogDao.updateState(msgId, ack.success() ? SUCCESS : FAILED); } } }代码里有三个关键点。第一commandRedis.set(idempotentKey, msgId, 180, ...)这行不能省它解决“学生连续点了两次开机”这种高频问题没有幂等键网关就会收到两条一样的开机指令轻则空调重复执行重则有些空调会自己进入保护状态。第二onDeviceAck里只对PENDING更新状态这个判断是防止指令回执和定时重试之间互相覆盖。第三createMsgId()不要用数据库自增 ID而要使用 UUID 或雪花算法生成的全局 ID因为设备上报和指令下发两个线程都要依赖这个 ID 做关联自增 ID 在跨表跨模块时容易重复。如果你用的是真实红外网关要额外注意一条空调对红外指令的响应是几十毫秒级的但 MQTT 消息可能延迟几百毫秒。网关收到指令后如果立即回 ACK等于只告诉你“收到了”不代表空调执行了。这里我建议把 ACK 拆成两段先上报“指令已接收”再在 2 秒后补充上报“设备状态已变更”。服务端以后者为准更新数据库。这是很多项目里的隐性需求不做这层界面上的状态永远像是猜的。3.3 定时任务与电量采集计费数据的入口计费模块是让这个项目和“玩具”拉开距离的地方。常见的计费策略有两种按时长计费和按电量计费。宿舍空调一般没有独立电表按时长是最稳妥的起步方案如果网关支持读功率也可以用电量累计。这一节给出的定时任务是“每隔五分钟采集一次空调的工作时长增量”并把原始记录写入 time_usage 表。它不直接算账只负责采数。Component public class UsageCollector { Scheduled(cron 0 */5 * * * ?) // 每5分钟执行一次 public void collect() { ListDeviceSnapshot runningDevices snapshotService.listWithRunningState(); for (DeviceSnapshot device : runningDevices) { int seconds device.calcDeltaSecondsOfRunning(); if (seconds 0) { // 时间戳异常或设备刚启动跳过本次采集 continue; } TimeUsage usage new TimeUsage(); usage.setDeviceId(device.getDeviceId()); usage.setDormId(device.getDormId()); usage.setStartAt(device.getLastSnapshotTime()); usage.setEndAt(LocalDateTime.now()); usage.setDurationSeconds(seconds); usageDao.insert(usage); snapshotService.updateSnapshot(device.getDeviceId()); } } }这里必须避开一个大坑calcDeltaSecondsOfRunning不能用“本次采集时间减去上次采集时间”作为设备实际运行时长因为空调可能在这五分钟内开开关关好几次。正确的做法是依赖设备主动上报的状态变化时间上报。也就是说每次 MQTT 上报里要带上since字段表示这个状态从什么时间开始服务端用状态变更时间增量求和。只有在你没有状态变化事件的情况下才退而求其次用定时采样但这时候要接受误差。参数方面cron 0 */5 * * * ?我这里设置的是每五分钟一次不会有重复。如果你改成*/5那是每 5 秒一次相当于 5 秒里执行 60 次注意别把 cron 表达式里的 秒 和 分 搞混。采集频率太高没必要因为空调的运行状态变化都是分钟级别的太低又会导致计费误差大。五分钟是宿舍空调项目的合理值也是答辩时能讲清楚的依据。采集任务本身不参与计费计算计费在月结或每日结算时统一跑避免把两次计费叠加在一次采集任务的异常里。4. 数据库模型与接口约定让房间、计费和账单对得上4.1 六张核心表的结构说明打表设计是这类项目能跑多久的分水岭。空调项目至少需要这六张核心表宿舍表dorm、设备表device、用户与宿舍关系表user_dorm、指令日志表command_log、设备上报快照表device_snapshot、计费记录表billing_record。简单项目还可以加一张tariff表存计费单价但我更建议把单价做成一个系统配置项而非数据库表减少改动范围。下面把六张表的用途、关键字段和表间关系整理成一张说明表方便你在评审时对照着讲。这里不落具体建表 SQL因为字段需要跟你所选的技术栈对齐但表之间的关联逻辑是一致的。表名主要职责关键字段关联关系dorm宿舍基础信息id, dorm_name, building_name, max_devicesdevice.dorm_id 关联device空调设备本身id, dev_id, dorm_id, status, power_state, current_temp, firmware_version关联 dormuser_dorm绑定学生与宿舍id, user_id, dorm_id, role, is_active多对多关系解耦command_log下发指令留痕id, msg_id, device_id, cmd_type, cmd_content, state, create_time, ack_time控制链路核心device_snapshot定时采集快照id, device_id, snapshot_time, running_seconds, energy_kwh计费数据源billing_record计费/账单记录id, dorm_id, period, total_seconds, fee, status, paid_time汇总 device_snapshotcommand_log表是整个系统的“审计日志”出现任何争议比如学生说没开空调账单却有费用全靠它还原操作。它也是我唯一建议加索引的表字段msg_id必须建唯一索引否则第 3.2 节的按 msgId 查日志会退化成全表扫描。device_snapshot表会随时间膨胀建议定期按宿舍聚合后保留汇总数据详细信息留存时间可以短一些。这个细节能让你在评审时说出“我考虑了数据生命周期”是一个很实际的加分点。4.2 对账接口与账单生成为什么不能用数据库时间账单生成是最容易出“玄学”的模块。很多同学直接写当月账单 当月所有快照时长 × 单价然后用 MySQL 的NOW()取当前时间。这里有两个隐患第一定时任务是按自然月跑批的NOW()在跨月跑批时会污染上个月的数据第二如果网关延迟上报了上个月的快照且你又是直接用报时间而不是业务时间做过滤这张快照会被记到本月下个月初对账时怎么都对不上。我建议的接口约定是所有设备上报和快照记录除了存created_at数据库写入时间还要有一个biz_time业务发生时间由网关在上报时附带。所有计费聚合一律用biz_time过滤数据库时间只能作为兜底日志。这样做的好处是当网络抖动导致设备消息晚到 5 分钟时这 5 分钟还是算在它真实发生的时间段里账不会因为传输的快慢而漂移。账单生成落到代码上核心 SQL 是这段按宿舍和月份分组的聚合查询SELECT d.dorm_id, DATE_FORMAT(s.biz_time, %Y-%m) AS bill_month, SUM(s.running_seconds) AS total_seconds, ROUND(SUM(s.running_seconds) / 3600 * tc.price_per_hour, 2) AS fee FROM device_snapshot s JOIN device d ON s.device_id d.id JOIN tariff_config tc ON tc.is_active 1 WHERE s.biz_time 2025-06-01 00:00:00 AND s.biz_time 2025-07-01 00:00:00 GROUP BY d.dorm_id, bill_month;这条 SQL 里值得注意的不是分组本身而是过滤条件用了半开区间和而不是BETWEEN。BETWEEN是闭区间会把你下个月 0 点的数据也包含进来月底结算很容易差出刚好一个采样粒度的金额。另外tariff_config表用了一条is_active 1的标记来取当前生效的单价这样可以支持跨月调价而不用修改历史账单。如果你们没有调价场景也可以直接把这个单价常量写死在结算代码里减少一张表的维护。4.3 关键 SQL统计每个宿舍七天用电/用时的写法评审老师最常问的问题之一是“你怎么证明系统是准的”。所以你要拿得出一条能验证的数据路径。下面这条查询统计的是过去 7 天每个宿舍累计空调运行时长并且把离线时间比异常地标出来。它是你在答辩时说“数据已验证”的底气。SELECT d.dorm_id, d.dorm_name, ROUND(SUM(s.running_seconds) / 3600, 1) AS total_hours, COUNT(DISTINCT s.device_id) AS active_devices, ROUND(AVG(s.running_seconds), 0) AS avg_duration_per_record FROM device_snapshot s JOIN device d ON s.device_id d.id WHERE s.biz_time DATE_SUB(NOW(), INTERVAL 7 DAY) AND s.biz_time NOW() GROUP BY d.dorm_id, d.dorm_name ORDER BY total_hours DESC;这条 SQL 的过滤条件同样使用DATE_SUB(NOW(), INTERVAL 7 DAY)与 NOW()的半开区间为了避免在校验时把到“当前时刻”之后的数据算进去。GROUP BY后面跟着非聚合字段在 MySQL 默认ONLY_FULL_GROUP_BY关闭时可以执行但建议完整写出所有非聚合字段方便在答辩时说明你的 SQL 兼容性。索引建议建立在device_snapshot(biz_time, device_id)上否则数据量一旦到十万级这条查询就会慢到让现场演示卡住。5. 避坑与排查空调项目里最常见的 5 个翻车点5.1 现象控制界面显示开机空调却没反应这是项目演示时事故率最高的一幕。原因通常是三种设备离线但缓存状态没刷新指令发布到了主题但网关没订阅或者 QoS 0 发布时消息在弱网下丢了。排查路径要按先后走先看 EMQX Dashboard 里在线客户端有没有网关连接再查command_log里这条指令的发布状态是否PENDING最后用mosquitto_sub命令行工具订阅对应主题看消息是否真的从 Broker 转发出来了。解决的办法是三层兜底。第一下发前强制刷新设备在线状态不能只查数据库里的power_state要查last_heartbeat_time是否在 30 秒内。第二网关侧订阅时使用主题通配符并且定期重发PINGREQ保持连接避免假在线。第三所有控制指令 QoS 必须为 1下行消息不能省。原因很简单空调执行失败可以通过回执重试但消息在网络上丢了就没了。这里建议把所有控制动作的调用结果都做一次超时检查比如 10 秒内没有 ACK 就在管理端提示“设备可能未收到指令”不要让人去猜。配置网关时也常遇到一个问题宿舍里有两台空调共用一个网关时网关只上报了孤儿设备、另一台不响应。这往往是 RS485 总线的地址冲突不是软件问题。排查这类问题要看网关日志中收到的设备 ID 是否有规律地轮不到某台设备如果是就通过网关配置脚本刷新该设备的 485 从机地址。5.2 现象计费金额漂移账单比手动计算多几块钱计费漂移几乎都与业务时间和运行时长的计算方式有关。如果你的device_snapshot表没有biz_time字段就一定会出现跨月跨日漂移。另一个常见原因是状态变更上报的“状态持续时间”被重复累加空调在 10:00:00 开机10:05:00 上报一次10:05:30 又上报一次如果第二次上报还是把 10:00 到 10:05 的 300 秒算进去就重复计费了。解决方只有一条状态上报必须携带状态变更时间点state_changed_at服务端累加的是一个时间点到另一个时间点的差值而不是多次累加同一段区间。具体实现中state_changed_at应当由网关产生而不是服务端接收时间因为服务端接收时间会包含消息传输延迟弱网下延迟十几秒甚至更多金额就会漂移。我自己踩过一次这样的坑上报消息延迟三分钟五分钟采样任务把三分钟的“未运行时间”也算进去了排查了三个小时才找到是LocalDateTime.now()惹的祸。教训是所有的计费时间字段名里必须有biz_前缀时刻提醒自己是业务事件时间还是服务器接收时间。5.3 现象定时任务重复执行同一个宿舍被扣两次费定时任务重复执行的原因有两个一是用了Scheduled但部署了多个后端实例二是任务执行时间超过了触发间隔上一次还没跑完下一次又开始了。典型表现是凉棚火警式扣费一张宿舍的账单金额翻倍。解决办法围绕两个词幂等和分布锁。如果是单实例Scheduled默认不会并发执行同一个任务但它不防重启后补跑。更稳的做法是给计费任务加一个“任务批次号”每月跑批时第一件事就是查billing_record里有没有同月批次记录有就直接跳过。如果是多实例部署使用 Redis 分布式锁SET key value NX EX 60同一时刻只能有一个实例跑批。这里不需要引入复杂框架一条 Redis SETNX 就够了关键在于锁过期时间要大于任务最大耗时否则锁提前释放会再次放进来第二个实例。我一般会在跑批任务开头加一行日志输出实例 IP 和批次号方便事后核对是哪台机器执行的。出现重复跑批第一反应不是改业务逻辑而是先看日志里批次号有没有重复再决定改锁还是改幂等。5.4 现象断电重连后设备状态与服务端不一致宿舍空调突然断电网关可能连不上 MQTT服务端还停留在“在线”状态。等来电恢复后空调由于断电自启动恢复成了“关”但数据库里还是“开”或者相反空调是机械开关来电后自动开启数据库以为它关机。服务端拿到的第一次上报消息通常只是当前状态服务端直接用status字段更新把之前的计费区间闭合掉就会导致电费计算错误。解决策略是网关在上线时发送的第一条消息必须是type poweroff_recovery的特殊上报里面包含断电前记录的上次状态。服务端收到后不能直接覆盖当前状态而是要生成一条“状态变更事件”对比断电前的 running 区间先把旧区间闭合计费再为当前开机状态开启新区间。如果你不做这层那等到月底一算账所有断电宿舍的账单都偏高。设备侧如果无法区分断电恢复和普通上报可以在report_type字段加一个枚举normal和recovery。这算是我在这个项目里最依赖的一个小约定没有它半夜断电第二天全楼账单全都是乱的。5.5 现象并发下同一宿舍两条不同指令互相覆盖学生端和宿管端几乎同时下发“调温 26 度”和“温度 18 度”服务端如果按“最后接收的覆盖之前”来处理没问题但如果两个操作一个发了“开”一个发了“关”最后的状态取决于 MQTT 消息的到达顺序而且两个操作都在数据库里生成了PENDING指令可能造成设备刚执行“关”又立刻被另一条“开”覆盖。这个问题的本质是缺少“串行化”。我的做法在command_log表里对同一个device_id加一个串行锁同一设备同一时刻只允许一条PENDING指令进入。代码上发送新指令前要主动把同设备所有PENDING指令置为CANCELED并通知网关撤销排队中的指令。如果让两条指令并发执行那么控制结果对账单来说就是不可信的。值得再提一条血泪经验不要在设计并发控制时只盯着服务端网关侧如果透传队列等待第二条指令会压在第一条后面执行最终结果可能符合你的预期但时序上会多出几秒钟的“假状态”。所以接口层控制并发是一方面网关侧也尽量不引入本地队列直接实时下发。6. 验证与进阶如何证明这个项目真的“能跑”以及往哪里走验证一个空调软件工程项目不能只看页面能不能打开。我会分三层自测。第一层是设备链路模拟用一个命令行脚本模拟网关发送开机上报看服务端是否在 3 秒内更新状态。第二层是异常注入直接杀掉后端进程然后让设备上报恢复后检查计费任务是否会补跑是否会重复跑。第三层是对账验证手工记录一天内所有开关机动作月底和系统账单逐条比对。进阶方向上最值得做的是把“时长计费”升级为“功率估算计费”。如果你的网关支持读取当前功率可以在device_snapshot表增加power_watts字段能计算出每台设备当日总电量。这个功能对答辩的价值在于它打通了“硬件数据 → 软件模型 → 业务决策”的链路比单纯展示 CRUD 高一层但它对数据采集频率要求高需要把采样间隔缩短到 1 分钟以内且要注意空调待机功率为 0 时不计费。我做类似项目时最后总要保留一个“演示模式”的开关。它可以在没有真实网关时用本地文件模拟 MQTT 消息方便你在任何环境下随时跑起整个系统。这个习惯多次救急——现场设备连不上时用它完成评审判定流程总比整个项目当场翻车要好。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/19 9:20:47 · 阅读 1.2k 高校宿舍空调软件工程项目实战：从MQTT接入到计费闭环
简介面向北邮软件工程相关课程设计压缩包内提供了一套完整的“空调”主题项目内含基于Qt的C桌面程序源码涵盖登录、主界面、多线程、房间管理等功能模块适合正在完成软件工程课设或初学Qt开发的同学参考。资源共113个文件其中16个cpp和13个h构成核心逻辑4个ui与2个qrc负责界面与资源编排另有65张jpg图片用于界面预览与文档说明3个docx为报告材料整体约2.68MB目录结构清晰便于快速定位代码。已有392人学习下载项目代码结构分明适合对照源码理解MVC分层与多线程服务器设计思路也可结合现有图片和文档快速搭建属于自己的课程设计。对于希望整体复现或二次开发空调管理系统的读者能省去大量从零搭建的时间。1. 高校宿舍空调软件工程项目到底在做什么先想清楚这不是“做个网页”一个宿舍空调管控项目最容易翻车的不是空调而是软件侧的表设计和定时任务。很多同学把这个题目理解成“给空调做个开关页面”结果设备接入、计费对账、断电重连三个环节全都塌了。这个软件工程项目的核心是把一台物理空调变成可以被多个角色宿管、学生、维修员安全、稳定、可审计地操作的业务对象它同时涉及硬件通信、服务端任务调度和财务级的数据准确性。适合谁做正在选软件工程课设方向的同学或者想独立完成一个从串口到 Web 全链路项目的开发者。读完之后你能拿到的是一套能跑通的最小系统方案以及那些文档里永远不会写的坑。2. 需求拆解与总体架构把宿舍空调项目切成设备、计费、Web 三个子系统2.1 从一张床位的空调谈起角色、场景与边界空调项目听起来小但一旦落到宿舍场景角色至少有三类学生要远程开关、定时、看账单宿管要批量控制、查看运行状态维修员要定位异常设备。每个角色对“空调”这个对象的操作权限完全不同。另一个被忽略的维度是“边界”宿舍空调是壁挂机没有网络模块你要在空调和系统之间补一层硬件网关网关负责红外或 RS485 通信。边界问题直接决定项目工作量。如果只做“模拟数据网页展示”那这个项目只是 CRUD 练习评不出来如果做真实红外控制需要硬件烧录和现场调试时间成本又不受控。我建议你走中间路线设备侧和服务器之间用 MQTT 协议网关层做成可替换的模拟器——本地开发时用脚本模拟空调上报答辩时再切换成真实网关。这样软件工程的核心流程需求、设计、编码、测试、部署都在又不必赌硬件不出问题。功能清单上至少要覆盖这四件事远程开关机与温度设定、定时任务按宿舍时段统一控温、计费按时长或电量、状态监控在线/离线/故障。再往上的“智能控温”“能耗预测”属于加分项不建议在一开始就引入因为它们会把需求边界撑大导致主流程做不完。软件工程课设的评分点从来不是功能多而是“你说要做的东西是否真正闭环”。2.2 总体架构与数据流控制指令怎么从浏览器走到压缩机我习惯把系统分为三层Web 应用层、消息接入层、设备网关层。Web 应用层负责展示和业务规则比如计费、权限、报表消息接入层用 MQTT Broker 承担设备连接和指令转发设备网关层是物理空调与网络的交界。第一次做这个项目的人最容易砍掉消息接入层直接让 Web 后端通过网络请求去调设备这在宿舍场景是走不通的空调在校园网内 IP 不固定而且 NAT 背后你根本找不到设备。正确路径是浏览器操作 → Web 后端写库 → 后端发布 MQTT 消息 → 网关订阅后转红外/485 → 空调执行 → 网关回报状态 → MQTT 回传 → 后端更新数据库。这里有两个关键设计第一控制指令必须异步化后端发布消息后不能立刻认为“操作成功”要等设备回报第二数据库里的状态不能作为实时状态只能作为“最近一次已知状态”。这两个设计决定了系统会不会出现“界面开了、空调没开”的经典事故。数据流设计的另一个重点是消息格式。我建议直接定义一个统一的 JSON 协议所有设备上报和控制指令都走同一个结构。比如{msgId:uuid,deviceId:ac_001,type:cmd/status,payload:{power:on,temp:26}}。msgId 是每次操作的唯一标识后面计费、幂等、日志全靠它。不要在项目里出现“A 类设备一套格式、B 类设备另一套格式”的分叉否则网关一多逻辑就霉化了。2.3 技术选型为什么用 MQTT 定时任务而不是直接用轮询每年都有人问为什么不做成 Web 后端轮询空调状态原因很简单宿舍场景下空调数量多、网关在线状态不稳定轮询要么频率低没实时性要么频率高把网关打爆。MQTT 是发布/订阅模式空调状态变化时主动上报服务器不用反复去问控制指令下行也是一次发布、多端订阅宿管批量控制就和单台控制走同一套逻辑。另一个好处是 MQTT 自带 QoS 分级和离线遗嘱Last Will设备掉线时 Broker 能替设备发出“离线”信号这正是下一章状态管理的地基。后端和 MQTT 的配合上我推荐 Java Spring Boot 加 Eclipse Paho 客户端理由不是它比 Node.js 更高级而是事务管理和定时任务生态更完整。计费、锁、对账都要依赖数据库事务这一块 Spring 的成熟度远高于自己拼 Promise。定时任务则用 XXL-Job 或 Spring 自带的Scheduled都行但要注意一句话定时任务只负责“触发”具体能不能执行要靠分布式锁防止多个实例重复跑。如果你们只有一个后端实例Scheduled够用如果上了集群就得加锁。MQTT Broker 的选择常见方案是 EMQX 或 Mosquitto。我用 EMQX 多一些因为它自带的 Dashboard 可以直接看设备连接数和消息流对排查问题很直观。版本号不用刻意追求新稳定版即可。数据库用 MySQL表结构见第 4 章。Redis 在这个项目里不是必需品只有做实时在线状态展示时才建议用 Redis 的 key 过期来做心跳判断。选型的关键不是“哪个最强”而是“哪个能支撑你把从控制到下线的链路讲清楚”。3. 核心实现从设备接入到远程开机的关键代码3.1 设备接入层用 MQTT 订阅空调上报的基础结构设备接入是整个系统第一个要落地的模块。你要让后端点开就能收到空调的上报最朴素的写法就是订阅一个主题。但主题命名必须提前设计我见过太多人写ac/status这种把所有设备混在一起的主题后面一上线就发现无法区分宿舍。推荐结构dorm/{dormId}/device/{deviceId}/report。主题本身带了隔离性网关侧只需要按规则发布服务端订阅时也能用通配符dorm//device//report接收所有设备上报互不干扰。下面是接入层的核心代码结构用 Spring Boot Eclipse Paho 实现。它做的事情是启动时连接 EMQX订阅所有宿舍的设备上报主题收到消息后反序列化成统一对象再分发给对应的处理器。Component public class MqttSubscriber { private static final String TOPIC_PATTERN dorm//device//report; private final MqttClient client; public MqttSubscriber(Value(${mqtt.broker}) String broker, Value(${mqtt.client-id}) String clientId) throws MqttException { this.client new MqttClient(broker, clientId, new MemoryPersistence()); } PostConstruct public void connect() { MqttConnectOptions options new MqttConnectOptions(); options.setCleanSession(false); options.setAutomaticReconnect(true); options.setConnectionTimeout(10); client.setCallback(new MqttCallback() { Override public void connectionLost(Throwable cause) { // 网络抖动时保持线程自动重连由 AutomaticReconnect 处理 } Override public void messageArrived(String topic, MqttMessage message) { String payload new String(message.getPayload(), StandardCharsets.UTF_8); DeviceReport report JSON.parseObject(payload, DeviceReport.class); handleReport(topic, report); } }); client.connect(options); client.subscribe(TOPIC_PATTERN, 1); // QoS 1至少一次 } }这段代码里两个参数值得说明setCleanSession(false)表示会话持久化Broker 会保存该客户端的订阅关系后端程序重启后不需要重新订阅如果设成 true会出现“服务挂了一下恢复之后收不到任何设备消息”的诡异情况排查半天发现是订阅丢了。client.subscribe(TOPIC_PATTERN, 1)中的 QoS 1 表示消息至少送达一次适合状态上报场景。设备主动上报本身允许重复因为服务端处理时要做幂等后面会讲。如果你用 QoS 0在校园网弱网环境下丢消息概率不小到时你会发现计费时长达标、设备状态却是旧的。3.2 控制指令下发带幂等处理的启停命令控制下行比上行更容易翻车因为你要面对“发成功了但设备没执行”“设备执行了但没回执”“回执丢了”三种情况。处理这三类问题统一答案是指令要带唯一 msgId服务端要保存指令状态同时要把“执行中”和“已完成”分清楚。在下发之前先查设备的在线状态但注意在线状态也是缓存的最终以网关回报为准。这里给出一段控制下发的示例包含幂等检查和数据库状态更新。这是整个系统里事务最密集的地方一定不要只发布 MQTT 而忘记落库。Service public class ControlService { Transactional public void sendCommand(String dormId, String deviceId, ControlCommand cmd) { // 1. 生成全局唯一的指令ID String msgId createMsgId(); // 2. 幂等键设备指令类型内容三分钟内相同指令不重复执行 String idempotentKey buildIdempotentKey(deviceId, cmd); if (commandRedis.has(idempotentKey)) { throw new DuplicateCommandException(指令重复请勿频繁操作); } // 3. 更新数据库中的待执行指令表 commandLogDao.insert(new CommandLog(msgId, deviceId, cmd.commandType(), PENDING)); // 4. 发布控制topic带上msgId MqttMessage message new MqttMessage(buildControlPayload(msgId, cmd).getBytes()); message.setQos(1); MqttTopic topic mqttClient.getTopic(dorm/ dormId /device/ deviceId /cmd); topic.publish(message); // 5. 写入幂等标记过期时间三分钟 commandRedis.set(idempotentKey, msgId, 180, TimeUnit.SECONDS); } Transactional public void onDeviceAck(String msgId, DeviceAck ack) { CommandLog log commandLogDao.findByMsgId(msgId); if (log null) { // 网关注销了一条我们从未发出的指令多为测试消息直接忽略 return; } // 只有状态为 PENDING 时更新避免覆盖 ACK/FAIL if (PENDING.equals(log.getState())) { commandLogDao.updateState(msgId, ack.success() ? SUCCESS : FAILED); } } }代码里有三个关键点。第一commandRedis.set(idempotentKey, msgId, 180, ...)这行不能省它解决“学生连续点了两次开机”这种高频问题没有幂等键网关就会收到两条一样的开机指令轻则空调重复执行重则有些空调会自己进入保护状态。第二onDeviceAck里只对PENDING更新状态这个判断是防止指令回执和定时重试之间互相覆盖。第三createMsgId()不要用数据库自增 ID而要使用 UUID 或雪花算法生成的全局 ID因为设备上报和指令下发两个线程都要依赖这个 ID 做关联自增 ID 在跨表跨模块时容易重复。如果你用的是真实红外网关要额外注意一条空调对红外指令的响应是几十毫秒级的但 MQTT 消息可能延迟几百毫秒。网关收到指令后如果立即回 ACK等于只告诉你“收到了”不代表空调执行了。这里我建议把 ACK 拆成两段先上报“指令已接收”再在 2 秒后补充上报“设备状态已变更”。服务端以后者为准更新数据库。这是很多项目里的隐性需求不做这层界面上的状态永远像是猜的。3.3 定时任务与电量采集计费数据的入口计费模块是让这个项目和“玩具”拉开距离的地方。常见的计费策略有两种按时长计费和按电量计费。宿舍空调一般没有独立电表按时长是最稳妥的起步方案如果网关支持读功率也可以用电量累计。这一节给出的定时任务是“每隔五分钟采集一次空调的工作时长增量”并把原始记录写入 time_usage 表。它不直接算账只负责采数。Component public class UsageCollector { Scheduled(cron 0 */5 * * * ?) // 每5分钟执行一次 public void collect() { ListDeviceSnapshot runningDevices snapshotService.listWithRunningState(); for (DeviceSnapshot device : runningDevices) { int seconds device.calcDeltaSecondsOfRunning(); if (seconds 0) { // 时间戳异常或设备刚启动跳过本次采集 continue; } TimeUsage usage new TimeUsage(); usage.setDeviceId(device.getDeviceId()); usage.setDormId(device.getDormId()); usage.setStartAt(device.getLastSnapshotTime()); usage.setEndAt(LocalDateTime.now()); usage.setDurationSeconds(seconds); usageDao.insert(usage); snapshotService.updateSnapshot(device.getDeviceId()); } } }这里必须避开一个大坑calcDeltaSecondsOfRunning不能用“本次采集时间减去上次采集时间”作为设备实际运行时长因为空调可能在这五分钟内开开关关好几次。正确的做法是依赖设备主动上报的状态变化时间上报。也就是说每次 MQTT 上报里要带上since字段表示这个状态从什么时间开始服务端用状态变更时间增量求和。只有在你没有状态变化事件的情况下才退而求其次用定时采样但这时候要接受误差。参数方面cron 0 */5 * * * ?我这里设置的是每五分钟一次不会有重复。如果你改成*/5那是每 5 秒一次相当于 5 秒里执行 60 次注意别把 cron 表达式里的 秒 和 分 搞混。采集频率太高没必要因为空调的运行状态变化都是分钟级别的太低又会导致计费误差大。五分钟是宿舍空调项目的合理值也是答辩时能讲清楚的依据。采集任务本身不参与计费计算计费在月结或每日结算时统一跑避免把两次计费叠加在一次采集任务的异常里。4. 数据库模型与接口约定让房间、计费和账单对得上4.1 六张核心表的结构说明打表设计是这类项目能跑多久的分水岭。空调项目至少需要这六张核心表宿舍表dorm、设备表device、用户与宿舍关系表user_dorm、指令日志表command_log、设备上报快照表device_snapshot、计费记录表billing_record。简单项目还可以加一张tariff表存计费单价但我更建议把单价做成一个系统配置项而非数据库表减少改动范围。下面把六张表的用途、关键字段和表间关系整理成一张说明表方便你在评审时对照着讲。这里不落具体建表 SQL因为字段需要跟你所选的技术栈对齐但表之间的关联逻辑是一致的。表名主要职责关键字段关联关系dorm宿舍基础信息id, dorm_name, building_name, max_devicesdevice.dorm_id 关联device空调设备本身id, dev_id, dorm_id, status, power_state, current_temp, firmware_version关联 dormuser_dorm绑定学生与宿舍id, user_id, dorm_id, role, is_active多对多关系解耦command_log下发指令留痕id, msg_id, device_id, cmd_type, cmd_content, state, create_time, ack_time控制链路核心device_snapshot定时采集快照id, device_id, snapshot_time, running_seconds, energy_kwh计费数据源billing_record计费/账单记录id, dorm_id, period, total_seconds, fee, status, paid_time汇总 device_snapshotcommand_log表是整个系统的“审计日志”出现任何争议比如学生说没开空调账单却有费用全靠它还原操作。它也是我唯一建议加索引的表字段msg_id必须建唯一索引否则第 3.2 节的按 msgId 查日志会退化成全表扫描。device_snapshot表会随时间膨胀建议定期按宿舍聚合后保留汇总数据详细信息留存时间可以短一些。这个细节能让你在评审时说出“我考虑了数据生命周期”是一个很实际的加分点。4.2 对账接口与账单生成为什么不能用数据库时间账单生成是最容易出“玄学”的模块。很多同学直接写当月账单 当月所有快照时长 × 单价然后用 MySQL 的NOW()取当前时间。这里有两个隐患第一定时任务是按自然月跑批的NOW()在跨月跑批时会污染上个月的数据第二如果网关延迟上报了上个月的快照且你又是直接用报时间而不是业务时间做过滤这张快照会被记到本月下个月初对账时怎么都对不上。我建议的接口约定是所有设备上报和快照记录除了存created_at数据库写入时间还要有一个biz_time业务发生时间由网关在上报时附带。所有计费聚合一律用biz_time过滤数据库时间只能作为兜底日志。这样做的好处是当网络抖动导致设备消息晚到 5 分钟时这 5 分钟还是算在它真实发生的时间段里账不会因为传输的快慢而漂移。账单生成落到代码上核心 SQL 是这段按宿舍和月份分组的聚合查询SELECT d.dorm_id, DATE_FORMAT(s.biz_time, %Y-%m) AS bill_month, SUM(s.running_seconds) AS total_seconds, ROUND(SUM(s.running_seconds) / 3600 * tc.price_per_hour, 2) AS fee FROM device_snapshot s JOIN device d ON s.device_id d.id JOIN tariff_config tc ON tc.is_active 1 WHERE s.biz_time 2025-06-01 00:00:00 AND s.biz_time 2025-07-01 00:00:00 GROUP BY d.dorm_id, bill_month;这条 SQL 里值得注意的不是分组本身而是过滤条件用了半开区间和而不是BETWEEN。BETWEEN是闭区间会把你下个月 0 点的数据也包含进来月底结算很容易差出刚好一个采样粒度的金额。另外tariff_config表用了一条is_active 1的标记来取当前生效的单价这样可以支持跨月调价而不用修改历史账单。如果你们没有调价场景也可以直接把这个单价常量写死在结算代码里减少一张表的维护。4.3 关键 SQL统计每个宿舍七天用电/用时的写法评审老师最常问的问题之一是“你怎么证明系统是准的”。所以你要拿得出一条能验证的数据路径。下面这条查询统计的是过去 7 天每个宿舍累计空调运行时长并且把离线时间比异常地标出来。它是你在答辩时说“数据已验证”的底气。SELECT d.dorm_id, d.dorm_name, ROUND(SUM(s.running_seconds) / 3600, 1) AS total_hours, COUNT(DISTINCT s.device_id) AS active_devices, ROUND(AVG(s.running_seconds), 0) AS avg_duration_per_record FROM device_snapshot s JOIN device d ON s.device_id d.id WHERE s.biz_time DATE_SUB(NOW(), INTERVAL 7 DAY) AND s.biz_time NOW() GROUP BY d.dorm_id, d.dorm_name ORDER BY total_hours DESC;这条 SQL 的过滤条件同样使用DATE_SUB(NOW(), INTERVAL 7 DAY)与 NOW()的半开区间为了避免在校验时把到“当前时刻”之后的数据算进去。GROUP BY后面跟着非聚合字段在 MySQL 默认ONLY_FULL_GROUP_BY关闭时可以执行但建议完整写出所有非聚合字段方便在答辩时说明你的 SQL 兼容性。索引建议建立在device_snapshot(biz_time, device_id)上否则数据量一旦到十万级这条查询就会慢到让现场演示卡住。5. 避坑与排查空调项目里最常见的 5 个翻车点5.1 现象控制界面显示开机空调却没反应这是项目演示时事故率最高的一幕。原因通常是三种设备离线但缓存状态没刷新指令发布到了主题但网关没订阅或者 QoS 0 发布时消息在弱网下丢了。排查路径要按先后走先看 EMQX Dashboard 里在线客户端有没有网关连接再查command_log里这条指令的发布状态是否PENDING最后用mosquitto_sub命令行工具订阅对应主题看消息是否真的从 Broker 转发出来了。解决的办法是三层兜底。第一下发前强制刷新设备在线状态不能只查数据库里的power_state要查last_heartbeat_time是否在 30 秒内。第二网关侧订阅时使用主题通配符并且定期重发PINGREQ保持连接避免假在线。第三所有控制指令 QoS 必须为 1下行消息不能省。原因很简单空调执行失败可以通过回执重试但消息在网络上丢了就没了。这里建议把所有控制动作的调用结果都做一次超时检查比如 10 秒内没有 ACK 就在管理端提示“设备可能未收到指令”不要让人去猜。配置网关时也常遇到一个问题宿舍里有两台空调共用一个网关时网关只上报了孤儿设备、另一台不响应。这往往是 RS485 总线的地址冲突不是软件问题。排查这类问题要看网关日志中收到的设备 ID 是否有规律地轮不到某台设备如果是就通过网关配置脚本刷新该设备的 485 从机地址。5.2 现象计费金额漂移账单比手动计算多几块钱计费漂移几乎都与业务时间和运行时长的计算方式有关。如果你的device_snapshot表没有biz_time字段就一定会出现跨月跨日漂移。另一个常见原因是状态变更上报的“状态持续时间”被重复累加空调在 10:00:00 开机10:05:00 上报一次10:05:30 又上报一次如果第二次上报还是把 10:00 到 10:05 的 300 秒算进去就重复计费了。解决方只有一条状态上报必须携带状态变更时间点state_changed_at服务端累加的是一个时间点到另一个时间点的差值而不是多次累加同一段区间。具体实现中state_changed_at应当由网关产生而不是服务端接收时间因为服务端接收时间会包含消息传输延迟弱网下延迟十几秒甚至更多金额就会漂移。我自己踩过一次这样的坑上报消息延迟三分钟五分钟采样任务把三分钟的“未运行时间”也算进去了排查了三个小时才找到是LocalDateTime.now()惹的祸。教训是所有的计费时间字段名里必须有biz_前缀时刻提醒自己是业务事件时间还是服务器接收时间。5.3 现象定时任务重复执行同一个宿舍被扣两次费定时任务重复执行的原因有两个一是用了Scheduled但部署了多个后端实例二是任务执行时间超过了触发间隔上一次还没跑完下一次又开始了。典型表现是凉棚火警式扣费一张宿舍的账单金额翻倍。解决办法围绕两个词幂等和分布锁。如果是单实例Scheduled默认不会并发执行同一个任务但它不防重启后补跑。更稳的做法是给计费任务加一个“任务批次号”每月跑批时第一件事就是查billing_record里有没有同月批次记录有就直接跳过。如果是多实例部署使用 Redis 分布式锁SET key value NX EX 60同一时刻只能有一个实例跑批。这里不需要引入复杂框架一条 Redis SETNX 就够了关键在于锁过期时间要大于任务最大耗时否则锁提前释放会再次放进来第二个实例。我一般会在跑批任务开头加一行日志输出实例 IP 和批次号方便事后核对是哪台机器执行的。出现重复跑批第一反应不是改业务逻辑而是先看日志里批次号有没有重复再决定改锁还是改幂等。5.4 现象断电重连后设备状态与服务端不一致宿舍空调突然断电网关可能连不上 MQTT服务端还停留在“在线”状态。等来电恢复后空调由于断电自启动恢复成了“关”但数据库里还是“开”或者相反空调是机械开关来电后自动开启数据库以为它关机。服务端拿到的第一次上报消息通常只是当前状态服务端直接用status字段更新把之前的计费区间闭合掉就会导致电费计算错误。解决策略是网关在上线时发送的第一条消息必须是type poweroff_recovery的特殊上报里面包含断电前记录的上次状态。服务端收到后不能直接覆盖当前状态而是要生成一条“状态变更事件”对比断电前的 running 区间先把旧区间闭合计费再为当前开机状态开启新区间。如果你不做这层那等到月底一算账所有断电宿舍的账单都偏高。设备侧如果无法区分断电恢复和普通上报可以在report_type字段加一个枚举normal和recovery。这算是我在这个项目里最依赖的一个小约定没有它半夜断电第二天全楼账单全都是乱的。5.5 现象并发下同一宿舍两条不同指令互相覆盖学生端和宿管端几乎同时下发“调温 26 度”和“温度 18 度”服务端如果按“最后接收的覆盖之前”来处理没问题但如果两个操作一个发了“开”一个发了“关”最后的状态取决于 MQTT 消息的到达顺序而且两个操作都在数据库里生成了PENDING指令可能造成设备刚执行“关”又立刻被另一条“开”覆盖。这个问题的本质是缺少“串行化”。我的做法在command_log表里对同一个device_id加一个串行锁同一设备同一时刻只允许一条PENDING指令进入。代码上发送新指令前要主动把同设备所有PENDING指令置为CANCELED并通知网关撤销排队中的指令。如果让两条指令并发执行那么控制结果对账单来说就是不可信的。值得再提一条血泪经验不要在设计并发控制时只盯着服务端网关侧如果透传队列等待第二条指令会压在第一条后面执行最终结果可能符合你的预期但时序上会多出几秒钟的“假状态”。所以接口层控制并发是一方面网关侧也尽量不引入本地队列直接实时下发。6. 验证与进阶如何证明这个项目真的“能跑”以及往哪里走验证一个空调软件工程项目不能只看页面能不能打开。我会分三层自测。第一层是设备链路模拟用一个命令行脚本模拟网关发送开机上报看服务端是否在 3 秒内更新状态。第二层是异常注入直接杀掉后端进程然后让设备上报恢复后检查计费任务是否会补跑是否会重复跑。第三层是对账验证手工记录一天内所有开关机动作月底和系统账单逐条比对。进阶方向上最值得做的是把“时长计费”升级为“功率估算计费”。如果你的网关支持读取当前功率可以在device_snapshot表增加power_watts字段能计算出每台设备当日总电量。这个功能对答辩的价值在于它打通了“硬件数据 → 软件模型 → 业务决策”的链路比单纯展示 CRUD 高一层但它对数据采集频率要求高需要把采样间隔缩短到 1 分钟以内且要注意空调待机功率为 0 时不计费。我做类似项目时最后总要保留一个“演示模式”的开关。它可以在没有真实网关时用本地文件模拟 MQTT 消息方便你在任何环境下随时跑起整个系统。这个习惯多次救急——现场设备连不上时用它完成评审判定流程总比整个项目当场翻车要好。希望帮到你。本文还有配套的精品资源点击获取