简介北邮软件工程课程中的“空调”项目完整代码与配套文档包面向学习 C 与 Qt 桌面开发的学生、准备课程设计的本科生以及希望了解软硬件结合场景的开发者。项目围绕机房/办公室内空调环境监控这一场景实现登录验证、主控制窗口、多线程服务、房间管理等模块将温度控制、湿度调节、空气质量监测等需求落实为可操作的功能界面与后台逻辑也体现了软件工程从需求分析、架构设计到编码实现的完整流程。资源共 113 个文件压缩包约 2.68MB其中 16 个 C 源文件与 13 个头文件承载主要业务逻辑UI 文件设计人机交互界面pro/qrc 工程资源文件支持直接编译运行docx 文档为设计说明与使用指南jpg 图片多为界面截图与过程记录。已有 390 人关注学习适合对照源码进行功能扩展、界面重构或答辩讲解尤其对掌握 Qt 的信号槽机制、多线程通信、界面布局与软件分层设计有明确帮助。 提起“北邮软件工程”和“空调”这两个词很多人第一反应是八竿子打不着。直到我在软件工程课程设计里接到一道题——给学院实验室开发一套空调设备管理系统才意识到这类生活化的业务场景恰恰是练手软件工程全流程的最好载体。这个项目技术难度不算高但把需求分析、UML建模、数据库设计、前后端编码、测试部署完整跑一遍收获远大于堆新技术。如果你在做软件工程课程设计、毕业设计或者想找一个小而全的项目来理解软件工程到底在“工程”什么这篇可以给你一套能直接抄作业的参考。整个项目从接到题目到验收花了大概三周最后交付了一个可运行的管理平台设备台账、报修工单、能耗统计、权限管理都有还接了一路模拟温湿度传感器做环境监控。下面我把拆解思路、技术选型、核心表设计和代码实现都写出来踩过的坑也一并整理在最后。1. 项目全貌与需求拆解1.1 这个“空调”项目到底要解决什么问题北邮的机房、实验室和自习室加起来有几十间空调数量多、品牌杂、位置分散。以前靠人工巡检和纸质登记设备坏了什么时候报修、修了几次、换过什么配件全凭一张Excel和维修师傅的记忆。老师在课堂上反复强调软件工程不是“写个网站”而是“用一个系统性的方法解决真实业务问题”。所以这个题目的本质是如何用一套软件系统把分散的空调资产管起来把报修、维护、能耗这些流程线上化。我先花了两天做现场调研和实验室管理员、维修师傅分别聊过一轮发现真实痛点不是“开发一个好看的管理后台”而是三个字台账乱、响应慢、数据散。空调分布在哪些房间、什么时候买的、保修期到没到、上次保养是什么时候这些基础数据都没有统一记录报修靠电话和微信群工单状态不可追踪电费分摊靠估算缺乏按设备维度的能耗依据。1.2 核心需求与边界控制需求整理阶段我把功能分成了“必须有”“应该有”“可以有”三档。必须有的是设备管理、工单管理、用户登录和角色权限应该有的是能耗记录、温湿度监控、统计报表可以有的是短信通知、大屏可视化、移动端适配。这一步非常关键。课程设计最容易翻车的地方就是需求蔓延今天想加一个微信小程序明天想上人脸识别最后什么都做了一半。我的建议是只做MVP最小可行产品先把核心链路跑通再谈锦上添花。最终确定的功能清单是这样的设备管理空调信息的增删改查、按楼栋/房间/状态筛选、设备二维码标识工单管理报修创建、派单、处理、完成、评价的完整状态流转用户与权限管理员、维修人员、普通用户三类角色不同角色看到不同操作入口能耗与环境按小时记录空调温度和用电量提供简单统计图表系统基础登录认证、操作日志、数据导出非功能需求也不能忽视。并发量不需要太高校内系统同时在线几十人足够但数据准确性和操作可追溯性必须做好。我把“谁在什么时间改了哪条记录”作为硬性要求给核心表都加了审计字段。2. 技术选型与整体架构设计2.1 为什么选这组技术栈技术选型是软件工程里面很有争议的一环。我最终选择了后端Spring Boot MyBatis Plus MySQL前端Vue 3 Element Plus数据采集用MQTT模拟。理由不复杂北邮软件工程课程里Java生态是主线Spring Boot够成熟、资料多课程设计阶段没必要为了追新而选冷门框架。之前也犹豫过要不要用Python FastAPI毕竟现在Python在软件工程领域也很火写起来代码量更少。但考虑到团队里有人对Java更熟而且Spring Boot自带完整的依赖注入、事务管理和权限框架整套工程化体验更适合演示软件工程方法论。如果是个人项目用Python FastAPI确实能更快出成果但团队协作场景下Java的工程规范和生态稳定性更占优势。技术栈优点缺点适用场景Spring Boot MyBatis Plus工程规范清晰、事务/权限成熟、招聘市场需求大项目启动较重、代码量偏多课程设计、中小型管理系统FastAPI SQLAlchemy开发速度快、代码简洁、适合快速验证工程化组件相对少、团队认知差异大个人项目、数据接口服务Django DRF自带Admin后台、极速开发约定较重、定制灵活度略低原型验证、内部工具微服务、容器化这些概念在这个项目里属于过度设计。我见过有人用Docker Compose起了一堆服务结果部署环节直接在演示现场翻车。课程设计的评分重点是“流程完整、逻辑自洽、可运行”不是“用了多少中间件”。2.2 系统分层与模块划分系统采用经典的前后端分离结构后端按三层架构组织Controller层只做参数接收和结果封装Service层负责业务逻辑Mapper层通过MyBatis Plus操作数据库。前端按页面拆模块用Vue Router做路由守卫根据登录用户的角色动态生成菜单。实际的代码目录结构我按资源分包而不是按技术分层分包src/main/java/com/example/ac/ ├── common // 通用返回结果、异常处理、工具类 ├── config // 跨域配置、拦截器、MyBatis Plus配置 ├── controller // 设备、工单、用户、能耗、报表接口 ├── entity // 数据库实体类 ├── mapper // MyBatis Plus Mapper接口 ├── service // 业务逻辑层 └── vo // 前端交互的视图对象这种分包方式的优势是业务边界清楚。比如你接手这个项目想找工单相关的代码直接进controller、service、entity三个目录里的WorkOrder类就够了不需要在几十个技术包里翻来翻去。模块划分上设备、工单、用户权限、能耗采集、报表五个模块之间保持低耦合模块间只通过Service接口调用不直接访问对方的Mapper。3. 核心环节UML建模与数据库设计3.1 用UML把业务关系理清楚软件工程课程都会重点讲UML但很多人画图是画图、代码是代码两张皮。这次我刻意要求自己先画图再写代码让UML真正成为设计工具。用例图是最先画的核心角色有三类普通用户提交报修、查看自己名下设备的运行状态维修人员接单、填写维修结果、更新设备状态系统管理员维护设备台账、管理用户、查看统计报表。用例图画完功能边界基本就锁死了。类图我重点梳理了实体之间的关系。空调设备、用户、工单、维修记录、能耗记录这五个核心类关系其实不难理一个设备可以有多条工单一个工单对应一条维修记录一个设备每天产生多条能耗记录。关键是工单状态这个属性我单独做了一个枚举保证业务流转不会出现非法状态。时序图选了一个最有代表性的场景——报修工单完整流转。从用户提交报修请求开始到系统创建工单、通知维修人员、维修人员接单、填写处理结果、用户确认完成每一步都画在时序图上。画完这张图后面写代码几乎是在翻译不需要再纠结调用顺序。3.2 数据库表结构设计与字段取舍UML模型确定后数据库设计就很顺了。核心表一共五张外加一张用户角色中间表。我列出最关键的三张表结构供参考设备表字段名类型说明idbigint主键device_codevarchar(32)设备编号唯一room_namevarchar(64)所在房间brandvarchar(32)品牌model_namevarchar(64)型号install_datedate安装日期statustinyint运行状态0离线、1在线、2维修中energy_typevarchar(16)供电类型create_timedatetime创建时间工单表字段名类型说明idbigint主键order_novarchar(32)工单号如GD20250317001device_idbigint关联设备表reporter_idbigint报修人用户IDhandler_idbigint处理人用户IDstatustinyint状态1待派单、2处理中、3已完成、4已取消descriptionvarchar(500)故障描述handle_resultvarchar(500)处理结果handle_timedatetime完成时间能耗表字段名类型说明idbigint主键device_idbigint关联设备表temperaturedecimal(5,2)环境温度humiditydecimal(5,2)环境湿度powerdecimal(10,2)功率读数record_timedatetime采集时间有一个经验值得单独说不要在任何核心表里直接存用户姓名、设备品牌这种“冗余值”一律存ID然后关联查。一开始图省事在工单表里直接存了报修人姓名结果用户改名或者管理员要统计某个人的报修量时数据根本对不上。后来改成存user_id前端展示时再关联查。数据库设计宁可多写一条join也不要给后续埋坑。索引方面工单表的status和device_id要建联合索引因为查询场景基本是“某个设备的未完成工单”能耗表按device_id和record_time建联合索引否则按设备查一段时间内能耗会走全表扫描数据量一上来查询会明显变慢。4. 实操开发核心模块实现与细节4.1 设备台账与状态管理设备模块是基础中的基础实现起来不难但细节最多。实体类用MyBatis Plus的注解映射核心代码大概是这样的Data TableName(device) public class Device { TableId(type IdType.ASSIGN_ID) private Long id; private String deviceCode; private String roomName; private String brand; private String modelName; private LocalDate installDate; private Integer status; private String energyType; private LocalDateTime createTime; }分页查询接口建议统一封装返回结果我写了一个R类所有Controller都返回R.ok(data)或者R.error(msg)前端拿到统一结构异常处理会轻松很多。设备列表的筛选条件是楼栋、状态、关键词搜索用MyBatis Plus的LambdaQueryWrapper就能搞定不需要手写XML。这个模块最容易踩的坑是状态枚举。设备状态在数据库里是tinyint如果直接在代码里写魔法数字后期维护一定是灾难。我新建了一个DeviceStatusEnum并且在前端也用常量对应保证前后端对同一状态的理解完全一致。4.2 报修工单状态机与控制逻辑工单模块是整个项目里业务逻辑最重的部分。状态流转用状态机思想待派单、处理中、已完成、已取消四种状态每种状态定义了允许的转移路径。比如已取消只能从待派单转移处理中的工单不能直接删除。我单独写了一个WorkOrderStateTransition类用Map维护合法状态变更private static final MapInteger, ListInteger TRANSITIONS new HashMap(); static { TRANSITIONS.put(1, Arrays.asList(2, 4)); // 待派单 - 处理中 / 已取消 TRANSITIONS.put(2, Arrays.asList(3)); // 处理中 - 已完成 } public static boolean canTransition(int from, int to) { return TRANSITIONS.getOrDefault(from, Collections.emptyList()).contains(to); }工单创建时设备状态要同步变为“维修中”工单完成后再恢复为“在线”。这两个操作必须放在同一个事务里否则会出现工单已完成但设备状态卡在维修中的脏数据。我用Transactional注解包住了整个changeStatus方法实测下来事务控制是这类系统最容易被忽视的环节。4.3 前端联调与权限控制要点前端部分我用Vue 3 Element Plus组件化拆成设备管理、工单管理、能耗图表、用户管理四个主页面。与后端联调时踩得最多的坑是跨域和接口鉴权。跨域问题在后端加一个配置类解决Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowCredentials(true); } }权限控制用拦截器实现。登录成功后在Session里存入用户角色拦截器里校验请求路径的权限标识。前端通过Vue Router的beforeEach守卫判断是否登录、是否拥有指定角色没权限直接跳转到403页面。这样前后端双重校验基本能挡住越权操作。实际联调时前端自己直连数据库这种操作千万不要做前后端联调是为了验证接口协议是否一致不是绕过后端。接口统一以/api前缀开头返回结构统一为code、message、data三件套联调效率会高很多。5. 项目验收中的常见问题与排查技巧5.1 我在实训中踩过的5个坑时间戳问题。实体类用了LocalDateTime但前端传过来的是字符串导致时间比较和排序全乱了。后来统一在应用层做格式转换接口入参使用DateTimeFormat出参用JsonFormat。N1查询问题。设备列表页需要展示每台设备的最后一条维修记录一开始直接在循环里查数据库20台设备页面向后端发了21条SQL。后来改成一次性查出所有设备的维修记录在内存里按设备ID分组性能提升非常明显。重复提交问题。用户双击“提交工单”按钮会创建两条一模一样的工单。解决方案是前端按钮加loading状态后端在创建接口里用工单号唯一索引兜底双保险。跨域配置冲突问题。网关层配置了跨域后端又配了一次结果请求头出现重复的Allow-Origin浏览器直接拦截。排查了好一会儿才发现是配置叠加导致最终统一到后端配置。MyBatis Plus逻辑删除问题。默认的逻辑删除是在SQL上自动追加deleted0条件但如果实体类里没有对应字段写入时不会自动赋值导致旧数据查不出、新数据带null值。定义逻辑删除字段时一定要在实体类里同时声明并配置默认值。5.2 课程设计最容易丢分的地方根据我自己的体会评分老师最在意的是代码和文档的一致性。很多同学的UML图是最后补画的画出来的模型和代码对不上这种一眼就能看出来。我的习惯是一边写代码一边更新设计文档哪怕小到一个枚举的取值范围变化也要同步修改类图。单元测试是另一个容易被忽略的得分点。给Service层写几个核心方法的单元测试不需要覆盖全部代码但至少要覆盖工单状态流转的合法和非法分支。我用JUnit写了一个关于状态机方法的参数化测试大概四十行代码演示效果很好也让代码质量有了基本保障。Git提交规范也值得提一下。整个项目我按功能分支开发每个commit写清楚改动点绝不出现“update”“fix”这种没信息量的提交信息。验收现场直接打开Git历史一条清晰的项目演进线比什么都加分。6. 实训后的几点真实体会这个项目做完我个人最大的感触是软件工程课程设计和真实项目之间最大的差距卡在工程习惯而不是技术难度。空调管理系统本身并不复杂但把需求调研、UML建模、接口设计、数据库设计、代码实现、测试部署这条链路完整走一遍再做任何项目心里都有底。项目的扩展方向其实很明确。如果想把这个课题做得更有含金量可以接入真实的温湿度传感器和用电采集设备把MQTT模拟数据换成真实上报也可以对接企业微信通知让维修人员不用登陆系统就能收到派单提醒报表模块可以用ECharts做一个能耗趋势大屏放到实验室门口的屏幕上实时滚动。无论往哪个方向扩展骨架都已经打好了。如果你也要做类似的课程设计或毕业设计我的建议是先把“业务关系”画明白再动手写代码。图画得越清晰后面写代码就越像翻译。最后再分享一个实用技巧任何涉及状态变更的操作都先列一个状态转移矩阵再写逻辑这是避免逻辑漏洞最有效的方法。本文还有配套的精品资源点击获取 软件工程课程设计实战：空调设备管理系统开发与设计全解析
简介北邮软件工程课程中的“空调”项目完整代码与配套文档包面向学习 C 与 Qt 桌面开发的学生、准备课程设计的本科生以及希望了解软硬件结合场景的开发者。项目围绕机房/办公室内空调环境监控这一场景实现登录验证、主控制窗口、多线程服务、房间管理等模块将温度控制、湿度调节、空气质量监测等需求落实为可操作的功能界面与后台逻辑也体现了软件工程从需求分析、架构设计到编码实现的完整流程。资源共 113 个文件压缩包约 2.68MB其中 16 个 C 源文件与 13 个头文件承载主要业务逻辑UI 文件设计人机交互界面pro/qrc 工程资源文件支持直接编译运行docx 文档为设计说明与使用指南jpg 图片多为界面截图与过程记录。已有 390 人关注学习适合对照源码进行功能扩展、界面重构或答辩讲解尤其对掌握 Qt 的信号槽机制、多线程通信、界面布局与软件分层设计有明确帮助。 提起“北邮软件工程”和“空调”这两个词很多人第一反应是八竿子打不着。直到我在软件工程课程设计里接到一道题——给学院实验室开发一套空调设备管理系统才意识到这类生活化的业务场景恰恰是练手软件工程全流程的最好载体。这个项目技术难度不算高但把需求分析、UML建模、数据库设计、前后端编码、测试部署完整跑一遍收获远大于堆新技术。如果你在做软件工程课程设计、毕业设计或者想找一个小而全的项目来理解软件工程到底在“工程”什么这篇可以给你一套能直接抄作业的参考。整个项目从接到题目到验收花了大概三周最后交付了一个可运行的管理平台设备台账、报修工单、能耗统计、权限管理都有还接了一路模拟温湿度传感器做环境监控。下面我把拆解思路、技术选型、核心表设计和代码实现都写出来踩过的坑也一并整理在最后。1. 项目全貌与需求拆解1.1 这个“空调”项目到底要解决什么问题北邮的机房、实验室和自习室加起来有几十间空调数量多、品牌杂、位置分散。以前靠人工巡检和纸质登记设备坏了什么时候报修、修了几次、换过什么配件全凭一张Excel和维修师傅的记忆。老师在课堂上反复强调软件工程不是“写个网站”而是“用一个系统性的方法解决真实业务问题”。所以这个题目的本质是如何用一套软件系统把分散的空调资产管起来把报修、维护、能耗这些流程线上化。我先花了两天做现场调研和实验室管理员、维修师傅分别聊过一轮发现真实痛点不是“开发一个好看的管理后台”而是三个字台账乱、响应慢、数据散。空调分布在哪些房间、什么时候买的、保修期到没到、上次保养是什么时候这些基础数据都没有统一记录报修靠电话和微信群工单状态不可追踪电费分摊靠估算缺乏按设备维度的能耗依据。1.2 核心需求与边界控制需求整理阶段我把功能分成了“必须有”“应该有”“可以有”三档。必须有的是设备管理、工单管理、用户登录和角色权限应该有的是能耗记录、温湿度监控、统计报表可以有的是短信通知、大屏可视化、移动端适配。这一步非常关键。课程设计最容易翻车的地方就是需求蔓延今天想加一个微信小程序明天想上人脸识别最后什么都做了一半。我的建议是只做MVP最小可行产品先把核心链路跑通再谈锦上添花。最终确定的功能清单是这样的设备管理空调信息的增删改查、按楼栋/房间/状态筛选、设备二维码标识工单管理报修创建、派单、处理、完成、评价的完整状态流转用户与权限管理员、维修人员、普通用户三类角色不同角色看到不同操作入口能耗与环境按小时记录空调温度和用电量提供简单统计图表系统基础登录认证、操作日志、数据导出非功能需求也不能忽视。并发量不需要太高校内系统同时在线几十人足够但数据准确性和操作可追溯性必须做好。我把“谁在什么时间改了哪条记录”作为硬性要求给核心表都加了审计字段。2. 技术选型与整体架构设计2.1 为什么选这组技术栈技术选型是软件工程里面很有争议的一环。我最终选择了后端Spring Boot MyBatis Plus MySQL前端Vue 3 Element Plus数据采集用MQTT模拟。理由不复杂北邮软件工程课程里Java生态是主线Spring Boot够成熟、资料多课程设计阶段没必要为了追新而选冷门框架。之前也犹豫过要不要用Python FastAPI毕竟现在Python在软件工程领域也很火写起来代码量更少。但考虑到团队里有人对Java更熟而且Spring Boot自带完整的依赖注入、事务管理和权限框架整套工程化体验更适合演示软件工程方法论。如果是个人项目用Python FastAPI确实能更快出成果但团队协作场景下Java的工程规范和生态稳定性更占优势。技术栈优点缺点适用场景Spring Boot MyBatis Plus工程规范清晰、事务/权限成熟、招聘市场需求大项目启动较重、代码量偏多课程设计、中小型管理系统FastAPI SQLAlchemy开发速度快、代码简洁、适合快速验证工程化组件相对少、团队认知差异大个人项目、数据接口服务Django DRF自带Admin后台、极速开发约定较重、定制灵活度略低原型验证、内部工具微服务、容器化这些概念在这个项目里属于过度设计。我见过有人用Docker Compose起了一堆服务结果部署环节直接在演示现场翻车。课程设计的评分重点是“流程完整、逻辑自洽、可运行”不是“用了多少中间件”。2.2 系统分层与模块划分系统采用经典的前后端分离结构后端按三层架构组织Controller层只做参数接收和结果封装Service层负责业务逻辑Mapper层通过MyBatis Plus操作数据库。前端按页面拆模块用Vue Router做路由守卫根据登录用户的角色动态生成菜单。实际的代码目录结构我按资源分包而不是按技术分层分包src/main/java/com/example/ac/ ├── common // 通用返回结果、异常处理、工具类 ├── config // 跨域配置、拦截器、MyBatis Plus配置 ├── controller // 设备、工单、用户、能耗、报表接口 ├── entity // 数据库实体类 ├── mapper // MyBatis Plus Mapper接口 ├── service // 业务逻辑层 └── vo // 前端交互的视图对象这种分包方式的优势是业务边界清楚。比如你接手这个项目想找工单相关的代码直接进controller、service、entity三个目录里的WorkOrder类就够了不需要在几十个技术包里翻来翻去。模块划分上设备、工单、用户权限、能耗采集、报表五个模块之间保持低耦合模块间只通过Service接口调用不直接访问对方的Mapper。3. 核心环节UML建模与数据库设计3.1 用UML把业务关系理清楚软件工程课程都会重点讲UML但很多人画图是画图、代码是代码两张皮。这次我刻意要求自己先画图再写代码让UML真正成为设计工具。用例图是最先画的核心角色有三类普通用户提交报修、查看自己名下设备的运行状态维修人员接单、填写维修结果、更新设备状态系统管理员维护设备台账、管理用户、查看统计报表。用例图画完功能边界基本就锁死了。类图我重点梳理了实体之间的关系。空调设备、用户、工单、维修记录、能耗记录这五个核心类关系其实不难理一个设备可以有多条工单一个工单对应一条维修记录一个设备每天产生多条能耗记录。关键是工单状态这个属性我单独做了一个枚举保证业务流转不会出现非法状态。时序图选了一个最有代表性的场景——报修工单完整流转。从用户提交报修请求开始到系统创建工单、通知维修人员、维修人员接单、填写处理结果、用户确认完成每一步都画在时序图上。画完这张图后面写代码几乎是在翻译不需要再纠结调用顺序。3.2 数据库表结构设计与字段取舍UML模型确定后数据库设计就很顺了。核心表一共五张外加一张用户角色中间表。我列出最关键的三张表结构供参考设备表字段名类型说明idbigint主键device_codevarchar(32)设备编号唯一room_namevarchar(64)所在房间brandvarchar(32)品牌model_namevarchar(64)型号install_datedate安装日期statustinyint运行状态0离线、1在线、2维修中energy_typevarchar(16)供电类型create_timedatetime创建时间工单表字段名类型说明idbigint主键order_novarchar(32)工单号如GD20250317001device_idbigint关联设备表reporter_idbigint报修人用户IDhandler_idbigint处理人用户IDstatustinyint状态1待派单、2处理中、3已完成、4已取消descriptionvarchar(500)故障描述handle_resultvarchar(500)处理结果handle_timedatetime完成时间能耗表字段名类型说明idbigint主键device_idbigint关联设备表temperaturedecimal(5,2)环境温度humiditydecimal(5,2)环境湿度powerdecimal(10,2)功率读数record_timedatetime采集时间有一个经验值得单独说不要在任何核心表里直接存用户姓名、设备品牌这种“冗余值”一律存ID然后关联查。一开始图省事在工单表里直接存了报修人姓名结果用户改名或者管理员要统计某个人的报修量时数据根本对不上。后来改成存user_id前端展示时再关联查。数据库设计宁可多写一条join也不要给后续埋坑。索引方面工单表的status和device_id要建联合索引因为查询场景基本是“某个设备的未完成工单”能耗表按device_id和record_time建联合索引否则按设备查一段时间内能耗会走全表扫描数据量一上来查询会明显变慢。4. 实操开发核心模块实现与细节4.1 设备台账与状态管理设备模块是基础中的基础实现起来不难但细节最多。实体类用MyBatis Plus的注解映射核心代码大概是这样的Data TableName(device) public class Device { TableId(type IdType.ASSIGN_ID) private Long id; private String deviceCode; private String roomName; private String brand; private String modelName; private LocalDate installDate; private Integer status; private String energyType; private LocalDateTime createTime; }分页查询接口建议统一封装返回结果我写了一个R类所有Controller都返回R.ok(data)或者R.error(msg)前端拿到统一结构异常处理会轻松很多。设备列表的筛选条件是楼栋、状态、关键词搜索用MyBatis Plus的LambdaQueryWrapper就能搞定不需要手写XML。这个模块最容易踩的坑是状态枚举。设备状态在数据库里是tinyint如果直接在代码里写魔法数字后期维护一定是灾难。我新建了一个DeviceStatusEnum并且在前端也用常量对应保证前后端对同一状态的理解完全一致。4.2 报修工单状态机与控制逻辑工单模块是整个项目里业务逻辑最重的部分。状态流转用状态机思想待派单、处理中、已完成、已取消四种状态每种状态定义了允许的转移路径。比如已取消只能从待派单转移处理中的工单不能直接删除。我单独写了一个WorkOrderStateTransition类用Map维护合法状态变更private static final MapInteger, ListInteger TRANSITIONS new HashMap(); static { TRANSITIONS.put(1, Arrays.asList(2, 4)); // 待派单 - 处理中 / 已取消 TRANSITIONS.put(2, Arrays.asList(3)); // 处理中 - 已完成 } public static boolean canTransition(int from, int to) { return TRANSITIONS.getOrDefault(from, Collections.emptyList()).contains(to); }工单创建时设备状态要同步变为“维修中”工单完成后再恢复为“在线”。这两个操作必须放在同一个事务里否则会出现工单已完成但设备状态卡在维修中的脏数据。我用Transactional注解包住了整个changeStatus方法实测下来事务控制是这类系统最容易被忽视的环节。4.3 前端联调与权限控制要点前端部分我用Vue 3 Element Plus组件化拆成设备管理、工单管理、能耗图表、用户管理四个主页面。与后端联调时踩得最多的坑是跨域和接口鉴权。跨域问题在后端加一个配置类解决Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowCredentials(true); } }权限控制用拦截器实现。登录成功后在Session里存入用户角色拦截器里校验请求路径的权限标识。前端通过Vue Router的beforeEach守卫判断是否登录、是否拥有指定角色没权限直接跳转到403页面。这样前后端双重校验基本能挡住越权操作。实际联调时前端自己直连数据库这种操作千万不要做前后端联调是为了验证接口协议是否一致不是绕过后端。接口统一以/api前缀开头返回结构统一为code、message、data三件套联调效率会高很多。5. 项目验收中的常见问题与排查技巧5.1 我在实训中踩过的5个坑时间戳问题。实体类用了LocalDateTime但前端传过来的是字符串导致时间比较和排序全乱了。后来统一在应用层做格式转换接口入参使用DateTimeFormat出参用JsonFormat。N1查询问题。设备列表页需要展示每台设备的最后一条维修记录一开始直接在循环里查数据库20台设备页面向后端发了21条SQL。后来改成一次性查出所有设备的维修记录在内存里按设备ID分组性能提升非常明显。重复提交问题。用户双击“提交工单”按钮会创建两条一模一样的工单。解决方案是前端按钮加loading状态后端在创建接口里用工单号唯一索引兜底双保险。跨域配置冲突问题。网关层配置了跨域后端又配了一次结果请求头出现重复的Allow-Origin浏览器直接拦截。排查了好一会儿才发现是配置叠加导致最终统一到后端配置。MyBatis Plus逻辑删除问题。默认的逻辑删除是在SQL上自动追加deleted0条件但如果实体类里没有对应字段写入时不会自动赋值导致旧数据查不出、新数据带null值。定义逻辑删除字段时一定要在实体类里同时声明并配置默认值。5.2 课程设计最容易丢分的地方根据我自己的体会评分老师最在意的是代码和文档的一致性。很多同学的UML图是最后补画的画出来的模型和代码对不上这种一眼就能看出来。我的习惯是一边写代码一边更新设计文档哪怕小到一个枚举的取值范围变化也要同步修改类图。单元测试是另一个容易被忽略的得分点。给Service层写几个核心方法的单元测试不需要覆盖全部代码但至少要覆盖工单状态流转的合法和非法分支。我用JUnit写了一个关于状态机方法的参数化测试大概四十行代码演示效果很好也让代码质量有了基本保障。Git提交规范也值得提一下。整个项目我按功能分支开发每个commit写清楚改动点绝不出现“update”“fix”这种没信息量的提交信息。验收现场直接打开Git历史一条清晰的项目演进线比什么都加分。6. 实训后的几点真实体会这个项目做完我个人最大的感触是软件工程课程设计和真实项目之间最大的差距卡在工程习惯而不是技术难度。空调管理系统本身并不复杂但把需求调研、UML建模、接口设计、数据库设计、代码实现、测试部署这条链路完整走一遍再做任何项目心里都有底。项目的扩展方向其实很明确。如果想把这个课题做得更有含金量可以接入真实的温湿度传感器和用电采集设备把MQTT模拟数据换成真实上报也可以对接企业微信通知让维修人员不用登陆系统就能收到派单提醒报表模块可以用ECharts做一个能耗趋势大屏放到实验室门口的屏幕上实时滚动。无论往哪个方向扩展骨架都已经打好了。如果你也要做类似的课程设计或毕业设计我的建议是先把“业务关系”画明白再动手写代码。图画得越清晰后面写代码就越像翻译。最后再分享一个实用技巧任何涉及状态变更的操作都先列一个状态转移矩阵再写逻辑这是避免逻辑漏洞最有效的方法。本文还有配套的精品资源点击获取