簡(jiǎn)介校園水電費(fèi)管理微信小程序畢業(yè)設(shè)計(jì)源碼基于Java技術(shù)棧開(kāi)發(fā)適合計(jì)算機(jī)、電子信息工程、數(shù)學(xué)等專(zhuān)業(yè)正在準(zhǔn)備畢業(yè)設(shè)計(jì)或課程作業(yè)的學(xué)生。資源包共包含1072個(gè)文件既有Java后端服務(wù)、Vue管理端頁(yè)面、微信小程序wxml/wxss頁(yè)面、JavaScript交互邏輯也有JSON/XML配置文件、SQL數(shù)據(jù)庫(kù)腳本以及png、svg、jpg等前端圖標(biāo)與素材壓縮包大小16.56MB整體結(jié)構(gòu)緊湊便于分類(lèi)學(xué)習(xí)。項(xiàng)目代碼經(jīng)導(dǎo)師指導(dǎo)并調(diào)試通過(guò)自帶安裝運(yùn)行批處理與工程配置可快速啟動(dòng)項(xiàng)目便于理解水電費(fèi)賬單管理、用戶(hù)繳費(fèi)、用能統(tǒng)計(jì)等核心模塊的實(shí)現(xiàn)思路也能覆蓋課程設(shè)計(jì)和期末大作業(yè)的實(shí)戰(zhàn)場(chǎng)景。目前已有230人學(xué)習(xí)下載對(duì)于需要參考高分畢設(shè)項(xiàng)目、二次開(kāi)發(fā)或項(xiàng)目實(shí)戰(zhàn)練手的學(xué)生都是一份實(shí)用價(jià)值較高的完整源碼包可輔助快速完成畢業(yè)設(shè)計(jì)。1. 校園水電費(fèi)管理微信小程序源碼為什么我建議你把它當(dāng)作第一個(gè)「完整閉環(huán)」畢設(shè)項(xiàng)目每年畢設(shè)季總有人拿著「校園水電費(fèi)管理微信小程序源碼」這個(gè)標(biāo)題來(lái)找我問(wèn)的第一句通常是「這東西到底能不能跑、老師會(huì)不會(huì)一眼看出是網(wǎng)上扒的」。我的回答一般是這個(gè)題目比大多數(shù)圖書(shū)管理系統(tǒng)、商城系統(tǒng)都更能體現(xiàn)一個(gè)完整業(yè)務(wù)閉環(huán)——它同時(shí)涉及微信登錄、狀態(tài)機(jī)賬單從待繳到已繳、費(fèi)用計(jì)算規(guī)則、角色權(quán)限學(xué)生和管理員、甚至支付回調(diào)。我做過(guò)的模擬項(xiàng)目X功能就是抄表、計(jì)費(fèi)、催繳、繳費(fèi)、臺(tái)賬查詢(xún)五件事前后端加起來(lái)三千多行代碼卻把畢設(shè)答辯里「你講講這個(gè)復(fù)雜業(yè)務(wù)怎么設(shè)計(jì)的」這類(lèi)問(wèn)題全堵住了。如果你正在找能落地、邏輯不單薄、工作量看得見(jiàn)的項(xiàng)目這確實(shí)是個(gè)值得投入的方向。2. 把這個(gè)源碼跑起來(lái)之前技術(shù)選型和項(xiàng)目骨架2.1 為什么小程序端用原生、后端用 Spring Boot 是校園場(chǎng)景最不容易翻車(chē)的組合常見(jiàn)做法是前端用微信小程序原生框架后端用 Spring Boot 加 MySQL。有人會(huì)覺(jué)得原生小程序?qū)懫饋?lái)不如 uni-app 順手但校園水電費(fèi)這種場(chǎng)景頁(yè)面主要是列表、表單、賬單詳情和圖表原生小程序完全夠用而且少了 H5 轉(zhuǎn)小程序那一層兼容問(wèn)題。后端選 Spring Boot 的原因也很直接你隨便找一個(gè)室友給他看application.yml里的數(shù)據(jù)庫(kù)賬號(hào)和端口配置他都能幫你把環(huán)境搭起來(lái)而如果選了 Node.js 或 Go很多同學(xué)對(duì)依賴(lài)管理不熟春節(jié)期間環(huán)境裝不上就卡住了。我一般會(huì)建議后端用 MVC 分層controller 只做參數(shù)接收和返回service 寫(xiě)計(jì)費(fèi)邏輯mapper 操作數(shù)據(jù)庫(kù)。這樣做的好處是如果你從網(wǎng)上找到的這份校園水電費(fèi)管理微信小程序源碼里 service 層寫(xiě)得特別薄、所有 SQL 都堆在 controller 里你一眼就能看出來(lái)這項(xiàng)目質(zhì)量不高不值得當(dāng)?shù)鬃痈摹?.2 拿到一份源碼后先看哪幾個(gè)目錄和文件我拿到一份校園水電費(fèi)管理微信小程序源碼第一件事不是急著放進(jìn)微信開(kāi)發(fā)者工具而是先掃目錄結(jié)構(gòu)。正常情況下應(yīng)該是這樣wechat-mini-program/ ├── pages/ │ ├── login/ # 登錄頁(yè) │ ├── index/ # 首頁(yè)我的房間、本月用量 │ ├── bill/ # 賬單列表與詳情 │ ├── payment/ # 收銀臺(tái) │ └── admin/ # 管理員抄表錄入、價(jià)格設(shè)置 ├── utils/ │ ├── request.js # 封裝 wx.request統(tǒng)一帶 token │ └── format.js # 金額、日期格式化 ├── app.js ├── app.json └── project.config.json同時(shí)后端源碼應(yīng)該是這種姿勢(shì)backend/ ├── src/main/java/com/xxx/ │ ├── controller/ │ ├── service/ │ ├── mapper/ │ ├── entity/ │ └── config/ ├── src/main/resources/ │ ├── mapper/*.xml # SQL │ └── application.yml └── pom.xml先看application.yml里的數(shù)據(jù)庫(kù)連接是不是寫(xiě)死的、有沒(méi)有用jdbc:mysql://localhost:3306/dormitory這種可改的寫(xiě)法——去平臺(tái)化的穩(wěn)定配置是你能不能本地跑起來(lái)的前提。再看app.js里的globalData.apiBaseUrl小程序端所有請(qǐng)求都走這個(gè)公共地址本地調(diào)試時(shí)改成http://localhost:8080。如果一份源碼這兩個(gè)文件都寫(xiě)死了某個(gè)公網(wǎng)地址我勸你立刻關(guān)掉因?yàn)槟悴恢浪B的是誰(shuí)的數(shù)據(jù)庫(kù)。2.3 最小啟動(dòng)步驟兩個(gè)小時(shí)內(nèi)在本地把它跑通我按自己跑通某水電費(fèi)項(xiàng)目源碼的順序給你一套可復(fù)現(xiàn)的步驟# 1. 創(chuàng)建數(shù)據(jù)庫(kù)并導(dǎo)入 mysql -u root -p -e CREATE DATABASE dormitory DEFAULT CHARSET utf8mb4; mysql -u root -p dormitory sql/init.sql # 2. 修改后端配置 cd backend vim src/main/resources/application.yml # 改 spring.datasource.username / password / url # 3. 啟動(dòng)后端 mvn spring-boot:run # 4. 確認(rèn)后端起來(lái) curl http://localhost:8080/api/health關(guān)鍵參數(shù)就三個(gè)數(shù)據(jù)庫(kù)名、端口默認(rèn) 8080微信開(kāi)發(fā)者工具不校驗(yàn)這個(gè)、以及小程序project.config.json里的appid測(cè)試號(hào)可以填touristappid。跑起來(lái)后用微信開(kāi)發(fā)者工具打開(kāi)小程序根目錄在utils/request.js里把 baseURL 指到http://localhost:8080然后在模擬器里點(diǎn)登錄——能拿到 openid 且首頁(yè)不白屏說(shuō)明這套源碼的基礎(chǔ)鏈路是通的。# 如果登錄報(bào)錯(cuò)先看后端日志有沒(méi)有這句話 # code2session err → 說(shuō)明 appid 或 secret 不對(duì)注意真機(jī)預(yù)覽時(shí)localhost指向的是你手機(jī)自己不是電腦。要做真機(jī)聯(lián)調(diào)把 baseURL 改成電腦的局域網(wǎng) IP并且微信公眾平臺(tái)里要把該 IP 加入 request 合法域名調(diào)試階段可勾選「不校驗(yàn)合法域名」。3. 別急著寫(xiě)界面計(jì)費(fèi)模型和數(shù)據(jù)庫(kù)表設(shè)計(jì)決定你答辯時(shí)有沒(méi)有底氣3.1 三張核心表房間表、抄表記錄表、賬單表我在做某跨平臺(tái)系統(tǒng)的水電費(fèi)模塊時(shí)第一版表結(jié)構(gòu)設(shè)計(jì)很簡(jiǎn)單——一張user表、一張record表結(jié)果項(xiàng)目走到一半就卡住了損耗分?jǐn)倹](méi)法算、階梯計(jì)費(fèi)對(duì)不上、同一個(gè)房間一個(gè)月產(chǎn)生了兩條賬單。后來(lái)重構(gòu)成三張表加一張日志表才順過(guò)來(lái)。CREATE TABLE room ( id int NOT NULL AUTO_INCREMENT, building varchar(32) NOT NULL COMMENT 樓棟號(hào), room_number varchar(32) NOT NULL COMMENT 房間號(hào), capacity int DEFAULT 4 COMMENT 標(biāo)準(zhǔn)入住人數(shù), area decimal(6,2) DEFAULT 0 COMMENT 面積用于分?jǐn)? PRIMARY KEY (id), UNIQUE KEY uk_building_room (building,room_number) ) ENGINEInnoDB COMMENT房間表; CREATE TABLE meter_record ( id bigint NOT NULL AUTO_INCREMENT, room_id int NOT NULL, period char(7) NOT NULL COMMENT 賬期如 2025-06, type tinyint NOT NULL COMMENT 1電 2水, last_value decimal(10,2) NOT NULL COMMENT 上次表底, current_value decimal(10,2) NOT NULL COMMENT 本次表底, read_time datetime NOT NULL, operator_id bigint DEFAULT NULL COMMENT 抄表管理員, PRIMARY KEY (id), UNIQUE KEY uk_room_period_type (room_id,period,type) ) ENGINEInnoDB COMMENT抄表記錄表; CREATE TABLE bill ( id bigint NOT NULL AUTO_INCREMENT, room_id int NOT NULL, period char(7) NOT NULL, bill_no varchar(40) NOT NULL, total_amount int NOT NULL COMMENT 總金額單位分, status tinyint NOT NULL DEFAULT 0 COMMENT 0待繳 1已繳 2作廢, created_at datetime DEFAULT CURRENT_TIMESTAMP, paid_at datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_bill_no (bill_no), KEY idx_room_period (room_id,period) ) ENGINEInnoDB COMMENT賬單表;這里最值得你注意的就是UNIQUE KEY uk_room_period_type。沒(méi)有這個(gè)唯一約束兩個(gè)管理員同一天對(duì)同一房間重復(fù)錄入抄表數(shù)系統(tǒng)就會(huì)生成兩張賬單學(xué)生對(duì)賬時(shí)必然翻車(chē)。我在模擬項(xiàng)目X里就被這個(gè)坑絆過(guò)一次后來(lái)加了唯一索引重復(fù)錄入直接報(bào)錯(cuò)才把數(shù)據(jù)可靠性救回來(lái)。3.2 階梯計(jì)費(fèi)和損耗分?jǐn)們蓚€(gè)必調(diào)的參數(shù)水電費(fèi)看著簡(jiǎn)單真去算時(shí)發(fā)現(xiàn)全是細(xì)節(jié)。以電費(fèi)為例校園宿舍常見(jiàn)的規(guī)則是每月每房間基礎(chǔ)額度 20 度超過(guò)部分按階梯計(jì)價(jià)。我把計(jì)費(fèi)邏輯寫(xiě)成一個(gè)獨(dú)立 service 方法public int calcElectricFee(BigDecimal usedAmount, FeeRate rate) { // 單位分 int total 0; BigDecimal remain usedAmount; for (LadderItem item : rate.getLadderList()) { if (remain.compareTo(item.getThreshold()) 0) { total item.getThreshold().multiply(item.getPrice()) .setScale(0, RoundingMode.HALF_UP).intValue(); remain remain.subtract(item.getThreshold()); } else { total remain.multiply(item.getPrice()) .setScale(0, RoundingMode.HALF_UP).intValue(); break; } } return total; }計(jì)費(fèi)參數(shù)我建議做成數(shù)據(jù)庫(kù)表而不是寫(xiě)死在代碼里字段包括ladder_type電/水、threshold檔位閾值、price單價(jià)、effective_date生效日期。理由很實(shí)際你答辯時(shí)老師大概率會(huì)問(wèn)「如果明年電費(fèi)調(diào)整了怎么辦」你直接演示改數(shù)據(jù)庫(kù)不改代碼比解釋「我硬編碼了」有說(shuō)服力得多。損耗分?jǐn)偸橇硪粋€(gè)容易做錯(cuò)的地方。我的方案是公攤電 總表數(shù) - 各分表數(shù)之和然后按每個(gè)房間用電量占比分?jǐn)?。注意這里要用「用電量占比」而不是「按人頭均攤」因?yàn)橛秒姸嗟姆块g多攤、用電少的少攤學(xué)生才不會(huì)有意見(jiàn)。公式是room_share public_loss * room_usage / total_usage這個(gè)除法會(huì)產(chǎn)生除不盡的小數(shù)所以最后要保證sum(room_share) public_loss做法是最后一個(gè)房間的份額用總損耗減去前面所有房間的份額而不是自己再算一遍。3.3 金額字段用「分」還是「元」這個(gè)選擇影響整個(gè)支付模塊新手拿到源碼后最喜歡把total_amount設(shè)計(jì)成decimal(10,2)存元因?yàn)?SQL 里看起來(lái)直觀。但只要你接支付哪怕只是模擬支付我強(qiáng)烈建議你存「分」理由有兩個(gè)一是金額計(jì)算過(guò)程全是乘法除法用元會(huì)出現(xiàn)0.1 * 3 0.30000000000000004這種浮點(diǎn)誤差用整型分永遠(yuǎn)不會(huì)二是支付回調(diào)里平臺(tái)返回的金額單位就是分你后端直接比對(duì)少做一次單位轉(zhuǎn)換就少一個(gè)出錯(cuò)點(diǎn)。上面的bill表里total_amount int NOT NULL COMMENT 總金額單位分就是這個(gè)用意。展示給用戶(hù)看時(shí)再做格式化(total_amount / 100).toFixed(2)。這條習(xí)慣我不只在畢設(shè)項(xiàng)目里用后來(lái)在公司做計(jì)費(fèi)系統(tǒng)也是這個(gè)規(guī)矩。4. 跑通一條完整鏈路登錄、綁定房間、抄表出賬、模擬支付4.1 從 wx.login 到 openid這條身份識(shí)別鏈路只有一種正確寫(xiě)法校園水電費(fèi)小程序的登錄本質(zhì)上不是「用戶(hù)名密碼登錄」而是通過(guò)微信的wx.login拿到臨時(shí) code再發(fā)給后端換取 openid。前端關(guān)鍵代碼// utils/request.js 中的登錄封裝 login() { return new Promise((resolve, reject) { wx.login({ success: (res) { wx.request({ url: ${this.baseUrl}/api/login, method: POST, data: { code: res.code }, success: (res2) { const { token } res2.data.data wx.setStorageSync(token, token) resolve(token) }, fail: reject }) } }) }) }后端對(duì)應(yīng)處理邏輯PostMapping(/login) public Result login(RequestBody LoginReq req) { // 1. 調(diào)用微信 jscode2session 接口用 code 換 openid String openid wechatClient.code2Session(req.getCode()); // 2. 查 user 表不存在則創(chuàng)建新用戶(hù) User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); userMapper.insert(user); } // 3. 生成自己的 tokenUUID 即可并返回 String token UUID.randomUUID().toString().replace(-, ); userMapper.saveToken(user.getId(), token); return Result.ok(token); }這里有一個(gè)代碼邏輯要注意jscode2session是后端去調(diào)微信接口不是你前端直接調(diào)。原因是這個(gè)接口需要appSecret而appSecret放在小程序前端就等于公開(kāi)了任何人都能冒充你的后端。很多畢設(shè)源碼圖省事讓前端直接拿 code 換 openid這種代碼答辯時(shí)被老師追問(wèn)「密鑰安全怎么保證」就會(huì)卡殼。你自己改的時(shí)候務(wù)必把a(bǔ)ppSecret留在后端配置文件里。4.2 綁定房間與身份校驗(yàn)一個(gè)「入住碼」就能解決的取舍登錄只解決了「你是誰(shuí)微信號(hào)」還沒(méi)解決「你住哪個(gè)房間」。校園場(chǎng)景里學(xué)生和房間的綁定不能亂來(lái)——如果隨便填個(gè)房間號(hào)就綁成功那任何人都能看別人的賬單。常見(jiàn)做法有兩種預(yù)置名單校驗(yàn)或者入住碼綁定。我更喜歡入住碼方案因?yàn)檫壿嫼?jiǎn)單且演示效果好管理員在后臺(tái)給某房間生成一個(gè) 6 位入住碼學(xué)生在小程序里輸入房間號(hào)和入住碼完成綁定。后端代碼PostMapping(/bindRoom) public Result bindRoom(RequestParam String roomNo, RequestParam String joinCode, RequestParam Long userId) { Room room roomMapper.selectByRoomNo(roomNo); if (room null || !room.getJoinCode().equals(joinCode)) { return Result.fail(房間號(hào)或入住碼錯(cuò)誤); } // 解綁舊綁定再綁新房 userMapper.updateRoom(userId, room.getId()); return Result.ok(); }這個(gè)方案比「上傳名單核對(duì)學(xué)號(hào)姓名」少一步導(dǎo)入操作也比「不校驗(yàn)直接綁」顯得有設(shè)計(jì)感。你在答辯時(shí)可以說(shuō)入住碼由管理員生成離校后解綁即作廢能防止學(xué)生串房。4.3 沒(méi)有商戶(hù)號(hào)也能演示支付模擬支付回調(diào)的正確姿勢(shì)校園開(kāi)發(fā)者最現(xiàn)實(shí)的問(wèn)題個(gè)人小程序沒(méi)有微信支付權(quán)限拿不到商戶(hù)號(hào)。很多人的處理辦法是把支付按鈕做成「假裝支付成功」賬單狀態(tài)直接改成已繳。這個(gè)做法在答辯時(shí)只要老師細(xì)看就會(huì)覺(jué)得項(xiàng)目「黑匣子」——你解釋不清錢(qián)去哪了。我的建議是把支付流程做成兩層模擬支付一層真實(shí)微信支付留好接口。后端收銀臺(tái)代碼這樣寫(xiě)// 發(fā)起支付創(chuàng)建支付單狀態(tài)為待支付 public PayOrder createPayOrder(Long billId) { PayOrder order new PayOrder(); order.setBillId(billId); order.setOrderNo(generateOrderNo()); order.setStatus(WAIT_PAY); payOrderMapper.insert(order); return order; } // 模擬支付回調(diào)不調(diào)微信直接標(biāo)記支付成功 PostMapping(/mockPayNotify) public Result mockPayNotify(RequestParam String orderNo) { PayOrder order payOrderMapper.selectByOrderNo(orderNo); if (order null || !WAIT_PAY.equals(order.getStatus())) { return Result.fail(訂單不存在或已處理); } // 冪等重復(fù)回調(diào)不重復(fù)修改 order.setStatus(PAID); order.setPaidAt(new Date()); payOrderMapper.update(order); // 賬單同步更新 billMapper.markPaid(order.getBillId()); return Result.ok(); }真實(shí)微信支付時(shí)你只需要把mockPayNotify替換成微信的支付回調(diào)地址并把payOrderMapper里的狀態(tài)更新邏輯換成微信支付結(jié)果驗(yàn)簽其他部分完全不用動(dòng)。這個(gè)「接口留白」的做法比把代碼寫(xiě)死強(qiáng)得多。5. 校園水電費(fèi)系統(tǒng)最常見(jiàn)的 5 個(gè)坑現(xiàn)象、原因、解決5.1 換設(shè)備登錄后看到的是別人的賬單現(xiàn)象學(xué)生換手機(jī)或者重新授權(quán)登錄后首頁(yè)顯示的不是自己房間的賬單而是另一個(gè)房間的數(shù)據(jù)。原因user表里沒(méi)有把openid和room_id的對(duì)應(yīng)關(guān)系存好。很多源碼是「登錄時(shí)創(chuàng)建一個(gè)新用戶(hù)綁定房間時(shí)再創(chuàng)建一個(gè)新用戶(hù)」導(dǎo)致兩次登錄生成兩條記錄綁定房間只寫(xiě)到了第二條記錄上。解決user表設(shè)計(jì)為openid唯一綁定房間只做UPDATE user SET room_idxx WHERE openidyy不要走「新用戶(hù)插入」邏輯。5.2 階梯電費(fèi)算出一個(gè)無(wú)限循環(huán)小數(shù)現(xiàn)象賬單金額莫名其妙多出一分錢(qián)或者階梯計(jì)算后金額對(duì)不上。原因用double或float存儲(chǔ)并計(jì)算單價(jià)二進(jìn)制無(wú)法精確表示 0.1。解決金額全部用分int存儲(chǔ)Java 里用BigDecimal計(jì)算最后setScale(0, HALF_UP)。水電表底數(shù)可以保留兩位小數(shù)但只作為表底存儲(chǔ)單價(jià)乘完的結(jié)果立刻轉(zhuǎn)成整數(shù)分。5.3 賬期和費(fèi)率生效日期錯(cuò)位現(xiàn)象6 月的賬單用了 7 月 1 日才生效的新電價(jià)。原因生成賬單時(shí)代碼里直接查SELECT * FROM fee_rate取第一條而這條記錄恰好是后來(lái)修改過(guò)的。解決fee_rate表增加effective_date字段生成賬單時(shí)按WHERE effective_date 賬期最后一天 ORDER BY effective_date DESC LIMIT 1取費(fèi)率。賬期是 6 月就用 6 月底之前最后生效的費(fèi)率而不是當(dāng)前最新費(fèi)率。5.4 學(xué)生雙擊支付按鈕生成了兩張重復(fù)賬單現(xiàn)象學(xué)生點(diǎn)了一次繳費(fèi)沒(méi)反應(yīng)又點(diǎn)了一次結(jié)果支付列表里出現(xiàn)兩條一模一樣的賬單。原因支付創(chuàng)建接口沒(méi)有做冪等控制兩次請(qǐng)求各生成一個(gè)訂單。解決兩個(gè)層面兜底。數(shù)據(jù)庫(kù)層面pay_order表的bill_id加唯一索引同一個(gè)賬單只能有一條未支付訂單。代碼層面創(chuàng)建訂單前先查SELECT * FROM pay_order WHERE bill_id ? AND status WAIT_PAY存在就直接返回舊訂單號(hào)。5.5 本地能跑真機(jī)一調(diào)用就連接失敗現(xiàn)象在微信開(kāi)發(fā)者工具里一切正常換成手機(jī)預(yù)覽就請(qǐng)求失敗。原因開(kāi)發(fā)者工具里localhost能通是因?yàn)楣ぞ吆碗娔X在同一臺(tái)機(jī)器上真機(jī)上localhost指向手機(jī)自身請(qǐng)求自然到達(dá)不了電腦。解決調(diào)試階段在request.js里把 baseURL 換成電腦的局域網(wǎng) IP同時(shí)微信開(kāi)發(fā)者工具勾選「不校驗(yàn)合法域名」。如果換了 IP 仍不行檢查 Windows 防火墻有沒(méi)有放行 8080 端口。這個(gè)坑我?guī)缀趺孔鲆粋€(gè)項(xiàng)目都要栽一次所以現(xiàn)在已經(jīng)養(yǎng)成習(xí)慣項(xiàng)目根目錄放一個(gè)config.js第一行就是環(huán)境注釋。6. 讓這個(gè)項(xiàng)目從「能跑」變成「能打」批量抄表和欠費(fèi)提醒6.1 管理端抄表脫離手工錄入Excel 批量導(dǎo)入怎么做畢設(shè)里演示抄表逐條手輸 6 個(gè)房間還能忍輸 60 個(gè)房間時(shí)演示就有點(diǎn)尷尬。給管理端加一個(gè)批量導(dǎo)入導(dǎo)出的功能屬于性?xún)r(jià)比很高的進(jìn)階點(diǎn)。常見(jiàn)做法是后端用 Apache POI 讀取 Excel核心邏輯如下public ImportResult importExcel(MultipartFile file) { Workbook wb WorkbookFactory.create(file.getInputStream()); Sheet sheet wb.getSheetAt(0); ListMeterRecord list new ArrayList(); for (Row row : sheet) { if (row.getRowNum() 0) continue; // 跳過(guò)表頭 String building row.getCell(0).getStringCellValue(); String roomNo row.getCell(1).getStringCellValue(); BigDecimal currentValue BigDecimal.valueOf(row.getCell(2).getNumericCellValue()); // 查找房間 id沒(méi)有則報(bào)錯(cuò) Room room roomMapper.selectByBuildingAndNo(building, roomNo); if (room null) { importResult.addError(row.getRowNum(), 房間不存在); continue; } list.add(buildRecord(room.getId(), currentValue)); } // 批量插入依賴(lài)唯一索引跳過(guò)重復(fù)賬期 meterRecordMapper.batchInsertIgnore(list); return importResult; }參數(shù)說(shuō)明batchInsertIgnore對(duì)應(yīng) SQL 里的INSERT IGNORE INTO配合表結(jié)構(gòu)里uk_room_period_type唯一索引重復(fù)賬期會(huì)靜默跳過(guò)而不是報(bào)錯(cuò)中斷。在 Excel 表里增加「上次表底」列并在導(dǎo)入時(shí)和庫(kù)里比對(duì)如果本次表底小于上次表底就判定為錄入異?！@是實(shí)際使用中很容易被忽略的校驗(yàn)。6.2 欠費(fèi)主動(dòng)推送把消息訂閱加進(jìn)來(lái)賬單生成后沒(méi)人看是常態(tài)要做成一套能用的欠費(fèi)提醒系統(tǒng)可以在用戶(hù)端加一個(gè)「訂閱消息」入口。微信小程序的訂閱消息需要用戶(hù)主動(dòng)點(diǎn)擊授權(quán)所以常規(guī)做法是用戶(hù)繳費(fèi)成功后彈出「允許發(fā)送賬單提醒」然后后端在每月出賬后調(diào)用subscribeMessage.send推送模板消息。這里有個(gè)反直覺(jué)點(diǎn)微信的訂閱消息是「一次性」的用戶(hù)授權(quán)一次只能收到一條推送不是永久的。所以你的授權(quán)入口要設(shè)計(jì)在「繳費(fèi)成功」這個(gè)用戶(hù)粘性最高的環(huán)節(jié)讓他每次繳費(fèi)都順便訂閱下個(gè)月的賬單提醒而不是在登錄時(shí)誘導(dǎo)授權(quán)。6.3 月度賬單統(tǒng)計(jì)一條 SQL 看出整個(gè)系統(tǒng)有沒(méi)有做對(duì)你寫(xiě)完計(jì)費(fèi)邏輯后可以用一條 SQL 自檢SELECT COUNT(*) AS total_bills, SUM(CASE WHEN status 1 THEN 1 ELSE 0 END) AS paid_bills, ROUND(SUM(CASE WHEN status 1 THEN 1 ELSE 0 END) / COUNT(*), 4) AS paid_rate, SUM(total_amount) AS should_receive, SUM(CASE WHEN status 1 THEN total_amount ELSE 0 END) AS real_received FROM bill WHERE period 2025-06;這條 SQL 能查出當(dāng)月應(yīng)收、實(shí)收、繳費(fèi)率三個(gè)指標(biāo)是你在答辯時(shí)展示「我做的是完整系統(tǒng)」最直接的證據(jù)。如果實(shí)收金額對(duì)不上那就是前面 5.2 的精度問(wèn)題沒(méi)處理干凈。我大四那年做某圖像處理 Demo完全跳過(guò)了計(jì)費(fèi)規(guī)則直接寫(xiě)界面結(jié)果導(dǎo)師一句「你這費(fèi)用用元算出現(xiàn)浮點(diǎn)誤差怎么辦」就把我問(wèn)住了。后來(lái)重做了這套水電費(fèi)系統(tǒng)把費(fèi)率表、抄表記錄、賬單關(guān)系想清楚才真正弄明白業(yè)務(wù)系統(tǒng)應(yīng)該怎么搭。這個(gè)方向值得你投入不是因?yàn)槟苁∈露亲鐾暌槐槟銓?duì)「登錄—業(yè)務(wù)—支付—對(duì)賬」整條鏈路的理解會(huì)徹底不一樣希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取