簡介這是一份面向計算機專業(yè)畢業(yè)設(shè)計或課程作業(yè)的智慧能耗管理系統(tǒng)后端源碼包適合正在做能耗監(jiān)控、數(shù)據(jù)采集與智能化管理項目的學(xué)生或開發(fā)者參考。系統(tǒng)整合物聯(lián)網(wǎng)、大數(shù)據(jù)分析與人工智能技術(shù)可用于學(xué)習(xí)后端業(yè)務(wù)邏輯、數(shù)據(jù)庫設(shè)計、API接口開發(fā)以及能耗預(yù)測等算法落地。壓縮包共481個文件約53.56MB以277個Java源碼文件為主體輔以171個XML配置、數(shù)據(jù)庫腳本、部署及監(jiān)控相關(guān)文件整體結(jié)構(gòu)覆蓋從項目文檔到測試與部署的完整鏈路。已有67人學(xué)習(xí)瀏覽。通過研讀源碼可掌握Spring類框架下的服務(wù)端分層實現(xiàn)、接口定義、數(shù)據(jù)持久化及容器化部署思路也能理解智慧能源場景中從設(shè)備數(shù)據(jù)接入到分析決策的工程化流程對完成類似畢設(shè)或提升后端實戰(zhàn)能力有直接幫助。1. 一份畢設(shè)級智慧能耗管理系統(tǒng)后端它到底是什么、值不值得做拿到這個標題時我第一反應(yīng)是又是一個把畢設(shè)源碼打包成 zip 的常見套路。但“智慧能耗管理系統(tǒng)”這個方向本身不算水它背后是建筑節(jié)能、設(shè)備數(shù)據(jù)采集、分項計量、趨勢報表這一整套真實業(yè)務(wù)。后端要做的事很明確管住設(shè)備、收住數(shù)據(jù)、算準能耗、按時出報表。放在畢設(shè)里它比普通 CRUD 多了一層數(shù)據(jù)采集和定時統(tǒng)計的味道答辯時也更好講。適合計算機科學(xué)與技術(shù)、軟件工程、物聯(lián)網(wǎng)方向的畢設(shè)選題。如果你是想在 springbootvue 前后端分離項目里找一個有業(yè)務(wù)深度的題目這個方向可以認真考慮。這篇我按最主流的 Spring Boot MyBatis-Plus MySQL Redis 組合把這個項目的后端從解壓到跑通、從采數(shù)到出報表完整拆一遍。2. 拆解后端模塊與數(shù)據(jù)模型先把數(shù)據(jù)庫設(shè)計立住2.1 模塊劃分與前后端分離的接口邊界智慧能耗管理系統(tǒng)的后端模塊劃分比普通管理系統(tǒng)要多一層“數(shù)據(jù)采集”的職責(zé)。常見的分層方式是系統(tǒng)管理用戶、角色、菜單、基礎(chǔ)檔案建筑、樓層、設(shè)備、能耗業(yè)務(wù)采集、統(tǒng)計、分項、報表展示日/月/年報表、告警管理超限提醒。前后端分離的項目里后端只出 JSON 接口前端用 Vue 去調(diào)。這里有一個畢設(shè)里特別容易翻車的點很多人把報表邏輯寫在 SQL 里然后在 Controller 里堆一大段 JDBC 代碼最后接口返回結(jié)構(gòu)亂七八糟前端拿不到數(shù)據(jù)。常見做法是后端統(tǒng)一返回ResultT結(jié)構(gòu)包含 code、message、data 三個字段前端所有請求都走這個結(jié)構(gòu)聯(lián)調(diào)時才不會天天吵架。接口邊界上采集接口和管理接口要分開。設(shè)備上報數(shù)據(jù)走/api/collect/**不需要登錄攔截管理端接口走/api/admin/**必須帶 token。這個設(shè)計在畢設(shè)答辯時是加分項因為能講清楚“設(shè)備數(shù)據(jù)是機器寫的用戶操作是人工寫的兩類請求的安全級別不一樣”。2.2 核心表結(jié)構(gòu)用一路 DDL 講清能耗數(shù)據(jù)怎么落地先建建筑表和設(shè)備表這兩張是基礎(chǔ)檔案屬于“被引用”的表。-- 建筑信息表 CREATE TABLE building ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, building_no VARCHAR(32) NOT NULL COMMENT 建筑編號, building_name VARCHAR(128) NOT NULL COMMENT 建筑名稱, area DECIMAL(12,2) NOT NULL DEFAULT 0 COMMENT 建筑面積(㎡), energy_type TINYINT NOT NULL DEFAULT 0 COMMENT 能耗類型: 0電 1水 2氣 3熱, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_building_no (building_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT建筑信息表; -- 設(shè)備信息表 CREATE TABLE device ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, building_id BIGINT UNSIGNED NOT NULL COMMENT 所屬建筑ID, device_no VARCHAR(64) NOT NULL COMMENT 設(shè)備編號, device_name VARCHAR(128) NOT NULL COMMENT 設(shè)備名稱, energy_type TINYINT NOT NULL DEFAULT 0 COMMENT 能耗類型, status TINYINT NOT NULL DEFAULT 1 COMMENT 狀態(tài): 0停用 1啟用, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_building_id (building_id), KEY idx_device_no (device_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT設(shè)備信息表;這兩張表的邏輯說明device 表通過building_id關(guān)聯(lián) building形成“建筑—設(shè)備”的一對多關(guān)系。energy_type用 TINYINT 存類型值不要直接存字符串否則統(tǒng)計時到處都是case when。參數(shù)說明面積字段用 DECIMAL(12,2)精度到平方米后兩位足夠記錄建筑規(guī)模設(shè)備編號用 VARCHAR(64)因為實際項目中設(shè)備編號可能帶前綴和區(qū)段太短很容易被卡住。能耗記錄表是整個系統(tǒng)的核心也是數(shù)據(jù)量增長最快的一張表。-- 能耗采集原始記錄表 CREATE TABLE energy_record ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, device_id BIGINT UNSIGNED NOT NULL COMMENT 設(shè)備ID, building_id BIGINT UNSIGNED NOT NULL COMMENT 建筑ID, energy_type TINYINT NOT NULL COMMENT 能耗類型, record_time DATETIME NOT NULL COMMENT 采集時間, value DECIMAL(14,4) NOT NULL COMMENT 讀數(shù): 電kWh/水m3/氣m3, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_device_time (device_id, record_time), KEY idx_building_time (building_id, record_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT能耗采集原始記錄表;這段 DDL 的關(guān)鍵點value 用 DECIMAL(14,4)四位小數(shù)是為了承接采集器上報的精度比如電表讀數(shù)可能到小數(shù)點后四位索引建在(device_id, record_time)和(building_id, record_time)上這是能耗查詢最常見的兩個維度——按設(shè)備查趨勢、按建筑查匯總。這里要提醒一句聯(lián)合索引列的順序不能反等值條件的列放前面范圍條件的列放后面否則索引利用率會明顯下降。2.3 為什么不用一張大表存所有能耗數(shù)據(jù)這是很多畢設(shè)代碼里最難看的地方。有人偷懶把所有能耗數(shù)據(jù)塞進一張energy_data大表字段包括電、水、氣、熱四列哪來的數(shù)據(jù)就填哪列。這種設(shè)計在演示階段沒問題一到了真實場景就崩。原因有三一是四類能耗的量綱不同電是 kWh、水是 m3、氣是 m3塞在同一行里前端展示時得反復(fù)判斷二是采集頻率不同電表可能 15 分鐘一條水表一天一條按行存才能貼合各自的粒度三是報表統(tǒng)計時基于record_time分組一張寬表會讓 GROUP BY 的復(fù)雜度上升。常見做法是只保留energy_type區(qū)分類型查詢時再用條件過濾。如果你擔(dān)心原始數(shù)據(jù)量太大常見做法是保留原始記錄表之外再建一張小時級聚合表energy_hourly定時任務(wù)把原始表聚合到小時表報表走聚合表這樣查詢性能和解說邏輯都順了。這里要注意分表邊界畢設(shè)數(shù)據(jù)量一般在萬級到十萬級單表完全抗得住不需要做分表。答辯時如果被問到“數(shù)據(jù)量大了怎么辦”標準答法是“生產(chǎn)環(huán)境按record_time做月分區(qū)或按 device 做分表但畢設(shè)階段用索引 聚合表足夠”不要給自己挖坑。3. 把 zip 變成能跑的工程解壓、配置與啟動全流程3.1 解壓前的檢查zip 偽加密與解壓工具選擇這個標題里帶 zip 后綴別看到壓縮包就雙擊解壓。畢設(shè)源碼包在流傳過程中經(jīng)常被二次打包有人會順手加上 zip 偽加密——也就是文件頭標記了加密但實際數(shù)據(jù)沒加密或者反過來。表現(xiàn)癥狀是解壓時提示需要密碼但你輸入空密碼也解不開用 360 壓縮強制解壓又能出文件。遇到這種情況先別急著找密碼先用命令行工具探一下壓縮包的加密標志位。Windows 下可以用certutil或者直接換 7-Zip 打開看屬性Linux 下用zipinfo -v查看。# 查看 zip 壓縮包的加密標志 zipinfo -v 畢設(shè)_智慧能耗管理系統(tǒng).zip | grep -i encryption # 如果確認是偽加密直接強制解壓Linux 下 7z x 畢設(shè)_智慧能耗管理系統(tǒng).zip -y # Windows 下沒有 7z 時用 PowerShell 調(diào) .NET 解壓 Expand-Archive -Path 畢設(shè)_智慧能耗管理系統(tǒng).zip -DestinationPath D:\project\energy這段命令的邏輯說明zipinfo -v會輸出壓縮包內(nèi)每個文件的詳細屬性如果看到encryption: ZipCrypto但文件實際能解出來基本就是偽加密。7z x強制解壓時7-Zip 會對偽加密文件自動跳過密碼校驗這是常見做法。參數(shù)說明-y表示所有詢問都默認 yes避免交互卡住-o7-Zip 里是-o指定輸出目錄注意-o和目錄路徑之間不能有空格這是 7-Zip 特有的坑。另外畢設(shè)源碼包的目錄結(jié)構(gòu)一般是有講究的。常見結(jié)構(gòu)是backend/放后端、frontend/放 vue 前端或者直接一層目錄塞著pom.xml、src/、doc/。解壓后先看根目錄有沒有pom.xml或package.json有pom.xml就是 Maven 工程有package.json就是 Node 工程兩個都有就是前后端分離。這個判斷 5 秒內(nèi)完成別急著打開 IDE。3.2 修改 application.yml數(shù)據(jù)庫、Redis 與時區(qū)參數(shù)后端工程的配置集中在application.yml里。這一節(jié)最重要因為畢設(shè)源碼包自帶的配置大概率是原作者本機的數(shù)據(jù)庫密碼、端口、Redis 地址都得改成你自己的。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/energy_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 password: database: 0 servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl jwt: secret: your-jwt-secret-key-change-me expire: 86400 # token 有效期單位秒配置邏輯說明數(shù)據(jù)源 URL 里的serverTimezoneAsia/Shanghai是必填的不填 MySQL 8.x 驅(qū)動會直接報時區(qū)錯誤填了 UTC 會導(dǎo)致統(tǒng)計口徑偏移 8 小時這個坑在第五章細說。Redis 如果你的本機沒設(shè)密碼就留空但生產(chǎn)環(huán)境必須設(shè)密碼。jwt.secret是 token 簽名密鑰畢設(shè)源碼包自帶的默認值一定要換掉否則任何人都能用同一個密鑰偽造 token這在答辯演示時最容易翻車。expire: 86400是 token 有效期24 小時對畢設(shè)演示夠用如果想做“記住我”功能可以改成 6048007 天。map-underscore-to-camel-case 這個參數(shù)必須開。數(shù)據(jù)庫字段都是building_no、create_time這種下劃線風(fēng)格Java 實體類里是buildingNo、createTime不開這個開關(guān)MyBatis 查出來的結(jié)果全部是 null而且不會報錯排查起來很費勁。log-impl 配成 StdOutImpl 是為了在控制臺直接看 SQL畢設(shè)階段別關(guān)掉它別看“日志刷屏”就覺得礙眼出問題時有 SQL 可看才能最快定位。3.3 初始化數(shù)據(jù)庫與啟動后端的最小命令序列數(shù)據(jù)庫腳本一般在 zip 的sql/或doc/目錄下文件名常見的是init.sql或energy_db.sql。如果壓縮包里沒有現(xiàn)成 SQL就按第二章的 DDL 自己建。初始化命令# 登錄 MySQL創(chuàng)建數(shù)據(jù)庫并導(dǎo)入腳本 mysql -uroot -p CREATE DATABASE energy_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE energy_db; SOURCE /path/to/init.sql; # 測試連接 mysql -uroot -p -h127.0.0.1 -P3306 energy_db -e SELECT COUNT(*) FROM device;數(shù)據(jù)庫初始化完成后啟動后端。Maven 工程的標準啟動方式是mvn spring-boot:run但畢設(shè)源碼包經(jīng)常依賴沒下全第一次啟動大概率會報紅。常見做法是先mvn clean install -DskipTests把依賴拉全再用 IDE 啟動。-DskipTests是跳過測試用例畢設(shè)項目的測試類多半沒寫但 JUnit 依賴沒配齊時跑測試會直接卡住。啟動成功的標志是控制臺出現(xiàn)Tomcat started on port(s): 8080然后馬上用curl打一個健康檢查接口確認服務(wù)活著。# 啟動后驗證服務(wù)是否可用 curl -X GET http://localhost:8080/api/admin/building/list -H Authorization: Bearer your-token4. 能耗采集、統(tǒng)計與報表的核心實現(xiàn)4.1 設(shè)備數(shù)據(jù)采集接口冪等寫入與防重采集接口是能耗管理系統(tǒng)和普通 CRUD 系統(tǒng)最大的分水嶺。設(shè)備上報數(shù)據(jù)不是人點按鈕可能是每 15 分鐘自動上報一次網(wǎng)絡(luò)抖動會導(dǎo)致重復(fù)上報。接口里必須做冪等處理否則同一時間點的數(shù)據(jù)會被插兩遍統(tǒng)計報表立刻對不上。Service public class EnergyRecordServiceImpl extends ServiceImplEnergyRecordMapper, EnergyRecord { Autowired private EnergyRecordMapper energyRecordMapper; /** * 采集數(shù)據(jù)上報入口 * deviceNo 設(shè)備編號, recordTime 采集時間, value 讀數(shù), energyType 能耗類型 */ Transactional(rollbackFor Exception.class) public boolean collect(CollectRequest request) { // 1. 根據(jù)設(shè)備編號查設(shè)備信息設(shè)備不存在直接拒絕 Device device deviceMapper.selectOne(new LambdaQueryWrapperDevice() .eq(Device::getDeviceNo, request.getDeviceNo())); if (device null) { throw new BizException(設(shè)備不存在: request.getDeviceNo()); } // 2. 冪等校驗同一設(shè)備同一采集時間只能有一條記錄 Long count energyRecordMapper.selectCount(new LambdaQueryWrapperEnergyRecord() .eq(EnergyRecord::getDeviceId, device.getId()) .eq(EnergyRecord::getRecordTime, request.getRecordTime())); if (count 0) { // 已存在則更新讀數(shù)保證最終值是最新上報的 EnergyRecord update new EnergyRecord(); update.setValue(request.getValue()); energyRecordMapper.update(update, new LambdaQueryWrapperEnergyRecord() .eq(EnergyRecord::getDeviceId, device.getId()) .eq(EnergyRecord::getRecordTime, request.getRecordTime())); return true; } // 3. 不存在則插入新記錄 EnergyRecord record new EnergyRecord(); record.setDeviceId(device.getId()); record.setBuildingId(device.getBuildingId()); record.setEnergyType(request.getEnergyType()); record.setRecordTime(request.getRecordTime()); record.setValue(request.getValue()); return save(record); } }這段代碼的邏輯說明先查設(shè)備再寫記錄是因為設(shè)備編號是外部傳入的字符串而能耗記錄表里存的是內(nèi)部device_id不先查一遍關(guān)聯(lián)外鍵就是空的。冪等校驗用device_id record_time做唯一判斷比用業(yè)務(wù)主鍵更穩(wěn)因為上報方可能拿不到內(nèi)部 ID。參數(shù)說明Transactional(rollbackFor Exception.class)里 rollbackFor 必須寫Spring 默認只回滾 RuntimeException如果你拋的是自定義 BizException不指定 rollbackFor 就不會回滾數(shù)據(jù)會處于半寫狀態(tài)。4.2 定時統(tǒng)計任務(wù)把原始表聚合成小時表能耗統(tǒng)計是后端另一個硬骨頭。實時查原始表做報表數(shù)據(jù)量一上來就慢而且“小時均值”“日均值”這類指標需要匯總邏輯。常見做法是寫一個定時任務(wù)每小時把原始記錄聚合成小時數(shù)據(jù)。Component public class EnergyStatTask { Autowired private EnergyHourlyMapper hourlyMapper; Autowired private EnergyRecordMapper recordMapper; /** 每小時執(zhí)行一次統(tǒng)計上一小時的能耗數(shù)據(jù) */ Scheduled(cron 0 5 * * * ?) public void statLastHour() { // 統(tǒng)計上一小時的聚合結(jié)果 ListEnergyHourly result recordMapper.selectHourlyStat( LocalDateTime.now().minusHours(1).withMinute(0).withSecond(0).withNano(0), LocalDateTime.now().withMinute(0).withSecond(0).withNano(0)); for (EnergyHourly item : result) { hourlyMapper.insertOrUpdate(item); } } }對應(yīng)的 SQL 寫在 Mapper XML 里select idselectHourlyStat resultTypecom.energy.entity.EnergyHourly SELECT device_id, building_id, energy_type, DATE_FORMAT(record_time, %Y-%m-%d %H:00:00) AS stat_time, SUM(value) AS total_value FROM energy_record WHERE record_time gt; #{startTime} AND record_time lt; #{endTime} GROUP BY device_id, building_id, energy_type, DATE_FORMAT(record_time, %Y-%m-%d %H:00:00) /select這里有個容易踩的細節(jié)定時任務(wù)的執(zhí)行時間不要卡在整點。cron 寫成0 5 * * * ?也就是 0 分 5 秒執(zhí)行原因很簡單——設(shè)備數(shù)據(jù)上報有網(wǎng)絡(luò)延遲多數(shù)采集終端會在整點附近集中上報如果定時任務(wù)也在 0 分 0 秒跑會漏掉還沒來得及入庫的幾條數(shù)據(jù)。往后錯 5 分鐘等上報完成了再統(tǒng)計數(shù)據(jù)就全了。這是血淚經(jīng)驗我之前第一次寫這個任務(wù)就吃了整點執(zhí)行的虧統(tǒng)計結(jié)果天天少幾條。SQL 里的record_time startTime AND record_time endTime是左閉右開區(qū)間避免同一秒的數(shù)據(jù)被統(tǒng)計兩次或漏掉。4.3 報表接口與前端 vue 聯(lián)調(diào)時的數(shù)據(jù)格式報表接口的返回格式直接影響前端能不能直接畫圖。前端常用的圖表庫是 ECharts它需要的數(shù)據(jù)結(jié)構(gòu)是{ categories: [2025-01-01, 2025-01-02], series: [{ name: 用電, data: [100, 200] }] }。后端如果只拋原始表記錄前端得自己再聚合一次不符合“后端算好、前端展示”的分工。常見做法是后端接口直接返回前端畫圖所需的格式。GetMapping(/report/daily) public ResultDailyReportVO dailyReport(RequestParam Long buildingId, RequestParam String startDate, RequestParam String endDate) { // startDate/endDate 格式: yyyy-MM-dd ListEnergyHourly records hourlyMapper.selectByBuildingAndDateRange(buildingId, startDate, endDate); DailyReportVO vo new DailyReportVO(); // 按日期分組累加生成 categories 和 series vo.setCategories(records.stream().map(r - r.getStatTime().toLocalDate().toString()).distinct().toList()); MapString, ListBigDecimal seriesMap new HashMap(); for (EnergyHourly r : records) { String name EnergyTypeEnum.of(r.getEnergyType()).getDesc(); seriesMap.computeIfAbsent(name, k - new ArrayList()).add(r.getTotalValue()); } vo.setSeries(seriesMap.entrySet().stream() .map(e - new SeriesItem(e.getKey(), e.getValue())).toList()); return Result.success(vo); }邏輯說明報表接口不查原始表而是查小時聚合表數(shù)據(jù)量會小 24 倍。distinct().toList()生成橫軸日期列表保證 categories 不重復(fù)且順序穩(wěn)定。參數(shù)說明startDate和endDate用字符串接收而不是 LocalDate是因為日期格式在傳輸中最容易出亂子字符串格式由前端固定傳yyyy-MM-dd后端用 DateTimeFormatter 解析解析失敗直接拋參數(shù)異常簡單可控。5. 后端翻車排查手冊5 個畢設(shè)答辯前必查的坑5.1 跨域?qū)е虑岸苏{(diào)不通接口現(xiàn)象前端 vue devServer 跑在 5173 端口后端接口在 8080瀏覽器控制臺報CORS error接口請求顯示blocked by CORS policy。原因瀏覽器的同源策略攔截了跨端口請求。前端頁面和后端接口的 origin 不一致后端沒返回Access-Control-Allow-Origin響應(yīng)頭。解決后端加全局 CORS 配置允許指定來源訪問。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowCredentials(true)和allowedOriginPatterns(*)組合使用Spring Boot 2.4 之后不能用allowedOrigins(*)配 credentials否則報錯。另一個常見坑是接口報 401 而不是 CORS 錯誤這是攔截器先于 CORS 過濾器執(zhí)行把預(yù)檢請求 OPTIONS 也攔了。解決方法是攔截器里放行 OPTIONS 請求或者把 CorsConfig 改成實現(xiàn)Filter并設(shè)置Order(0)。5.2 登錄接口被攔截器攔死現(xiàn)象前端調(diào)登錄接口后端返回401 未認證但登錄接口明明不需要 token。原因攔截器配置把/api/admin/login也納入了攔截范圍或者攔截器里直接getHeader(Authorization)取到 null 就拋出異常。解決白名單里把登錄、注冊、驗證碼接口放行。常見寫法registry.addInterceptor(new AuthInterceptor()) .addPathPatterns(/api/admin/**) .excludePathPatterns(/api/admin/login, /api/admin/captcha);另一個坑是攔截器里 token 解析失敗時拋了ExpiredJwtException這個異常沒有被全局異常處理器捕獲返回的是一長串堆棧而不是{code: 401}。解決的常見做法是在RestControllerAdvice里加一個專門捕獲ExpiredJwtException的方法返回 code 401 和“登錄已過期請重新登錄”。5.3 數(shù)據(jù)庫時區(qū)錯亂導(dǎo)致能耗統(tǒng)計對不上現(xiàn)象上午 9 點采集的數(shù)據(jù)查數(shù)據(jù)庫顯示record_time是凌晨 1 點日統(tǒng)計報表的日期邊界錯位總是少了 8 個小時的數(shù)據(jù)。原因JDBC 連接串里沒配serverTimezoneMySQL 驅(qū)動默認用 JVM 時區(qū)而 MySQL 服務(wù)端時區(qū)是 UTC二者差了 8 小時。寫入時LocalDateTime.now()用的是東八區(qū)時間存進 UTC 的 DATETIME 字段后語義就亂了。解決數(shù)據(jù)源 URL 加serverTimezoneAsia/Shanghai同時建表時統(tǒng)一用 DATETIME 類型不要混用 TIMESTAMP。TIMESTAMP 在 MySQL 中會做時區(qū)轉(zhuǎn)換DATETIME 不會混用會導(dǎo)致同一套代碼里不同表的時間錯位。還有一個隱藏坑LocalDateTime.now()取的是服務(wù)器本機時間如果服務(wù)器時區(qū)沒設(shè)對代碼里怎么改都沒用。Linux 下用timedatectl set-timezone Asia/Shanghai改時區(qū)改完重啟 Java 進程。5.4 定時任務(wù)重復(fù)執(zhí)行的玄學(xué)問題現(xiàn)象小時聚合表里同一小時的統(tǒng)計數(shù)據(jù)出現(xiàn)兩條總值翻倍。原因Spring 的Scheduled默認單線程串行一個任務(wù)沒執(zhí)行完下一個不會啟動這個設(shè)計本身不會導(dǎo)致重復(fù)。重復(fù)的來源一般是部署了多個后端實例每個實例都跑同一個定時任務(wù)或者開發(fā)環(huán)境跑了一個實例調(diào)試時又啟動了一個兩個進程同時執(zhí)行statLastHour()。解決分兩層處理。單實例場景在任務(wù)執(zhí)行前加一個 Redis 分布式鎖用setIfAbsent拿鎖拿不到就跳過本次執(zhí)行。多實例場景更穩(wěn)妥的做法是把所有定時任務(wù)集中到一個獨立模塊用 xxl-job 這類調(diào)度平臺統(tǒng)一調(diào)度。畢設(shè)階段沒必要上這么重Redis 鎖足夠。還有一個細節(jié)任務(wù)執(zhí)行時間要避開整點cron 寫成0 5 * * * ?而不是0 0 * * * ?給設(shè)備上報留出緩沖這個前面已經(jīng)踩過補充一句——如果上報數(shù)據(jù)是分鐘級聚合任務(wù)最好用0 10 * * * ?給足 10 分鐘延遲。5.5 Redis 未啟動導(dǎo)致登錄后黑匣子現(xiàn)象后端啟動了MySQL 也沒問題但一登錄就報Unable to connect to Redis或者登錄成功后請求其他接口又返回 401。原因token 存 Redis 做失效校驗Redis 沒啟動時登錄接口寫 token 失敗后續(xù)接口查 token 也失敗。畢設(shè)源碼包里 Redis 地址可能配的是遠端服務(wù)器本機連不上。解決先redis-cli ping確認 Redis 通不通通的話返回PONG。不通就檢查三件事Redis 服務(wù)是否已啟動Windows 下是 redis-server.exe 跑起來Linux 下是 systemctl start redis配置里的 host 和 port 是否指向本機Redis 是否設(shè)置了bind 127.0.0.1導(dǎo)致只能本機訪問。這里最坑的不是 Redis 連不上本身而是報錯信息不明顯——有時 token 校驗邏輯里 catch 了 Redis 連接異常直接返回“登錄過期”表現(xiàn)成用戶頻繁掉線實際全是 Redis 的鍋。排查習(xí)慣日志里搜RedisConnectionFailureException有就是 Redis 問題別在 token 邏輯里翻來覆去找。6. 答辯驗收前的一小時驗證清單與兩個進階優(yōu)化驗收前不要只驗證“能啟動、能登錄”那是最低標準。真正容易出問題的是數(shù)據(jù)鏈路采集 → 存儲 → 聚合 → 展示。我習(xí)慣按下面這張清單過一遍每條都要看到實際結(jié)果。驗證項操作預(yù)期結(jié)果設(shè)備上報調(diào)/api/collect/upload傳入合法設(shè)備編號返回 success數(shù)據(jù)庫energy_record新增一條重復(fù)上報同設(shè)備同時刻再調(diào)一次不新增記錄更新原記錄 value登錄鑒權(quán)不帶 token 訪問/api/admin/**返回 401JSON 格式統(tǒng)一定時聚合手動執(zhí)行statLastHour()觸發(fā)一次energy_hourly生成上一小時數(shù)據(jù)報表接口查跨 3 天的日報表categories 日期連續(xù)series 數(shù)值正確異常入?yún)鞑淮嬖诘?buildingId返回 code 500 或 業(yè)務(wù)錯誤碼不拋堆棧設(shè)備禁用把設(shè)備 status 置 0 再上報接口拒絕寫入接下來講兩個能讓你答辯加分的進階優(yōu)化。第一個是數(shù)據(jù)冪等寫一點升級設(shè)備上報接口的冪等判斷加一個唯一索引兜底也就是在energy_record表上建(device_id, record_time)的唯一索引。代碼里的冪等判斷在并發(fā)場景下存在競態(tài)兩個請求同時通過校驗同時執(zhí)行 insert還是會產(chǎn)生重復(fù)數(shù)據(jù)。唯一索引是數(shù)據(jù)庫層面的硬約束代碼判斷是軟約束兩層一起用才是穩(wěn)的。第二個優(yōu)化是報表緩存。日報表如果每次都實時查小時聚合表數(shù)據(jù)量大了之后依然會慢。我給自己的項目加了一層緩存查詢報表時先查 Rediskey 是report:daily:{buildingId}:{date}沒有命中再從 MySQL 查查到后寫回 Redis 并設(shè)置expire 24小時。報表接口的響應(yīng)時間從 300ms 降到 30ms前端畫圖明顯跟手。這個優(yōu)化能講清楚“緩存穿透、緩存雪崩、緩存一致性”三個概念答辯時被問到的概率不小。后端索引設(shè)計、時區(qū)配置、跨域攔截、token 過期處理這幾個點單獨拿一個出來都能做一個完整的“項目難點”講半天。我自己帶過的項目經(jīng)驗是后端代碼寫得好不好不看功能多不多看邊界處理得細不細——設(shè)備重復(fù)上報怎么辦、登錄過期怎么提示、報表慢怎么扛、數(shù)據(jù)庫時區(qū)怎么定。把這些邊界都想清楚畢設(shè)答辯離優(yōu)秀就不遠了。這套流程我每次拿到一個畢設(shè)后端都會按它走一遍能省掉大量無頭緒的翻車時間希望幫到你。本文還有配套的精品資源點擊獲取