最近不少同學(xué)來(lái)聊畢業(yè)設(shè)計(jì)選題發(fā)現(xiàn)今年咨詢(xún)智慧物業(yè)類(lèi)題目的特別多尤其是“SpringBoot 微信小程序”這個(gè)組合。這類(lèi)題目確實(shí)值得認(rèn)真做一方面業(yè)務(wù)場(chǎng)景貼近真實(shí)生活需求清晰好展開(kāi)另一方面技術(shù)棧是國(guó)內(nèi)Java后端的主流行情從框架選型到部署上線都有大量現(xiàn)成經(jīng)驗(yàn)可以參考答辯時(shí)完全有東西可講。今天我就拿一個(gè)非常典型的題目——醫(yī)院新家屬小區(qū)物業(yè)綜合管理系統(tǒng)——來(lái)完整拆一遍。從需求分析、技術(shù)選型、數(shù)據(jù)庫(kù)設(shè)計(jì)到核心功能實(shí)現(xiàn)最后再聊部署踩坑和答辯準(zhǔn)備整個(gè)過(guò)程都講透希望能給你一條可以直接落地的路線圖。1. 項(xiàng)目背景與需求拆解醫(yī)院家屬院區(qū)的物業(yè)痛點(diǎn)到底在哪1.1 醫(yī)院家屬院區(qū)有什么特殊性這類(lèi)家屬院區(qū)和普通商品房小區(qū)最大的區(qū)別在于住戶(hù)構(gòu)成極其復(fù)雜。有在職醫(yī)生、退休職工、行政人員、實(shí)習(xí)醫(yī)生還有大量租戶(hù)。不同人群對(duì)物業(yè)服務(wù)的訴求差異非常大醫(yī)生倒班頻繁作息時(shí)間跟普通住戶(hù)完全錯(cuò)開(kāi)早上五六點(diǎn)下班回家凌晨?jī)扇c(diǎn)出門(mén)急診是常態(tài)傳統(tǒng)物業(yè)那種“工作日窗口繳費(fèi)、電話報(bào)修、公告欄貼通知”的模式在這里基本失效退休職工對(duì)上門(mén)服務(wù)、人工咨詢(xún)的依賴(lài)度高更習(xí)慣用簡(jiǎn)單的交互完成操作租戶(hù)的身份信息、車(chē)位綁定、繳費(fèi)歸屬經(jīng)常變動(dòng)無(wú)固定住戶(hù)的溝通成本很高。另外醫(yī)院家屬院區(qū)通常會(huì)面臨一個(gè)所有“核心地段老小區(qū)”都有的問(wèn)題——停車(chē)資源緊張。進(jìn)出通道窄、車(chē)位少、訪客車(chē)輛多如果還用手工登記的方式管理高峰期排隊(duì)很容易堵住急救通道。這類(lèi)場(chǎng)景下的物業(yè)系統(tǒng)本質(zhì)上不是做一個(gè)信息管理后臺(tái)而是要解決“一老一小一特殊排班人群”的全天候服務(wù)觸達(dá)問(wèn)題。1.2 核心需求到底有哪些從實(shí)際場(chǎng)景里梳理一下這個(gè)系統(tǒng)涉及的核心角色有四類(lèi)業(yè)主、租戶(hù)、物業(yè)人員含維修工、管理員。每個(gè)角色的訴求差異很大不能堆在一個(gè)頁(yè)面里解決所有問(wèn)題。業(yè)主最關(guān)心的是報(bào)修進(jìn)度、繳費(fèi)到期時(shí)間、公告通知和訪客放行。租戶(hù)在業(yè)主的基礎(chǔ)需求之上還多一個(gè)“退租時(shí)繳費(fèi)歸屬怎么算、維修責(zé)任怎么劃分”的問(wèn)題。物業(yè)人員需要的是一個(gè)移動(dòng)端工單處理入口修完現(xiàn)場(chǎng)直接拍照回傳、更新?tīng)顟B(tài)不用跑回辦公室再補(bǔ)錄一遍。管理員則希望有一個(gè)數(shù)據(jù)看板能一眼看清楚今天有幾個(gè)待處理工單、本月物業(yè)費(fèi)收繳率多少、哪些樓棟報(bào)修頻率最高、哪個(gè)維修師傅的工單積壓最長(zhǎng)。把這些訴求歸納成功能模塊就是八大塊用戶(hù)認(rèn)證含微信登錄、房屋管理、報(bào)修工單、賬單繳費(fèi)、公告通知、訪客管理、投訴建議、停車(chē)管理。后續(xù)所有的數(shù)據(jù)庫(kù)建模、后端接口設(shè)計(jì)、小程序頁(yè)面規(guī)劃都是圍繞這八塊展開(kāi)的。2. 技術(shù)方案選型SpringBoot加微信小程序?yàn)槭裁词欠€(wěn)妥的組合2.1 后端框架選型的理由后端選擇SpringBoot其實(shí)不需要糾結(jié)太多。首先是生態(tài)成熟。SpringBoot解決了傳統(tǒng)SSM框架里大量繁瑣的XML配置問(wèn)題內(nèi)嵌Tomcat后打包成可執(zhí)行Jar就能直接部署運(yùn)行。對(duì)本科畢業(yè)設(shè)計(jì)來(lái)說(shuō)從開(kāi)發(fā)到部署的學(xué)習(xí)成本已經(jīng)壓到很低了。其次是社區(qū)資料密度極高。任何“SpringBoot MyBatis-Plus 微信小程序”相關(guān)問(wèn)題基本都能搜索到現(xiàn)成答案和解決方案。畢業(yè)設(shè)計(jì)周期一共就那么幾個(gè)月你需要的是確定性和可復(fù)現(xiàn)性而不是在冷門(mén)技術(shù)里吭哧吭哧踩坑。第三是和學(xué)校課程體系銜接自然。很多同學(xué)之前學(xué)過(guò)Java Web課程SpringBoot和Servlet、SSM框架是同一條技術(shù)脈絡(luò)的延續(xù)學(xué)習(xí)曲線非常平緩。答辯被問(wèn)到框架原理時(shí)也能講清楚自動(dòng)裝配、內(nèi)嵌容器這些基礎(chǔ)概念。數(shù)據(jù)庫(kù)我推薦MySQL 8.x。對(duì)于小區(qū)物業(yè)這種體量的系統(tǒng)住戶(hù)可能就幾百戶(hù)每天的工單、賬單、公告并發(fā)量非常有限MySQL在功能、事務(wù)支持、索引優(yōu)化這些方面都完全夠用而且這些都是面試和答辯常考的知識(shí)點(diǎn)。緩存我加了Redis主要用來(lái)緩存微信會(huì)話信息、首頁(yè)熱點(diǎn)公告和統(tǒng)計(jì)數(shù)據(jù)。不指望它扛高并發(fā)但能讓你在答辯時(shí)輕松講出“本地緩存分布式緩存分層”的思想。ORM選型方面MyBatis-Plus比原生MyBatis更省心。BaseMapper內(nèi)置了單表的增刪改查邏輯條件構(gòu)造器寫(xiě)動(dòng)態(tài)查詢(xún)也簡(jiǎn)潔能減少大把樣板代碼。配合Lombok簡(jiǎn)化實(shí)體類(lèi)的Getter/Setter后端代碼量能控制到很小。這里有一句重要提醒MyBatis-Plus的邏輯刪除和樂(lè)觀鎖插件最好在一開(kāi)始就配置好不然后期表字段改動(dòng)和并發(fā)更新會(huì)非常痛苦。2.2 小程序端怎么選型前后端如何交互前端選微信小程序的原因很直接醫(yī)院家屬區(qū)的住戶(hù)基本都在微信生態(tài)里小程序免安裝、即點(diǎn)即用、打開(kāi)就是最新的服務(wù)頁(yè)面推廣和使用成本幾乎為零。而且小程序官方提供的API非常貼合國(guó)內(nèi)業(yè)務(wù)場(chǎng)景登錄態(tài)獲取、手機(jī)號(hào)授權(quán)、訂閱消息推送這些能力都是現(xiàn)成的。至于用原生小程序還是uni-app我的建議是畢設(shè)階段用原生小程序。uni-app雖然能一套代碼多端復(fù)用但調(diào)試鏈路更長(zhǎng)部分原生組件存在兼容差異。原生小程序用WXML、WXSS和JavaScript跟普通前端開(kāi)發(fā)差異不大學(xué)起來(lái)快遇到問(wèn)題也更容易在官方社區(qū)找到答案。前后端交互統(tǒng)一走JSON over HTTP接口設(shè)計(jì)遵循RESTful風(fēng)格。比如POST /api/user/login 微信登錄GET /api/repair/list 報(bào)修工單列表POST /api/repair 創(chuàng)建報(bào)修工單PUT /api/repair/{id}/status 更新工單狀態(tài)POST /api/payment 發(fā)起繳費(fèi)訂單這里要強(qiáng)調(diào)一個(gè)架構(gòu)原則小程序端絕對(duì)不能直接訪問(wèn)數(shù)據(jù)庫(kù)所有數(shù)據(jù)交互都必須經(jīng)過(guò)后端的RESTful接口。這既是項(xiàng)目分層的核心體現(xiàn)也是答辯時(shí)能清晰講出來(lái)的架構(gòu)亮點(diǎn)。如果你在論文里畫(huà)一張“小程序端 → 后端Controller → Service → Mapper → 數(shù)據(jù)庫(kù)”的分層架構(gòu)圖評(píng)審老師一看就知道你是懂設(shè)計(jì)的。3. 數(shù)據(jù)庫(kù)設(shè)計(jì)這個(gè)環(huán)節(jié)真正決定項(xiàng)目成敗3.1 整體建模思路圍繞“人-房-服務(wù)”建模數(shù)據(jù)庫(kù)設(shè)計(jì)是這類(lèi)項(xiàng)目里最容易被低估的環(huán)節(jié)。很多同學(xué)上來(lái)就建表寫(xiě)代碼結(jié)果做到一半發(fā)現(xiàn)報(bào)修單關(guān)聯(lián)不上房屋、賬單沒(méi)有歷史狀態(tài)記錄、租戶(hù)更換后關(guān)聯(lián)關(guān)系全亂套這時(shí)候再改表結(jié)構(gòu)痛苦程度堪比重新做一遍。我采用的核心設(shè)計(jì)思想是圍繞“人-房-服務(wù)”三條主線來(lái)建模。人這條線比較簡(jiǎn)單就是一張用戶(hù)表包含業(yè)主、租戶(hù)、物業(yè)人員、管理員通過(guò)role字段區(qū)分。房這條線小區(qū)房屋作為物理單元向下派生樓棟表、車(chē)位表向上關(guān)聯(lián)業(yè)主和租戶(hù)。服務(wù)這條線報(bào)修、繳費(fèi)、公告、訪客、投訴都是依附于“某個(gè)人在某個(gè)房屋上的事件記錄”每條業(yè)務(wù)記錄都必須能追溯到人和房。在這個(gè)基礎(chǔ)上我給自己定了三條鐵律所有業(yè)務(wù)表必須有status狀態(tài)字段和create_time、update_time時(shí)間字段。沒(méi)有狀態(tài)字段的業(yè)務(wù)表流程根本沒(méi)法走閉環(huán)。金額字段用decimal(10,2)絕對(duì)不用double。這個(gè)細(xì)節(jié)在答辯和真實(shí)開(kāi)發(fā)里都會(huì)被問(wèn)到浮點(diǎn)數(shù)計(jì)算金額會(huì)出精度問(wèn)題專(zhuān)業(yè)感一下就拉低了。外鍵在邏輯上保留但不建物理外鍵。用應(yīng)用層代碼維護(hù)關(guān)聯(lián)即可這樣后續(xù)做分表、擴(kuò)展都很方便。答辯時(shí)說(shuō)一句“考慮性能和數(shù)據(jù)可控性我們?cè)趹?yīng)用層維護(hù)引用完整性”就足夠體面了。3.2 核心表結(jié)構(gòu)說(shuō)明挑幾張最核心的表展開(kāi)講。這些字段設(shè)計(jì)可以直接抄作業(yè)但建議你按照自己的需求微調(diào)。用戶(hù)表 user字段類(lèi)型說(shuō)明idbigint主鍵openidvarchar(64)微信openid唯一索引nicknamevarchar(50)昵稱(chēng)phonevarchar(20)手機(jī)號(hào)roletinyint角色1業(yè)主 2租戶(hù) 3物業(yè) 4管理員statustinyint狀態(tài)0禁用 1正常create_timedatetime創(chuàng)建時(shí)間房屋表 house字段類(lèi)型說(shuō)明idbigint主鍵building_novarchar(20)樓棟號(hào)unit_novarchar(20)單元號(hào)room_novarchar(20)房號(hào)owner_idbigint業(yè)主用戶(hù)IDareadecimal(8,2)建筑面積statustinyint狀態(tài)0空置 1入住報(bào)修表 repair字段類(lèi)型說(shuō)明idbigint主鍵order_novarchar(32)工單號(hào)唯一user_idbigint報(bào)修人house_idbigint關(guān)聯(lián)房屋categoryvarchar(20)報(bào)修類(lèi)型水電門(mén)鎖電梯等descriptiontext問(wèn)題描述image_urlsvarchar(500)照片URL逗號(hào)分隔statustinyint0待分配 1處理中 2待驗(yàn)收 3已完成 4已取消assignee_idbigint指派的維修工create_timedatetime創(chuàng)建時(shí)間繳費(fèi)表 payment字段類(lèi)型說(shuō)明idbigint主鍵bill_novarchar(32)賬單號(hào)唯一user_idbigint繳費(fèi)人house_idbigint關(guān)聯(lián)房屋fee_typetinyint1物業(yè)費(fèi) 2水費(fèi) 3電費(fèi) 4停車(chē)費(fèi)amountdecimal(10,2)金額statustinyint0待支付 1已支付 2已退款pay_timedatetime支付時(shí)間除了業(yè)務(wù)表還需要一張 sys_config 表存物業(yè)收費(fèi)標(biāo)準(zhǔn)比如每平米物業(yè)費(fèi)單價(jià)、車(chē)位月租單價(jià)。繳費(fèi)賬單的生成就是拿單價(jià)乘以房屋面積或者月份數(shù)這個(gè)邏輯后面會(huì)具體講。4. 后端核心模塊實(shí)現(xiàn)從登錄鑒權(quán)到業(yè)務(wù)流程閉環(huán)4.1 微信小程序登錄與JWT鑒權(quán)小程序登錄是整個(gè)系統(tǒng)的基礎(chǔ)流程是固定的小程序端調(diào)用 wx.login 拿到臨時(shí)code傳給后端后端拿著code調(diào)用微信官方 code2Session 接口換取 openid 和 session_key然后用openid查用戶(hù)表新用戶(hù)自動(dòng)注冊(cè)老用戶(hù)直接放行最后后端生成JWT token返回給小程序端后續(xù)所有請(qǐng)求都帶上這個(gè)token。JWT的核心工具類(lèi)我放在下面這段代碼可以直接搬進(jìn)項(xiàng)目里Component public class JwtUtil { Value(${jwt.secret}) private String secret; // 生成token有效期7天 public String generateToken(Long userId, Integer role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } // 解析token返回userId解析失敗返回null public Long parseToken(String token) { try { return Long.parseLong(Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody().getSubject()); } catch (Exception e) { return null; } } }有兩個(gè)關(guān)鍵細(xì)節(jié)必須處理好。一是token有效期我設(shè)了7天。太短會(huì)讓用戶(hù)頻繁重新登錄太長(zhǎng)有安全隱患。二是可以在Redis里存一份token到userId的映射這樣用戶(hù)在“我的”頁(yè)面點(diǎn)退出登錄時(shí)后端能方便地把token拉黑。雖然JWT天然無(wú)狀態(tài)但配合Redis做黑名單能體現(xiàn)出你對(duì)鑒權(quán)體系有完整思考。這里額外提醒一點(diǎn)jwt.secret這個(gè)配置項(xiàng)必須寫(xiě)死在application.yml里不能每次啟動(dòng)隨機(jī)生成。我見(jiàn)過(guò)有人圖省事在代碼里new一個(gè)隨機(jī)密鑰結(jié)果服務(wù)器一重啟所有在線用戶(hù)token全部失效還排查了半天。4.2 報(bào)修工單的完整生命周期報(bào)修模塊是這個(gè)系統(tǒng)里業(yè)務(wù)邏輯最完整的功能也是答辯時(shí)最容易展開(kāi)講的部分。用戶(hù)在小程序里點(diǎn)擊“我要報(bào)修”填寫(xiě)類(lèi)型水、電、門(mén)鎖、電梯等、問(wèn)題描述、上傳照片。后端創(chuàng)建工單時(shí)狀態(tài)置為待分配工單號(hào)用日期加隨機(jī)數(shù)生成保證唯一性。物業(yè)端看到一個(gè)待分配工單后指派給維修工。維修工收到工單后在手機(jī)端更新?tīng)顟B(tài)為處理中到達(dá)現(xiàn)場(chǎng)處理完畢后傳回照片并標(biāo)記為待驗(yàn)收。業(yè)主看到待驗(yàn)收后確認(rèn)無(wú)誤點(diǎn)擊完成整個(gè)工單閉環(huán)。這個(gè)流程里有幾個(gè)很容易踩的坑圖片上傳用小程序端的 wx.chooseMedia 選圖再傳給后端。為了簡(jiǎn)化部署圖片可以保存到服務(wù)器本地靜態(tài)目錄返回一個(gè)URL即可。但一定要注意在SpringBoot里配置靜態(tài)資源映射不然文件存上去了但URL訪問(wèn)不到小程序端永遠(yuǎn)加載不出圖片用戶(hù)會(huì)以為報(bào)修功能壞了。工單狀態(tài)流轉(zhuǎn)必須做權(quán)限校驗(yàn)。業(yè)主不能把別人的工單改成已完成所以更新?tīng)顟B(tài)接口里必須校驗(yàn)當(dāng)前登錄用戶(hù)是否是工單關(guān)聯(lián)人。工單狀態(tài)切換要設(shè)計(jì)成“狀態(tài)機(jī)”模式不允許從任意狀態(tài)跳到任意狀態(tài)。比如待驗(yàn)收的工單不能直接改回待分配。狀態(tài)更新接口的核心邏輯可以這樣寫(xiě)Override public boolean updateStatus(Long repairId, Integer targetStatus, Long operatorId) { Repair repair this.getById(repairId); if (repair null) { throw new ServiceException(工單不存在); } // 狀態(tài)機(jī)校驗(yàn)只能從當(dāng)前狀態(tài)流轉(zhuǎn)到合法下一步 Integer current repair.getStatus(); boolean valid (current 0 (targetStatus 1 || targetStatus 4)) || (current 1 (targetStatus 2)) || (current 2 (targetStatus 3)); if (!valid) { throw new ServiceException(非法的狀態(tài)流轉(zhuǎn)); } // 業(yè)主取消工單只能發(fā)生在待分配或處理中階段 if (targetStatus 4 !repair.getUserId().equals(operatorId)) { throw new ServiceException(無(wú)權(quán)操作此工單); } return this.lambdaUpdate().eq(Repair::getId, repairId) .set(Repair::getStatus, targetStatus) .set(Repair::getUpdateTime, new Date()) .update(); }關(guān)于工單和房屋的關(guān)聯(lián)我的做法是報(bào)修頁(yè)面上直接帶上用戶(hù)當(dāng)前默認(rèn)房屋ID后端存儲(chǔ)。這樣物業(yè)端按樓棟篩選工單非常直觀。另外repair表的 user_id 和 house_id 一定要建索引不然后期工單數(shù)據(jù)量漲上來(lái)查詢(xún)列表會(huì)變慢。4.3 繳費(fèi)賬單生成與狀態(tài)流轉(zhuǎn)繳費(fèi)系統(tǒng)的核心是賬單如何產(chǎn)生。如果每個(gè)賬單都要物業(yè)人員手動(dòng)錄入這套系統(tǒng)就沒(méi)有靈魂了。正確做法是寫(xiě)一個(gè)定時(shí)任務(wù)每月1號(hào)自動(dòng)為所有已入住的房屋生成物業(yè)費(fèi)賬單。計(jì)費(fèi)邏輯是物業(yè)費(fèi) 房屋面積 x 每平米單價(jià) x 月份數(shù)。比如一套100平的房子物業(yè)費(fèi)單價(jià)每月2元/平那一個(gè)月就是200元。要是欠費(fèi)多月賬單會(huì)累加月份的金額。定時(shí)任務(wù)用Spring自帶的Scheduled注解就可以實(shí)現(xiàn)畢設(shè)沒(méi)必要上分布式任務(wù)調(diào)度框架。但有一個(gè)重要細(xì)節(jié)定時(shí)任務(wù)要加冪等控制避免重復(fù)執(zhí)行生成重復(fù)賬單。單機(jī)部署時(shí)可以加同步鎖更規(guī)范的寫(xiě)法是借助Redis實(shí)現(xiàn)一個(gè)簡(jiǎn)單的分布式鎖。這個(gè)點(diǎn)答辯時(shí)講出來(lái)就是加分項(xiàng)。前端繳費(fèi)流程是用戶(hù)看到待支付賬單點(diǎn)擊支付。微信支付在畢設(shè)里比較麻煩的地方是資質(zhì)問(wèn)題個(gè)人開(kāi)發(fā)者往往開(kāi)不了微信支付商戶(hù)號(hào)。我建議優(yōu)先嘗試接入小程序支付如果資質(zhì)確實(shí)卡住就做一個(gè)“在線賬單 線下確認(rèn)”的混合流程小程序端生成賬單用戶(hù)點(diǎn)擊“去繳費(fèi)”后展示物業(yè)收費(fèi)二維碼用戶(hù)線下轉(zhuǎn)賬物業(yè)人員在管理端確認(rèn)到賬后更新賬單狀態(tài)為已支付。這個(gè)妥協(xié)方案可以演示完整流程又不用死磕資質(zhì)問(wèn)題。答辯時(shí)如實(shí)說(shuō)明選擇原因評(píng)審老師一般都能理解。5. 小程序端實(shí)現(xiàn)要點(diǎn)與體驗(yàn)細(xì)節(jié)5.1 頁(yè)面結(jié)構(gòu)與導(dǎo)航設(shè)計(jì)小程序端的頁(yè)面結(jié)構(gòu)我建議四個(gè)主Tab首頁(yè)、服務(wù)、消息、我的。首頁(yè)放公告輪播、快捷入口報(bào)修、繳費(fèi)、訪客預(yù)約。服務(wù)頁(yè)是所有功能入口的九宮格集合。消息頁(yè)展示系統(tǒng)通知和報(bào)修進(jìn)度變更提醒。我的頁(yè)面展示個(gè)人信息、我的房屋、我的報(bào)修、我的賬單、意見(jiàn)反饋。頁(yè)面規(guī)劃和數(shù)據(jù)模型是嚴(yán)格對(duì)應(yīng)的每設(shè)計(jì)一個(gè)頁(yè)面就要想清楚它需要哪幾個(gè)后端接口。我建議在正式開(kāi)發(fā)前先畫(huà)一張接口和頁(yè)面的對(duì)應(yīng)表把關(guān)系固定下來(lái)這樣前后端可以并行開(kāi)發(fā)也不會(huì)發(fā)生接口反復(fù)改的窘境。小程序端的細(xì)節(jié)體驗(yàn)方面有幾個(gè)地方值得注意首頁(yè)加載可以做一個(gè)簡(jiǎn)單的骨架屏優(yōu)化。在請(qǐng)求未返回時(shí)展示灰色占位塊數(shù)據(jù)返回后渲染真實(shí)內(nèi)容。這個(gè)小細(xì)節(jié)在演示時(shí)很出效果。表單頁(yè)要做前端校驗(yàn)。手機(jī)號(hào)11位驗(yàn)證、金額精確到分、輸入框字?jǐn)?shù)限制等這些基礎(chǔ)校驗(yàn)不要等后端報(bào)錯(cuò)再發(fā)現(xiàn)。小程序頁(yè)面棧深度限制是10層設(shè)計(jì)流程時(shí)要控制跳轉(zhuǎn)層級(jí)。比如報(bào)修從首頁(yè)進(jìn)入后最好直接承接到底部Tab的“我的報(bào)修”列表避免用戶(hù)在一個(gè)長(zhǎng)鏈路里迷路。5.2 分包加載與性能優(yōu)化如果小程序主包體積逼近2MB上限就必須做分包加載。在物業(yè)系統(tǒng)這個(gè)場(chǎng)景下報(bào)修模塊和繳費(fèi)模塊頁(yè)面多、組件多很適合單獨(dú)拆成兩個(gè)分包。分包邏輯在 app.json 里配置{ pages: [ pages/index/index, pages/service/service, pages/message/message, pages/my/my ], subpackages: [ { root: packageRepair, name: repair, pages: [ pages/repairApply/repairApply, pages/repairDetail/repairDetail, pages/repairList/repairList ] }, { root: packagePayment, name: payment, pages: [ pages/paymentList/paymentList, pages/paymentDetail/paymentDetail ] } ] }分包之后用戶(hù)進(jìn)入首頁(yè)時(shí)不加載報(bào)修和繳費(fèi)資源只有在點(diǎn)擊進(jìn)入時(shí)才按需加載。首屏加載速度會(huì)有明顯提升這個(gè)性能優(yōu)化點(diǎn)寫(xiě)在論文里、答辯時(shí)講出來(lái)都能證明你有實(shí)戰(zhàn)意識(shí)。頁(yè)面數(shù)據(jù)緩存也要規(guī)劃好。房屋列表、公告列表這些變化不頻繁的數(shù)據(jù)可以用小程序端的storage緩存設(shè)置5分鐘或10分鐘過(guò)期。這樣用戶(hù)反復(fù)進(jìn)出頁(yè)面時(shí)不會(huì)每次都請(qǐng)求后端服務(wù)器壓力小體驗(yàn)也更流暢。但要注意賬單、報(bào)修狀態(tài)這類(lèi)實(shí)時(shí)性強(qiáng)的數(shù)據(jù)絕不能做長(zhǎng)期緩存否則用戶(hù)看到的是舊狀態(tài)會(huì)直接認(rèn)定系統(tǒng)“壞了”。5.3 消息通知與狀態(tài)更新消息通知這里正規(guī)做法是用小程序訂閱消息。用戶(hù)在報(bào)修時(shí)前端引導(dǎo)用戶(hù)訂閱“工單進(jìn)度提醒”后端在工單狀態(tài)更新時(shí)調(diào)用訂閱消息接口推送通知。但這個(gè)功能有兩個(gè)坑需要提前知道。訂閱消息是一次性訂閱機(jī)制用戶(hù)每點(diǎn)一次“允許”只能生效一次。也就是說(shuō)下次還要重新引導(dǎo)訂閱。合理的方式是在報(bào)修成功頁(yè)、繳費(fèi)成功頁(yè)放一個(gè)“開(kāi)啟進(jìn)度通知”按鈕讓用戶(hù)自主選擇而不是每次操作彈窗強(qiáng)制授權(quán)。小程序訂閱消息的模板ID必須在微信公眾平臺(tái)后臺(tái)配置并審核通過(guò)開(kāi)發(fā)階段可以用測(cè)試模板但上線前一定要記得切換到正式模板而且模板內(nèi)容的字段必須和代碼里拼接的完全一致否則會(huì)發(fā)送失敗。除了訂閱消息還可以用WebSocket做站內(nèi)實(shí)時(shí)通知比如首頁(yè)右上角小紅點(diǎn)提示有新的公告或工單狀態(tài)變化。SpringBoot端加一個(gè)WebSocketConfig前端維護(hù)心跳重連邏輯這套方案并不復(fù)雜。但既然是畢設(shè)我建議WebSocket只做消息紅點(diǎn)提醒不做核心業(yè)務(wù)避免把系統(tǒng)復(fù)雜度抬得過(guò)高。6. 部署上線與常見(jiàn)問(wèn)題排查6.1 服務(wù)器部署與HTTPS配置服務(wù)器這塊買(mǎi)一臺(tái)最低配的Linux云主機(jī)就足夠用。需要裝的東西包括JDK 8或11、MySQL 8、Redis、Nginx。運(yùn)行架構(gòu)是這樣的SpringBoot打成可執(zhí)行Jar包在服務(wù)器上用systemd或nohup啟動(dòng)Nginx監(jiān)聽(tīng)80/443端口將 /api 路徑反向代理到SpringBoot的8080端口小程序端通過(guò)HTTPS訪問(wèn)配置好的域名。這里有一個(gè)強(qiáng)制性要求微信小程序正式環(huán)境強(qiáng)制要求所有請(qǐng)求走HTTPS證書(shū)TLS版本也有最低要求。如果證書(shū)配置不對(duì)小程序端會(huì)直接報(bào)“域名不合法”或“TLS版本過(guò)低”排查起來(lái)讓人懷疑人生。所以部署階段第一件事就是把域名證書(shū)弄好不要拖到前后端聯(lián)調(diào)階段才去補(bǔ)。部署時(shí)的最小檢查清單檢查項(xiàng)說(shuō)明域名備案必須完成否則無(wú)法配置HTTPSSSL證書(shū)申請(qǐng)免費(fèi)證書(shū)即可練手完全夠用Nginx反向代理把/api路徑指向后端端口注意proxy_pass尾部是否帶斜杠數(shù)據(jù)庫(kù)賬號(hào)不要用root遠(yuǎn)程直連MySQL創(chuàng)建最小權(quán)限的獨(dú)立賬號(hào)Redis持久化正式環(huán)境建議開(kāi)啟RDB持久化防止崩潰丟數(shù)據(jù)6.2 高頻踩坑記錄與解決方案這部分我把自己實(shí)際做項(xiàng)目時(shí)遇到的頻率最高的坑整理成了一份速查表做類(lèi)似題目的同學(xué)可以直接對(duì)號(hào)入座。問(wèn)題一小程序端請(qǐng)求后端全部404或502。最典型的場(chǎng)景是Nginx反向代理路徑配置不對(duì)。比如 location /api/ { proxy_pass http://127.0.0.1:8080/; } 和 proxy_pass http://127.0.0.1:8080; 的轉(zhuǎn)發(fā)效果完全不同前者會(huì)丟掉 /api 前綴導(dǎo)致后端路由匹配不上。排查思路先在服務(wù)器本地 curl 后端接口確認(rèn)能通再看Nginx轉(zhuǎn)發(fā)日志定位。問(wèn)題二開(kāi)發(fā)工具能請(qǐng)求通真機(jī)預(yù)覽卻報(bào)“域名不合法”。原因是沒(méi)有在微信公眾平臺(tái)后臺(tái)配置合法的 request 合法域名。開(kāi)發(fā)工具里可以臨時(shí)勾選“不校驗(yàn)合法域名”但真機(jī)預(yù)覽和正式發(fā)布必須配置域名且域名必須備案并支持HTTPS。問(wèn)題三上傳圖片后URL打不開(kāi)。一般是SpringBoot靜態(tài)資源映射沒(méi)配置文件存在服務(wù)器本地但無(wú)法通過(guò)URL訪問(wèn)。解決辦法是寫(xiě)一個(gè)WebMvcConfigurer配置類(lèi)把本地物理目錄映射成URL路徑。上傳目錄最好放在項(xiàng)目外部不要讓Jar包目錄膨脹。問(wèn)題四定時(shí)任務(wù)重復(fù)執(zhí)行同一房屋生成了兩條物業(yè)費(fèi)賬單。這是沒(méi)做冪等控制導(dǎo)致的。單機(jī)部署可以在方法上直接加synchronized更好的是用Redis的SETNX命令實(shí)現(xiàn)一個(gè)簡(jiǎn)單分布式鎖獲得鎖的任務(wù)才執(zhí)行。加鎖的key建議用當(dāng)月日期比如 bill_generate_2025_06這樣月度賬單天然隔離。問(wèn)題五微信登錄時(shí) code2Session 返回40029或40163。前者是code無(wú)效后者是code重復(fù)使用。小程序端的code只能使用一次不能緩存復(fù)用。很多同學(xué)把code存在全局變量里頁(yè)面跳轉(zhuǎn)時(shí)反復(fù)傳就會(huì)踩到這個(gè)坑。解決方式登錄流程里后端調(diào)用完微信接口后立即把本次code標(biāo)記為已用。問(wèn)題六JWT token在服務(wù)器重啟后全部失效。原因通常是jwt.secret配置用的是隨機(jī)生成的密鑰。把secret寫(xiě)成固定字符串問(wèn)題就自然消失。問(wèn)題七M(jìn)yBatis-Plus邏輯刪除導(dǎo)致唯一索引沖突。比如用戶(hù)表里openid設(shè)置唯一索引用戶(hù)注銷(xiāo)走邏輯刪除后再重新注冊(cè)同一openid會(huì)因?yàn)榕f記錄還占用唯一索引而插入失敗。解決的常規(guī)思路是唯一索引里加一個(gè) status 字段但更簡(jiǎn)單的方案是邏輯刪除時(shí)給openid加一個(gè)時(shí)間戳后綴保證唯一性。7. 演示準(zhǔn)備、論文結(jié)構(gòu)和擴(kuò)展方向7.1 答辯演示腳本怎么編排很多同學(xué)覺(jué)得系統(tǒng)做出來(lái)了就萬(wàn)事大吉實(shí)際上面試答辯時(shí)的演示過(guò)程比代碼本身更影響最終觀感。我的建議是準(zhǔn)備一份10分鐘左右的演示腳本按“用戶(hù)視角-物業(yè)視角-管理員視角”三步走。用戶(hù)視角從微信登錄開(kāi)始走一遍報(bào)修流程、繳費(fèi)流程、訪客預(yù)約流程。重點(diǎn)展示人機(jī)交互的順暢度和狀態(tài)流轉(zhuǎn)的完整性。這里可以順手展示JWT鑒權(quán)帶來(lái)的自動(dòng)登錄效果。物業(yè)視角登錄一個(gè)物業(yè)賬號(hào)展示待處理工單列表、指派維修工、處理投訴。講一講工單狀態(tài)機(jī)的設(shè)計(jì)邏輯說(shuō)明為什么不允許用戶(hù)任意跳轉(zhuǎn)狀態(tài)。管理員視角登錄管理員賬號(hào)查看數(shù)據(jù)統(tǒng)計(jì)、發(fā)布公告、設(shè)置物業(yè)費(fèi)率。重點(diǎn)講數(shù)據(jù)閉環(huán)——比如管理員新增一條公告后切回小程序首頁(yè)馬上能看到公告出現(xiàn)。演示前務(wù)必準(zhǔn)備好充足的假數(shù)據(jù)。報(bào)修工單要有不同狀態(tài)的賬單要有待支付和已支付的訪客記錄要有本周的。這樣演示時(shí)可以隨時(shí)切換不會(huì)出現(xiàn)頁(yè)面空白的尷尬。7.2 論文結(jié)構(gòu)怎么安排如果這個(gè)題目是你的畢業(yè)設(shè)計(jì)論文結(jié)構(gòu)建議這樣分配緒論背景、意義、國(guó)內(nèi)外現(xiàn)狀、相關(guān)技術(shù)介紹SpringBoot、微信小程序、MySQL、Redis、需求分析、系統(tǒng)設(shè)計(jì)總體架構(gòu)、功能模塊、數(shù)據(jù)庫(kù)、系統(tǒng)實(shí)現(xiàn)關(guān)鍵代碼與界面截圖、系統(tǒng)測(cè)試功能性測(cè)試、非功能性測(cè)試、測(cè)試用例表最后是總結(jié)與展望。有一點(diǎn)必須提醒測(cè)試章節(jié)不要糊弄。至少要有系統(tǒng)功能測(cè)試表每個(gè)模塊對(duì)應(yīng)3到5條用例每條用例寫(xiě)清楚預(yù)期結(jié)果和實(shí)際結(jié)果。這部分體現(xiàn)的工作量在評(píng)分里占比很大。最好再加一張性能測(cè)試記錄比如模擬100個(gè)用戶(hù)并發(fā)調(diào)用登錄接口時(shí)接口的平均響應(yīng)時(shí)間是多少、吞吐量是多少。哪怕只是用壓測(cè)工具跑了一個(gè)簡(jiǎn)單腳本也比空寫(xiě)“經(jīng)測(cè)試系統(tǒng)運(yùn)行穩(wěn)定”這種話有說(shuō)服力得多。7.3 擴(kuò)展空間與個(gè)人體會(huì)最后聊聊這個(gè)題目的延展性。醫(yī)院家屬院區(qū)的物業(yè)系統(tǒng)業(yè)務(wù)模型完全可以復(fù)用到醫(yī)院教學(xué)區(qū)、普通住宅小區(qū)、單位家屬院、學(xué)校教職工生活區(qū)。如果想繼續(xù)深入做可以加智能門(mén)禁聯(lián)動(dòng)掃碼通行、能耗監(jiān)測(cè)水電表遠(yuǎn)程讀數(shù)、社區(qū)服務(wù)集成快遞驛站、家政上門(mén)這些都是目前智慧社區(qū)里的真實(shí)需求也是未來(lái)可以繼續(xù)研究的點(diǎn)。同一套SpringBoot后端架構(gòu)把小程序端換成安卓應(yīng)用或后臺(tái)管理前端又能延伸出新的題目技術(shù)骨架完全不用變。我個(gè)人在實(shí)際開(kāi)發(fā)里最大的感受是這類(lèi)項(xiàng)目的核心價(jià)值不在于用了多前沿的技術(shù)而在于把用戶(hù)、業(yè)務(wù)、數(shù)據(jù)這條完整鏈路真正走通了。業(yè)務(wù)需求拆清楚、數(shù)據(jù)關(guān)系建好、權(quán)限邊界守住這三件事做到位系統(tǒng)就已經(jīng)成功了七成。剩余的三成分給代碼細(xì)節(jié)和交互體驗(yàn)。如果你正在做類(lèi)似的畢業(yè)設(shè)計(jì)把這篇拆解當(dāng)成一張路線圖按步驟走穩(wěn)穩(wěn)落地不是什么難事。