Spring Boot智慧工地监控管理平台：从物联网到数据可视化全解析

每个做计算机毕业设计的人，尤其是选了Spring Boot这个技术栈的，基本都会面对同一个尴尬：题目看着挺熟，真下手做了才发现里面坑多得能把自己埋了。今天想跟你聊的这套“基于Spring Boot的云数据智慧工地监控管理软件”，就是这类题目里很典型的一个。它挂着“物联网”“云监控”“智慧工地”这些当下正热的关键词，看起来像是几个热点拼在一起，但真要动起手来，你会发现这其实是一个很完整的业务系统，从前端展示、后端服务、设备接入到数据存储，一环扣一环，任何一个地方卡住，整个项目都转不起来。

我先说结论：这个题目选得不算难，但绝对不简单。它适合有一定Java基础、想拿个像样的项目来展示自己能力的本科生，也适合那些想快速把Spring Boot、物联网、数据可视化这些东西串起来练手的同学。做完了，你手里握着的不仅是一份毕业设计，更是一套可以和“智慧城市”“工业互联网”这些大方向挂钩的工程化技能包。

整个系统解决的核心问题其实也很清楚：让工地管理者不在现场，也能实时看到现场发生了什么、设备运行是否正常、人员和车辆是否按规定作业。它不是一个简单的“视频监控”，而是把视频、传感设备、人员定位、环境检测这些信源汇到一套软件里，用云端的逻辑去判断、告警、调度。简单来说，就是把过去靠人盯的传统工地，变成数据驱动的数字化现场。

下面，我就从题目拆解到落地实现，把它完整地掰开揉碎讲给你。

1. 项目整体设计与思路拆解

1.1 需求决定架构：先搞清楚这个系统到底要管什么

很多人一拿到这个题目就直接开写代码，结果做着做着发现需求越铺越大，数据库表建了几十张，前后端接口对不上，最后草草收场。我更建议你先用半天时间，把需求理成一条清晰的线。

智慧工地说到底就干三件事：看得到、管得住、调得动。“看得到”指的是施工现场的实时画面、环境数据和设备状态要能传到云端；“管得住”要求系统有人员管理、考勤统计、安全告警这些控制能力；“调得动”则是在发现异常时，能够快速通知相关人员、派发任务，甚至联动闸机、喷淋、升降机这些现场设备。

基于这个逻辑，系统的功能模块至少应该包括：

• 数据采集层：门禁闸机、扬尘监测仪、塔吊传感器、视频摄像头等设备的数据接入
• 传输层：通过MQTT或HTTP把设备数据上报到云端服务
• 服务层：Spring Boot提供REST API，处理业务逻辑、规则引擎和权限控制
• 展示层：PC端管理后台 + 数据可视化大屏，供管理人员使用

如果是在毕业设计的场景下，不太可能真的把所有硬件都买到手，这就需要在软件层面把设备模拟器做好。把模拟器当作真实设备来设计，接口留好，之后接入真实硬件时直接替换数据来源就行。

1.2 技术选型：为什么是Spring Boot而不是别家

毕设题目标了Spring Boot，这个选择确实合理。它是现在Java后端开发事实上的标准，生态完善、社区活跃、文档多，真遇到问题一搜一大把解决方案。用它可以快速把Web服务搭起来，跟前端联调也方便。

但我觉得比框架本身更重要的，是能不能把Spring Boot里的几个核心机制讲清楚。毕设答辩时老师大概率会问：“为什么用Spring Boot？”你得能答出来——Spring Boot是用来简化Spring开发的框架，通过自动配置和starter依赖，省略了大量XML配置，内置Tomcat等Web容器，让应用可以直接跑起来。

在此基础上，整个系统会用到这样一组配套组件：

这套组合属于“最稳妥的毕业设计全家桶”。每个技术都有大量学习资料，就算中途换人接手也容易补上来。真没必要在这个阶段引入微服务那套，给自己找不痛快。

1.3 场景定位：从“能用”到“像样”的项目分层

同样的题目，有人做出来像课程作业，有人做出来像商业项目，差距在哪？在于对场景细节的还原度。

举个例子，“人员管理”这个模块，初级做法是建一张人员表做增删改查；高级做法会把人分成管理员、监理、施工队负责人、普通工人等不同角色，每个人关联部门或班组，考勤记录来自闸机进出事件，再配合工地的区域权限，比如塔吊操作员只能进入对应塔吊的监控范围。

还比如告警功能，不能只管一个空泛的“环境超标”。要区分粉尘浓度PM10超标还是噪声超标，不同告警对应不同的处置流程——粉尘超标自动启动喷淋降尘，噪声超标推送消息给现场负责人。“能用”是能存能查，“像样”是贴合实际业务的闭环逻辑。

毕业设计想拿好成绩，学的就是这套从业务场景出发去设计系统的思路。

2. 物联网接入架构与数据流转设计

2.1 设备接入设计：别只盯着HTTP，MQTT才是IoT的主流

说到物联网接入，很多同学的第一反应是设备通过HTTP接口POST数据到后端，但这在真实场景里并不是最优解。工地上设备量大、信号不稳定、数据要频繁上报，HTTP这种请求-响应模式，第一效率不高，第二设备端代码复杂，第三服务器也不好做消息的主动下发。

MQTT才是当前物联网接入的主流协议，我强烈建议在毕设里把它用上。MQTT基于发布/订阅模型，设备端作为客户端，连上MQTT Broker之后，往某个主题发布消息就行。服务端要做的，就是订阅对应的主题，实时收到这些上报数据。反过来，服务器想控制设备，就往命令主题发一条消息，设备端收到后执行动作。

架构长这样：

• 设备（或模拟器）→ MQTT Broker（EMQX） → Spring Boot 通过MQTT客户端订阅主题 → 解析数据 → 存入MySQL/更新Redis缓存 → 触发业务规则 → WebSocket推送前端
• 前端用户在页面点击“远程启动喷淋”→ 调用Spring Boot API → Spring Boot向设备命令主题发布消息 → 设备模拟器收到后改变状态并回报

这个链路走通后，你对物联网系统的理解会上一大截。之后不管换成阿里云IoT平台还是华为云IoTDA，逻辑都一样，只是Broker变了而已。

2.2 主题规划和消息协议：设备数据乱传是大忌

设备接入最容易翻车的是消息主题规划混乱。你想象一下，如果所有设备都把数据发到一个主题里，服务端收到消息后还得自己判断消息来自哪台设备，数据一多就乱套了。

更合理的做法是，接入层就按照“设备类型/设备标识/数据类型”的规则进行主题规划。比如塔吊的实时数据主题设计为：

plaintext复制smart-site/device/tower-crane/T001/metrics

其中smart-site是项目标识，tower-crane是设备类型，T001是设备编号，metrics表示上报的是运行指标。服务端订阅时按层级通配，就能轻松接收所有设备的上报消息。

数据内容建议统一用JSON格式，并且约定好协议结构：

json复制{
  "deviceId": "T001",
  "type": "tower-crane",
  "timestamp": "2025-06-01 14:30:22",
  "data": {
    "loadWeight": 2.5,
    "maxLoad": 6.0,
    "windSpeed": 4.2,
    "obliqueAngle": 0.8
  }
}

用一个统一的协议把设备ID、上报时间、业务数据分开，服务端解析时就会非常轻松，也方便后面扩展新的设备类型。

2.3 数据模拟器：毕设不提真实硬件也能跑通全链路

我明白很多人会担心，手头没有真实的扬尘监测仪、没有塔吊传感器，也没法去施工现场部署摄像头，这个系统怎么演示？答案是写一个数据模拟器。

模拟器的做法并不复杂，本质上是写一个Java程序或者Python脚本，定时按照MQTT协议往Broker发布模拟数据。比如每3秒生成一条塔吊数据，载重在一定范围内按正弦规律波动，偶尔超出阈值触发告警。再比如每5秒上报一条扬尘数据，PM2.5和PM10按某个随机算法生成，模拟出一天内早晚高峰浓度较高的规律。

模拟器的价值体现在两个地方：一是开发阶段你不用等硬件就能把整套云端逻辑调试好；二是答辩演示的时候，你能通过调大模拟频率，眼见地看到大屏上的数据跳动、告警触发，演示效果比静态截图好太多。

模拟器代码用Java写也行，用Python写也行，如果还没有太明确的偏好，我用Java给你打个样，直接放到Spring Boot里当独立模块跑：

java复制@Component
public class TowerCraneDataSimulator implements Runnable {

    @Autowired
    private MqttGateway mqttGateway;

    private double load = 2.0;
    private boolean running = true;

    @PostConstruct
    public void start() {
        ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2);
        scheduler.scheduleAtFixedRate(this, 0, 3, TimeUnit.SECONDS);
    }

    @Override
    public void run() {
        // 模拟载荷在一定范围内波动
        load = 2.5 + 1.5 * Math.sin(System.currentTimeMillis() / 10000.0);
        JSONObject payload = new JSONObject();
        payload.put("deviceId", "T001");
        payload.put("type", "tower-crane");
        payload.put("timestamp", LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));

        JSONObject data = new JSONObject();
        data.put("loadWeight", Math.round(load * 100) / 100.0);
        data.put("maxLoad", 6.0);
        data.put("windSpeed", 3.0 + Math.random() * 4);
        data.put("obliqueAngle", Math.random() * 1.5);
        payload.put("data", data);

        mqttGateway.sendToTopic(payload.toJSONString(), "smart-site/device/tower-crane/T001/metrics");
    }
}

写完模拟器，相当于打通了整个系统的输入源头，之后的每一步都是在这条活数据的管道上做文章。

3. 核心模块设计与数据库建模

3.1 监控中心模块：让用户随时掌握工地全貌

监控中心是系统的脸面，也是答辩演示时最加分的模块。它的主要职责是把所有关键信息汇集到一个页面上，包括实时视频流、环境监测曲线、人员定位、塔吊运行状态、车辆进出记录等。页面布局尽量模仿市面上成熟的可视化大屏：中间是工地平面图或者视频画面，两侧是ECharts绘制的实时数据图表。

想把这个模块做好，需要处理两类数据：一个是实时数据，讲究“快”，比如设备上报的频率，三秒一次；一个是统计数据，讲究“准”，比如今天有多少人出勤，出勤率是多少。

实时数据的展示不推荐反复查询MySQL，更好的做法是用Redis缓存。每台设备的最新一条状态都存成一份独立的缓存记录，前端请求概览页时直接读Redis，一次查询就能拿到所有设备的实时状态，速度能到毫秒级。统计数据才需要定期从MySQL聚合，比如每5分钟算一次最近一个小时的环境平均值，存到另一张统计表里供图表展示。

3.2 人员与考勤管理：从能增删改查到能“管”的进阶路线

人员与考勤管理看似是个常规CRUD，但这个模块恰恰能体现你系统设计的功力。真正的工地考勤不是员工自己在手机上打卡（工地管理对象中不少是一线操作工人，手机操作不现实），而是通过闸机联动——工人刷脸或刷卡进出工地，闸机把通行记录发给后端，后端根据进出方向和通行时间自动算出勤。

在数据层面，我建议至少设计以下几张核心表：

• 员工信息表：包含姓名、手机号、角色、班组、身份证号、头像URL等字段
• 考勤记录表：包含员工ID、通行方向（进/出）、识别方式、通行时间、设备编号
• 班组表：用于把员工分组，便于按班组统计出勤情况

演示的时候，可以手动模拟几条人员进出记录，之后前端报表中就能看到应出勤人数、实际出勤人数、迟到和缺勤情况。能演示到这个深度，已经远超普通增删改查。

3.3 资源调度与设备联动：真正体现“智慧”的地方

这块是整个项目里技术含量最高的部分，也是能拿得出手的干货。它的目标不是简单地把设备状态列出来，而是根据预设的规则，自动控制设备和安排资源。

我拿两个比较典型的场景来说明。

场景一：扬尘联动喷淋。工地围挡上安装了扬尘监测仪，一旦检测到PM10浓度超过预设上限（比如150mg/m³），系统就自动向喷淋控制器的指令主题发送一条“开启喷淋”的消息；等PM10降回到安全值以下，再发送“关闭喷淋”的消息。整个过程不需要人的干预。

场景二：车辆调度。工地门口有地磅和闸机，运料车辆进场时先过磅称重，系统根据当前各区域施工进度和已有物料，自动分配卸料区域并通知司机。司机在手机上看到推送消息后按指引进场卸料。

在毕业设计的语境下，要做到资源调度的“自动决策”确实有难度。比较务实的实现策略是做一个“规则引擎”：把各种触发条件写成可配置的规则存在数据库表里，后台管理页面支持自定义阈值和联动动作。核心逻辑就是定期扫描设备数据，命中条件就触发动作。

3.4 数据库设计核心经验

这个项目要建的数据库表加起来可能有20多张，其中几张关键表能够直接影响系统的稳定和扩展性，值得单独拿出来讲讲。

设备信息表是整个系统的基础，设备编码要全局唯一，建议在程序里生成而非依赖数据库自增，这样就算以后对接多个数据源也不会重复。同时设备和工地项目要建立关联关系，因为智慧工地平台很可能同时管理多个项目，不能把设备全部混在一起。把project_id作为外键字段设计进去，是这类系统一个比较标准的做法。

告警记录表要记录的具体字段包括：告警设备、告警类型（环境超标、超载、倾斜、离岗）、当前数值、阈值、发生时间、处理状态、处理人等等。状态字段要支持多态——告警从发生到处理到关闭是一个流转过程，而不只是一个“是否已读”的标记。

操作日志表建议贯穿全系统：谁在什么时间改了哪个设备的阈值，谁手动远程控制了什么设备，都要记录。这种东西看似不起眼，但在答辩的时候能回答很多实际业务问题。

4. 核心业务链路与关键代码

4.1 服务端订阅MQTT消息并落库

要让Spring Boot具备订阅MQTT主题的能力，首先需要引入依赖并做配置。我这里用的是Eclipse Paho客户端，配置类里需要指定Broker地址、客户端ID、用户名和密码（如果Broker开启了认证）。

关键配置如下：

yaml复制mqtt:
  broker: tcp://localhost:1883
  client-id: smart-site-server
  username: admin
  password: public
  topic: smart-site/device/#
  timeout: 3000
  keepalive: 60

注意topic是“smart-site/device/#”，“#”表示匹配所有层级。这样做的好处是，不管来的是塔吊、扬尘监测还是闸机事件，服务端都能收到，再由消息处理器根据type字段分发到不同逻辑里去。

在启动类上打上用来的注解之后，通过实现回调接口处理消息：

java复制@Component
public class MqttMessageHandler implements MqttCallback {

    @Autowired
    private DeviceDataService deviceDataService;

    @Override
    public void messageArrived(String topic, MqttMessage message) {
        String payload = new String(message.getPayload());
        JSONObject json = JSONObject.parseObject(payload);
        String type = json.getString("type");
        switch (type) {
            case "tower-crane":
                deviceDataService.processTowerCraneData(json);
                break;
            case "environment":
                deviceDataService.processEnvironmentData(json);
                break;
            case "access":
                deviceDataService.processAccessData(json);
                break;
            default:
                // 未知设备类型，记录日志
                break;
        }
    }

    @Override
    public void connectionLost(Throwable cause) {
        // 重新连接逻辑
    }

    @Override
    public void deliveryComplete(IMqttDeliveryToken token) {
        // 消息发送成功的回调
    }
}

4.2 实时告警并WebSocket推送前端

告警处理不能只在后端保存一条记录就结束，真正的在线监控系统必须让页面实时弹窗提醒。

实现逻辑：当处理环境监测数据时，判断数值是否超过阈值，如果超过，则产生告警事件。告警事件除了落库，还要通过WebSocket推送到在线的前端页面。

WebSocket在Spring Boot里的实现有很多成熟方案，核心流程是：前端页面加载完成后，建立与后端的WebSocket长连接；后端收到告警事件后，通过Session对象推送JSON消息。前端收到消息，如果是页面上正在监控的设备类型，就弹窗并声音提醒。

需要注意的是，在线用户可能同时有多个，比如项目经理看着大屏、安全员开着手机页面。推送时要注意去重和定向：哪个用户关注了哪个项目的告警，就推给谁，而不是把所有告警推给所有用户。毕业设计阶段可以简化成推送给同一项目下的所有在线用户，但你要知道这个边界在哪。

告警处理代码大致如下：

java复制@ServerEndpoint("/ws/alert/{projectId}")
@Component
public class AlertWebSocketServer {

    private static ConcurrentHashMap<String, Session> sessionMap = new ConcurrentHashMap<>();

    @OnOpen
    public void onOpen(Session session, @PathParam("projectId") String projectId) {
        sessionMap.put(projectId + "_" + session.getId(), session);
    }

    @OnClose
    public void onClose(Session session, @PathParam("projectId") String projectId) {
        sessionMap.remove(projectId + "_" + session.getId());
    }

    public static void sendAlert(String projectId, String message) {
        sessionMap.forEach((key, session) -> {
            if (key.startsWith(projectId)) {
                try {
                    session.getBasicRemote().sendText(message);
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        });
    }
}

4.3 告警数据落库与分析展示

能够触发告警逻辑只是数据流向的中间环节，另一端需要有清晰的落库策略。核心建议是：告警记录实时插入报警表，同时把原始数值追加写入某个设备的实时监控数据表。

如果每台设备每3秒上报一条，一天下来单台设备会产生2万多条记录，几十台设备就是上百万条。对毕业设计阶段的MySQL来说，这个量级还能抗住，但最好从一开始就按天分表，或者定期清理一个月前的原始监测数据，只保留统计结果。这样系统跑很久都不会卡。

告警记录的表结构，我的建议是：

sql复制CREATE TABLE alert_record (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    project_id VARCHAR(32) NOT NULL,
    device_id VARCHAR(32) NOT NULL,
    device_type VARCHAR(20) NOT NULL,
    alert_type VARCHAR(50) NOT NULL,
    alert_value DECIMAL(10, 2),
    threshold_value DECIMAL(10, 2),
    alert_level TINYINT COMMENT '1-一般, 2-严重, 3-紧急',
    alert_time DATETIME NOT NULL,
    process_status TINYINT DEFAULT 0 COMMENT '0-未处理, 1-处理中, 2-已关闭',
    process_user VARCHAR(32),
    process_time DATETIME,
    remark VARCHAR(255)
);

做统计报表时，按小时、天、周、月的时间粒度分别用对应的SQL进行查询，把告警次数、平均响应时间、各类告警占比等指标汇总展示。

5. 前端可视化大屏与后台管理界面

5.1 可视化大屏怎么设计才加分

毕设答辩中，演示环节的观感非常影响整体评分。数据可视化大屏如果设计得漂亮，整个项目的档次感立刻不一样。不过毕业设计阶段别乱用那些需要商业授权的复杂大屏框架，直接用ECharts，配合Vue的路由和布局，也能做出很强的视觉效果。

大屏常见的布局是：

• 顶部显示项目名称和当前时间
• 中间左侧显示环境监测、设备运行状态
• 中间核心区域播放视频或者显示工地平面图
• 右侧显示人员出勤、告警统计、车辆进出情况

图表类型也要有所选择。环境监测数据适合折线图，因为要展示趋势变化；人员出勤情况适合柱状图或漏斗图，一眼看出各个环节人数；告警统计适合饼图或环形图，展示不同告警类型占比。

大屏上所有数据走定时刷新机制，比如前端每隔5秒请求一次后端接口拿最新数据。真正做到实时推送也可以，但考虑到答辩现场的稳定性，定时刷新加局部更新往往比全量刷新更可靠。

5.2 监控模块的“视频接入”处理细节

“云监控”这个配置词里面含着视频，没做过视频接入的同学很可能在这里卡住。直接接入海康威视或者大华的摄像头SDK，需要注册开发者账号搞授权，对毕设来说太麻烦。

推荐的替代方案是用RTSP流模拟视频源，再用WebRTC或HLS在网页播放。更简化一点：如果你的系统里要展示“工地实时画面”，可以直接放一张每隔几秒刷新一次的现场抓图图片，看起来和视频监控的区别不大，但根本不需要处理流媒体。

要是想做得更真一些，可以用FFmpeg把一段工地实时视频流转成HLS流，然后在前端用video.js播放。具体操作时候，服务器要装FFmpeg，命令大概长这样：

bash复制ffmpeg -re -i input.mp4 -c:v libx264 -c:a aac -f flv rtmp://localhost/live/site01

视频这块是很多人的能力盲区，如果时间紧张，优先用图片轮播方案，先把核心功能做完，再回头考虑加视频。

5.3 后台管理的核心页面清单

后台管理界面包含的页面要与功能模块一一对应。建议做一个侧边栏加顶栏的经典布局，大致的页面清单如下：

• 系统概览：今日出勤、告警数、设备在线状态
• 设备管理：设备台账、设备类型、设备状态管理
• 监控中心：实时视频与各设备实时数据查看
• 环境监测：扬尘、噪声、温湿度、风速等指标数据查询
• 告警中心：告警列表、待处理/已处理/已关闭
• 人员管理：员工档案、班组管理、考勤查询
• 资源调度：车辆调度记录、物料进出场记录
• 数据报表：按时间维度统计各种指标
• 系统设置：用户管理、角色权限、阈值参数配置

页面数量说得挺多，但很多页面是长得很像的表格页，做了第一遍之后，后面用模板复制改改就出来了。前端组件化开发的目的就在这里。

5.4 给后端写接口时容易踩的小坑

在给前端提供接口时，有两个很容易踩的坑，而且踩的人非常多。我在这里先说破，免得你日后独自挣扎。

第一个坑是跨域问题。前端跑在8080端口，后端跑在8081端口，直接请求必然被浏览器的同源策略挡下。解决办法很简单，在后端写个配置类，或者直接在Controller上加注解。对毕设来说，弄一个全局的跨域配置类是最省事的。

第二个坑是时间格式化问题。Java后端返回LocalDateTime类型时，默认序列化结果是一串数组或者带T的字符串，前端的日期选择组件和表格都可能显示不正常。解决方式是配置统一的Jackson序列化规则：

java复制@Configuration
public class JacksonConfig {

    @Bean
    public Jackson2ObjectMapperBuilderCustomizer customizer() {
        return builder -> {
            builder.serializerByType(LocalDateTime.class,
                new LocalDateTimeSerializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
        };
    }
}

另外就是前端的接口封装和异常处理，不论后端返回成功还是失败，都应该统一响应结构。前端拿到的格式一致，处理逻辑就简单很多。我习惯用这种结构：

json复制{
  "code": 200,
  "message": "success",
  "data": {}
}

6. 部署与调试中的常见问题

6.1 本地开发跑起来的环境配置清单

下面是整套系统本地开发的基础环境，每一项后面对应版本注意事项都有讲究：

运行emqx之前记得先检查端口是否被占用，默认端口是1883。Redis如果没设密码，启动后客户端连接别填密码就行。

6.2 设备模拟器连接不上MQTT到底怎么排查

这个问题的出现率极高。模拟器运行后，后端一直收不到数据，查来查去发现EMQX管理后台里根本没有客户端连接。通常的原因有这几个：

• Broker地址写错了：常见的是把tcp://localhost:1883写成了http://localhost:1883
• 端口被防火墙拦了：本地开发一般没这个问题，装了某些安全软件的电脑要放行
• 客户端ID冲突：EMQX同一时刻不允许两个客户端用同一个Client ID，如果上次异常断开没释放，这次就连接不上。模拟器重启时最好随机生成一次Client ID
• 没有订阅正确的主题：连接Broker成功但订阅了不存在的主题，自然收不到数据

如果还是不行，就打开EMQX的Dashboard地址，默认是localhost:18083，在“客户端”菜单里能看到当前连上来的客户端列表。如果列表是空的，说明模拟器到Broker这一段断了，问题不在服务端。

6.3 WebSocket连接经常断开的隐藏凶手

做WebSocket推送时，一个常见问题是在服务器和前端的连接之间夹着一层Nginx反向代理。在本地开发环境直接访问后端端口可能没事，一旦部署到服务器上用Nginx转发，WebSocket连接就会反复断开。原因在于Nginx默认没有开启WebSocket升级协议。

解决办法是在Nginx配置里加上这样一段：

nginx复制proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600s;

如果是在本地直接访问后端，没经过Nginx还频繁掉线，大概率是心跳问题。WebSocket服务端要定时给前端发心跳包，或者前端定时向服务端发Ping消息，维持连接活跃状态，否则网关层会认为空闲连接不健康，主动帮你断开。

6.4 前端跨域后什么都调不通

开发时最常见的现象是：前端页面能打开，接口测试工具能调通，但页面里的请求全部失败。打开浏览器控制台，看到报错信息是CORS相关的。

跨域有传统解决方案也有更省事的方案。最简单粗暴的方式是前端开发时用Vite或Webpack的proxy代理，把请求代理到后端地址上，浏览器看到的是同域请求，就没有跨域问题。也可以用反向代理方式把前后端部署在同一个域名下。

如果说非要用跨域方式，也可以后端统一配置：

java复制@Configuration
public class CorsConfig {

    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedOrigin("*");
        config.addAllowedMethod("*");
        config.addAllowedHeader("*");

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return new CorsFilter(source);
    }
}

我这里把允许来源故意设置成了“*”，毕设阶段问题不大，如果上线了要按域名白名单收紧。

7. 从毕设到项目落地的几条扩展建议

7.1 功能层面：往AIoT方向延伸

技术演进到今天，纯“监控与展示”其实已经不算亮点，如果想让系统有更多想象空间，可以考虑引入轻量级的AI能力。

比如，在现有人员管理模块上叠加安全帽识别功能：写一个Python脚本，用OpenCV读取视频帧，调用一个预训练的目标检测模型（比如YOLOv5）去识别画面中的人是否佩戴了安全帽。检测到未佩戴安全帽的人时，脚本把告警消息通过MQTT发到后端，后端再走一套已有的告警流程。这样做的好处很明显——你不仅展示了一个常规的信息管理系统，还展示了物联网与AI技术的融合能力。

这个扩展是可行的，不需要很强的算法功底，更不用自己训练模型，用现成的开源框架就可以搞定。把Java的Spring Boot和Python的AI检测脚本串起来的桥梁就是MQTT和HTTP接口。

7.2 架构层面：从单机到云原生演进

现在做的系统，架构上属于单体应用。真实商用场景中，设备数量上升到方台级别之后，单体结构会非常吃力。可以在文档中预留一个“未来架构演进”章节，画出如何从单体迁移到微服务的思路。

比如把这些独立模块拆开：设备接入服务负责跟MQTT打交道，告警分析服务做数据判断，通知推送服务负责消息推送，数据报表服务提供统计查询接口。之间通过消息队列解耦，或者通过注册中心做服务发现。展示这个演进思路，即使不真的把微服务全部写出来，也能让毕业论文体现出对架构设计的思考。

7.3 部署层面：打包部署的步骤

毕设最终要能在答辩现场正常演示，提前把部署流程跑通很关键。推荐将前后端分别打包：Spring Boot项目用Maven打包成jar，注意资源文件的配置；Vue项目执行构建命令生成dist静态文件。部署方式可以根据服务器环境选择合适的方案，但要注意Java应用内存占用，以及数据库和消息中间件等服务要配置成开机自启，避免服务器重启后整套系统起不来。

还有一个很容易踩的坑是配置文件的分离。开发环境的数据库密码、测试环境的MQTT地址、生产环境的签名密钥都应该写在不同的配置文件里，切换环境只要指定一个profile就好。

7.4 文档层面：毕业论文撰写的建议

代码全部做完之后，千万别忽视毕业论文。先纠正一个常见错误——不要按照开发时序写论文，先做好的模块先写。论文的叙事逻辑应该是从宏观到微观、从设计到实现的完整闭环。推荐按照“需求分析 → 总体架构设计 → 数据库设计 → 后端核心模块实现 → 前端可视化实现 → 系统测试”的顺序来组织。

在需求分析章节，尽量用用例图和用例描述；总体架构设计章节附图说明逻辑架构和物理架构；核心模块实现按功能章节拆分，用流程图配合代码片段，讲清楚每个模块的处理流程；测试章节不要只写“功能正常”，要写清楚测试环境、测试数据、测试用例设计，甚至给出性能测试的基本数据和结果分析。这些内容是答辩老师最关心的。

8. 常见问题速查表

为了让你在开发过程中遇到问题可以直接查，我把前面提到的一些高频问题整理成了一张速查表。

这张表是开发过程中最容易踩的坑。可以打印出来贴在显示器旁边，能省下不少排查时间。

写这篇文章的时候，我又重新过了一遍当初自己做智慧工地项目的思路和踩坑记录。这个题目真正值得做的地方，在于它逼着你跳出“只会CRUD”的舒适区，去面对设备接入协议、实时消息推送、异常数据检测、复杂报表展示这一连串真实工程问题。你能把这些环节串起来，哪怕每个环节都只用了最基础的方式，你都拥有了见到一座“系统”而不是“作业”的完整经验。

如果你正在被这套毕业论文和系统的组合任务折磨，我的建议只有一句话：先别急着敲代码，把设备数据从诞生到展示的整条链路在纸上画通，然后再动手。链路清楚了，剩下的就只是把它翻译成Java和一个又一个接口。按照这个思路推进，你能做出来，而且能做好。