1. 項(xiàng)目概述與場(chǎng)景定位社區(qū)網(wǎng)格化管理這幾年從政務(wù)口到街道辦再到物業(yè)公司已經(jīng)成了數(shù)字化治理的標(biāo)配。簡(jiǎn)單說(shuō)就是把轄區(qū)拆成一個(gè)個(gè)“格子”每個(gè)格子配專人負(fù)責(zé)從人口信息登記、事件上報(bào)、任務(wù)派發(fā)到臺(tái)賬歸檔全流程線上化。過(guò)去這類系統(tǒng)多數(shù)是外包公司拿老掉牙的JSPServlet糊出來(lái)的維護(hù)成本高、界面觀感差網(wǎng)格員用起來(lái)怨聲載道。我最近整理了一套基于SpringBootVue3MyBatis的前后端分離實(shí)現(xiàn)配合MySQL做持久化整體跑下來(lái)不管是在代碼結(jié)構(gòu)、響應(yīng)速度還是二次開(kāi)發(fā)友好度上都比傳統(tǒng)單體方案舒服不少。這個(gè)項(xiàng)目適合誰(shuí)三類人值得關(guān)注一是剛學(xué)完Java后端、想找個(gè)完整項(xiàng)目練手的學(xué)生這套代碼能讓你把SSMSpringSpringBootMyBatis體系的真實(shí)用法串起來(lái)二是準(zhǔn)備面試的Java開(kāi)發(fā)網(wǎng)格化管理平臺(tái)是很典型的“業(yè)務(wù)管理系統(tǒng)”面試題素材里面的權(quán)限設(shè)計(jì)、數(shù)據(jù)權(quán)限隔離、工作流流轉(zhuǎn)是高頻考點(diǎn)三是有實(shí)際社區(qū)管理需求的開(kāi)發(fā)者或產(chǎn)品經(jīng)理可以直接基于這套源碼做二次開(kāi)發(fā)省掉從零搭建的時(shí)間。我用的技術(shù)組合是SpringBoot 2.7.x做后端基礎(chǔ)框架MyBatis負(fù)責(zé)數(shù)據(jù)訪問(wèn)層MySQL 8.0做數(shù)據(jù)存儲(chǔ)前端用Vue3全家桶Vue RouterVuex/PiniaVite前后端通過(guò)RESTful API交互用JWT做無(wú)狀態(tài)鑒權(quán)。整個(gè)項(xiàng)目結(jié)構(gòu)清晰功能覆蓋了網(wǎng)格化管理平臺(tái)的常用場(chǎng)景——登錄鑒權(quán)、用戶管理、網(wǎng)格劃分、人口檔案管理、事件上報(bào)與處置、任務(wù)派發(fā)與進(jìn)度跟蹤、數(shù)據(jù)統(tǒng)計(jì)看板。這里先說(shuō)明一點(diǎn)市面上很多所謂的“社區(qū)網(wǎng)格化管理平臺(tái)源碼”其實(shí)是閹割版或演示版功能少、代碼亂、注釋稀缺很難直接用。我整理的這套重點(diǎn)解決了三個(gè)問(wèn)題一是代碼結(jié)構(gòu)規(guī)范包名、類名、注釋都按照企業(yè)級(jí)項(xiàng)目的習(xí)慣來(lái)二是核心業(yè)務(wù)閉環(huán)完整從事件上報(bào)到審核到派單到處置到歸檔流程是通的三是前端不是簡(jiǎn)單的“套殼后臺(tái)”而是真實(shí)實(shí)現(xiàn)了Vue3的組件化、路由守衛(wèi)、狀態(tài)管理。2. 技術(shù)選型解析為什么是這套組合而不是別的2.1 后端SpringBoot為何依然是中小型管理系統(tǒng)的最優(yōu)解社區(qū)網(wǎng)格化平臺(tái)本質(zhì)上是一個(gè)典型的企業(yè)級(jí)Web應(yīng)用——有用戶認(rèn)證、有權(quán)限管理、有復(fù)雜的業(yè)務(wù)表關(guān)聯(lián)、有文件上傳、有定時(shí)任務(wù)。選框架時(shí)我考慮過(guò)Servlet原生、SSM傳統(tǒng)組合、SpringBoot、SpringCloud微服務(wù)最終定了SpringBoot。原因不復(fù)雜。Servlet原生開(kāi)發(fā)效率太低寫一個(gè)CRUD接口要配一堆XML、web.xml2000年以后出生的程序員估計(jì)都沒(méi)見(jiàn)過(guò)手寫Servlet的痛SSM傳統(tǒng)組合雖然能跑但配置繁瑣光Spring和SpringMVC的XML配置就能寫上百行SpringCloud微服務(wù)對(duì)社區(qū)網(wǎng)格化這種體量來(lái)說(shuō)是拿大炮打蚊子服務(wù)拆分、注冊(cè)中心、配置中心、鏈路追蹤一套下來(lái)運(yùn)維成本直接翻倍團(tuán)隊(duì)沒(méi)有專職運(yùn)維根本玩不轉(zhuǎn)。SpringBoot最香的地方在于“約定大于配置”。內(nèi)嵌Tomcat省掉獨(dú)立的Web服務(wù)器部署自動(dòng)配置只需要在pom.xml里引入依賴框架自動(dòng)搞定Bean裝配配套的actuator、validation、security等starter讓開(kāi)發(fā)專注業(yè)務(wù)邏輯而不是環(huán)境搭建。我實(shí)測(cè)過(guò)從零創(chuàng)建一個(gè)SpringBoot項(xiàng)目到跑通第一個(gè)Hello World接口不超過(guò)5分鐘。這里補(bǔ)充一點(diǎn)關(guān)于SpringBoot版本的選擇。我用的是2.7.x不是最新的3.x。原因很現(xiàn)實(shí)3.x要求JDK 17以上很多公司生產(chǎn)環(huán)境還在用JDK 8另外MyBatis、PageHelper等老牌庫(kù)對(duì)SpringBoot 3的原生支持還不太穩(wěn)定部分配置寫法變了。如果你是自己學(xué)習(xí)用2.7.x配合JDK 8是穩(wěn)妥組合如果是新項(xiàng)目且團(tuán)隊(duì)統(tǒng)一用JDK 17可以上3.x但要有踩坑的心理準(zhǔn)備。2.2 持久層MyBatis與MyBatis-Plus如何選標(biāo)題里寫的是MyBatis實(shí)際上做項(xiàng)目時(shí)我把MyBatis-Plus也集成進(jìn)去了。很多人搞不清這兩個(gè)東西的關(guān)系——MyBatis-Plus不是MyBatis的替代品而是它的增強(qiáng)工具提供了通用的Mapper接口、分頁(yè)插件、條件構(gòu)造器、代碼生成器讓單表CRUD不再需要手寫SQL和XML映射。為什么這么組合因?yàn)樯鐓^(qū)網(wǎng)格化管理平臺(tái)里像居民信息表、樓棟表、網(wǎng)格表這些基礎(chǔ)數(shù)據(jù)表90%的操作是單表增刪改查用MyBatis手寫會(huì)非?？菰锏瘛敖y(tǒng)計(jì)每個(gè)網(wǎng)格內(nèi)60歲以上老人數(shù)量”“查詢某個(gè)時(shí)間段內(nèi)事件處置率”這類統(tǒng)計(jì)型SQL又是MyBatis-Plus的條件構(gòu)造器搞不定的必須手寫SQL此時(shí)MyBatis靈活的XML映射正好派上用場(chǎng)。所以我的實(shí)踐策略是單表基礎(chǔ)操作用MyBatis-Plus的BaseMapper復(fù)雜統(tǒng)計(jì)查詢用Select注解或XML文件手寫SQL。兩者混用既保證了開(kāi)發(fā)效率又不失靈活度。這個(gè)策略很值得借鑒比二選一更符合真實(shí)項(xiàng)目的復(fù)雜度。2.3 前端Vue3相對(duì)Vue2到底升級(jí)了什么前端選Vue3是順勢(shì)而為。Vue3的核心變化有三點(diǎn)一是Composition API把組件邏輯按功能聚合而不是按選項(xiàng)分散多組件復(fù)用邏輯時(shí)不再依賴mixins那一套容易沖突的機(jī)制二是基于Proxy的響應(yīng)式系統(tǒng)替代了Vue2的Object.defineProperty對(duì)數(shù)組和動(dòng)態(tài)屬性的攔截更徹底性能也更好三是Vite構(gòu)建工具冷啟動(dòng)速度比Webpack快一個(gè)數(shù)量級(jí)改代碼熱更新幾乎是秒級(jí)響應(yīng)。但要說(shuō)實(shí)話如果只是做一個(gè)后臺(tái)管理系統(tǒng)Vue3的很多新特性你用不上。選項(xiàng)式API照樣能寫Proxy的差異普通開(kāi)發(fā)根本感知不到Vite雖然快但你一天也就啟動(dòng)個(gè)幾次項(xiàng)目。我堅(jiān)持用Vue3核心原因是組件化代碼的組織方式更清晰——Composition API讓每個(gè)功能點(diǎn)的代碼數(shù)據(jù)、方法、生命周期鉤子聚在一起而不是分散在data、methods、watch、computed里項(xiàng)目大了以后維護(hù)體驗(yàn)天差地別。另外Vue3配合Element Plus組件庫(kù)做后臺(tái)管理系統(tǒng)的效率非常高。表格、表單、彈窗、樹(shù)形控件、分頁(yè)都是現(xiàn)成的樣式也統(tǒng)一網(wǎng)格員用起來(lái)上手成本很低。2.4 數(shù)據(jù)庫(kù)MySQL 8.0的關(guān)鍵優(yōu)勢(shì)與本地環(huán)境搭建MySQL作為社區(qū)網(wǎng)格化平臺(tái)的數(shù)據(jù)存儲(chǔ)是這個(gè)體量項(xiàng)目的標(biāo)準(zhǔn)答案。關(guān)系型數(shù)據(jù)天然適合網(wǎng)格管理這種結(jié)構(gòu)化、強(qiáng)關(guān)聯(lián)的數(shù)據(jù)模型居民屬于樓棟樓棟屬于網(wǎng)格網(wǎng)格屬于社區(qū)這種層級(jí)關(guān)系用SQL外鍵和聯(lián)表查詢表現(xiàn)起來(lái)自然又高效。我選的是MySQL 8.0相比5.7有幾處關(guān)鍵升級(jí)默認(rèn)字符集是utf8mb4能直接存儲(chǔ)emoji表情和生僻字人名這塊很重要支持窗口函數(shù)做統(tǒng)計(jì)排名類的SQL簡(jiǎn)潔很多支持公用表表達(dá)式CTE復(fù)雜查詢不用寫一堆嵌套子查詢。安裝時(shí)注意一點(diǎn)8.0默認(rèn)的密碼加密方式是caching_sha2_password老的客戶端驅(qū)動(dòng)連接會(huì)報(bào)錯(cuò)需要改配置或升級(jí)驅(qū)動(dòng)。本地開(kāi)發(fā)環(huán)境的搭建流程比較固定官網(wǎng)下載MySQL Installer選Developer Default一路Next中間會(huì)要求設(shè)置root密碼記得選對(duì)數(shù)據(jù)庫(kù)端口默認(rèn)3306。安裝完成后需要在系統(tǒng)環(huán)境變量里把MySQL的bin目錄加進(jìn)去這樣命令行才能直接敲mysql命令。前端需要Node.js 16后端需要JDK 8和Maven 3.6。3. 核心功能模塊與業(yè)務(wù)閉環(huán)設(shè)計(jì)3.1 用戶權(quán)限模型RBAC與數(shù)據(jù)權(quán)限隔離社區(qū)網(wǎng)格化平臺(tái)最核心的體系是權(quán)限。我先說(shuō)角色權(quán)限再說(shuō)數(shù)據(jù)權(quán)限——這兩者經(jīng)常被混為一談其實(shí)是完全不同的東西。角色權(quán)限用標(biāo)準(zhǔn)的RBAC模型用戶表sys_user、角色表sys_role、菜單表sys_menu外加兩張關(guān)聯(lián)表user_role、role_menu。超級(jí)管理員、街道管理員、社區(qū)管理員、網(wǎng)格員四種角色各自能訪問(wèn)的菜單和操作按鈕不同。前端根據(jù)登錄用戶返回的按鈕權(quán)限列表控制哪些按鈕顯示哪些不顯示后端在每個(gè)接口上用RequiresPermissions注解做二次校驗(yàn)防止有人繞過(guò)前端直接調(diào)接口。數(shù)據(jù)權(quán)限是網(wǎng)格化平臺(tái)的特色。同樣是網(wǎng)格員角色A網(wǎng)格的網(wǎng)格員不能查看B網(wǎng)格的居民信息社區(qū)管理員能看自己社區(qū)下所有網(wǎng)格的數(shù)據(jù)但不能看隔壁社區(qū)的。這個(gè)我用MyBatis攔截器實(shí)現(xiàn)——攔截SQL語(yǔ)句判斷當(dāng)前用戶的數(shù)據(jù)權(quán)限級(jí)別如果是網(wǎng)格員就自動(dòng)拼接“WHERE grid_id ?”如果是社區(qū)管理員就拼接“WHERE community_id ?”。這樣業(yè)務(wù)代碼里完全不用關(guān)心數(shù)據(jù)過(guò)濾只管寫SELECT * FROM resident攔截器自動(dòng)幫你把條件加上。這套設(shè)計(jì)的巧妙之處在于新加一個(gè)業(yè)務(wù)模塊時(shí)只要數(shù)據(jù)表里有g(shù)rid_id或community_id字段權(quán)限攔截器就能自動(dòng)生效完全零侵入。3.2 基礎(chǔ)數(shù)據(jù)管理網(wǎng)格劃分與樓棟、居民信息檔案網(wǎng)格化管理的底層數(shù)據(jù)是“網(wǎng)格-樓棟-房屋-居民”的四級(jí)關(guān)聯(lián)結(jié)構(gòu)。設(shè)計(jì)表時(shí)要把這個(gè)層級(jí)關(guān)系落清楚網(wǎng)格表grid每個(gè)網(wǎng)格歸屬某個(gè)社區(qū)有網(wǎng)格名稱、編碼、負(fù)責(zé)網(wǎng)格員ID樓棟表building歸屬某個(gè)網(wǎng)格記錄樓棟號(hào)、層數(shù)、單元數(shù)、經(jīng)緯度坐標(biāo)房屋表house歸屬某樓棟記錄房號(hào)、面積、戶型、當(dāng)前居住人數(shù)居民表resident歸屬某房屋記錄姓名、身份證號(hào)、手機(jī)號(hào)、戶籍狀態(tài)、是否黨員、是否60歲以上老人等標(biāo)簽字段這塊業(yè)務(wù)寫起來(lái)不難就是反復(fù)的CRUD但有幾個(gè)細(xì)節(jié)值得注意。身份證號(hào)查重是必須的——網(wǎng)格員錄入時(shí)經(jīng)常錄重直接用身份證號(hào)做唯一索引重復(fù)插入直接報(bào)錯(cuò)樓棟和房屋的編碼要有規(guī)則比如“0102-03-0502”表示1號(hào)社區(qū)2號(hào)網(wǎng)格3號(hào)樓5層2號(hào)房既能當(dāng)業(yè)務(wù)編碼又能當(dāng)展示名稱還能用于快速檢索居民信息的標(biāo)簽字段老人、黨員、退役軍人、低保戶等用多選標(biāo)簽存儲(chǔ)方便做篩選統(tǒng)計(jì)。3.3 事件流轉(zhuǎn)從上報(bào)、審核、派單到處置歸檔的完整閉環(huán)事件處理是網(wǎng)格化平臺(tái)的“動(dòng)線”核心。我設(shè)計(jì)的事件流程是網(wǎng)格員日常巡查發(fā)現(xiàn)問(wèn)題或居民通過(guò)小程序上報(bào)在系統(tǒng)里創(chuàng)建事件工單社區(qū)管理員審核工單確認(rèn)無(wú)效的直接駁回確認(rèn)有效的派單給對(duì)應(yīng)網(wǎng)格的網(wǎng)格員網(wǎng)格員接單后去現(xiàn)場(chǎng)處置填寫處置結(jié)果并上傳照片網(wǎng)格員提交后社區(qū)管理員復(fù)核復(fù)核通過(guò)則歸檔不通過(guò)則退回重新處置。這里面涉及狀態(tài)機(jī)設(shè)計(jì)。事件狀態(tài)我用一個(gè)枚舉類維護(hù)待審核、審核駁回、待派單、已派單、處置中、待復(fù)核、復(fù)核駁回、已歸檔。每個(gè)狀態(tài)的流轉(zhuǎn)方向是固定的比如待審核只能流向?qū)徍笋g回或待派單不能跳到已歸檔。實(shí)現(xiàn)上我在后端Service層寫了一個(gè)統(tǒng)一的狀態(tài)流轉(zhuǎn)校驗(yàn)方法狀態(tài)不合法直接拋異常避免代碼里到處寫if-else導(dǎo)致?tīng)顟B(tài)管理失控。超時(shí)預(yù)警也值得一提。社區(qū)對(duì)這個(gè)有考核要求——事件必須在24小時(shí)內(nèi)處置完畢。我用SpringBoot自帶的Scheduled定時(shí)任務(wù)每小時(shí)掃描一次事件表如果發(fā)現(xiàn)處置中超時(shí)的工單自動(dòng)給對(duì)應(yīng)網(wǎng)格員的上級(jí)發(fā)送站內(nèi)消息提醒。這個(gè)用Quartz也能做但社區(qū)網(wǎng)格化這個(gè)體量用Scheduled就夠用了不必引入額外依賴。3.4 數(shù)據(jù)統(tǒng)計(jì)看板用SQL和ECharts做前端可視化平臺(tái)需要一個(gè)數(shù)據(jù)看板頁(yè)面展示網(wǎng)格內(nèi)的人口、事件、任務(wù)等核心指標(biāo)的統(tǒng)計(jì)結(jié)果。我用ECharts實(shí)現(xiàn)圖表展示數(shù)據(jù)接口直接在后端寫SQL聚合查詢。統(tǒng)計(jì)指標(biāo)包括各網(wǎng)格人口分布柱狀圖、本月事件處置率折線圖、事件類型餅圖、超時(shí)處置排行榜。這些SQL的核心是GROUP BY加各種聚合函數(shù)。比如統(tǒng)計(jì)每個(gè)網(wǎng)格的人口數(shù)就是SELECT g.id, g.grid_name, COUNT(r.id) AS resident_count FROM grid g LEFT JOIN building b ON g.id b.grid_id LEFT JOIN house h ON b.id h.building_id LEFT JOIN resident r ON h.id r.house_id GROUP BY g.id, g.grid_name這里用了LEFT JOIN而不是INNER JOIN是因?yàn)橛行┚W(wǎng)格可能還沒(méi)有樓棟數(shù)據(jù)但看板上依然要顯示這個(gè)網(wǎng)格只是數(shù)量為0。很多新手在這里犯錯(cuò)用了INNER JOIN后沒(méi)數(shù)據(jù)的網(wǎng)格直接消失報(bào)表不完整。看板查詢要注意性能問(wèn)題。如果數(shù)據(jù)量大每個(gè)圖表渲染時(shí)都實(shí)時(shí)去數(shù)據(jù)庫(kù)聚合數(shù)據(jù)庫(kù)壓力會(huì)很大。我的方案是建一張統(tǒng)計(jì)匯總表定時(shí)任務(wù)每天凌晨把前一天的數(shù)據(jù)預(yù)計(jì)算好存進(jìn)去看板直接查詢匯總表速度能提升幾十倍。建設(shè)項(xiàng)目初期數(shù)據(jù)量小可能感覺(jué)不到差異但上線半年后這個(gè)優(yōu)化就非常關(guān)鍵了。4. 數(shù)據(jù)庫(kù)設(shè)計(jì)的核心細(xì)節(jié)與建表實(shí)操4.1 建表規(guī)范編碼、時(shí)間字段與邏輯刪除數(shù)據(jù)庫(kù)設(shè)計(jì)的好與壞直接決定了后面寫業(yè)務(wù)代碼時(shí)是舒服還是痛苦。我在這個(gè)項(xiàng)目里的建表規(guī)范如下每張表必須有id主鍵類型用BIGINT自增。每張表必須有create_time和update_time兩個(gè)時(shí)間字段類型是DATETIME默認(rèn)值CURRENT_TIMESTAMPupdate_time在數(shù)據(jù)更新時(shí)自動(dòng)刷新。每張表必須有deleted字段做邏輯刪除用TINYINT類型0表示未刪除1表示已刪除。為什么不物理刪除因?yàn)榫用裥畔?、事件工單都是需要留痕的?shù)據(jù)物理刪除會(huì)導(dǎo)致審計(jì)審計(jì)鏈斷裂而且如果有外鍵關(guān)聯(lián)物理刪除會(huì)報(bào)錯(cuò)。字符集統(tǒng)一用utf8mb4排序規(guī)則用utf8mb4_general_ci。我之前說(shuō)過(guò)utf8mb4才能存emoji和生僻字人名地名這種場(chǎng)景經(jīng)常出現(xiàn)特殊字符跳過(guò)這個(gè)坑能省很多事。下面貼一個(gè)居民信息表的建表SQL片段你可以直接參考CREATE TABLE resident ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主鍵ID, name VARCHAR(50) NOT NULL COMMENT 姓名, id_card VARCHAR(18) NOT NULL COMMENT 身份證號(hào), phone VARCHAR(20) DEFAULT NULL COMMENT 手機(jī)號(hào), gender TINYINT DEFAULT NULL COMMENT 性別 1男 2女, house_id BIGINT DEFAULT NULL COMMENT 所屬房屋ID, grid_id BIGINT DEFAULT NULL COMMENT 所屬網(wǎng)格ID, is_elderly TINYINT DEFAULT 0 COMMENT 是否60歲以上老人 1是 0否, is_party_member TINYINT DEFAULT 0 COMMENT 是否黨員 1是 0否, deleted TINYINT DEFAULT 0 COMMENT 邏輯刪除 1刪除 0未刪除, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時(shí)間, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新時(shí)間, PRIMARY KEY (id), UNIQUE KEY uk_id_card (id_card) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT居民信息表;這里把id_card字段加了唯一索引目的就是防止身份證號(hào)重復(fù)錄入。有人會(huì)問(wèn)身份證號(hào)涉及隱私直接存明文合適嗎正規(guī)做法是加密存儲(chǔ)但社區(qū)網(wǎng)格化系統(tǒng)內(nèi)部網(wǎng)格員錄入、查看、核對(duì)是日常工作流程加密后反而影響使用效率。折中方案是數(shù)據(jù)庫(kù)層面限制權(quán)限、應(yīng)用層面做操作日志敏感信息展示時(shí)做脫敏處理比如中間8位打星號(hào)需要查看完整號(hào)碼時(shí)單獨(dú)二次授權(quán)。4.2 多表關(guān)聯(lián)查詢的設(shè)計(jì)技巧社區(qū)網(wǎng)格化數(shù)據(jù)表之間有天然的外鍵關(guān)系但我不建議在數(shù)據(jù)庫(kù)層面強(qiáng)加外鍵約束。原因是一個(gè)高頻寫入的OLTP系統(tǒng)外鍵會(huì)在每次插入、更新時(shí)觸發(fā)額外的校驗(yàn)性能有損耗而且后期做數(shù)據(jù)分片、數(shù)據(jù)歸檔時(shí)外鍵會(huì)成為絆腳石。實(shí)際做法是表結(jié)構(gòu)上不建外鍵應(yīng)用層通過(guò)MyBatis的聯(lián)表查詢或代碼邏輯保證數(shù)據(jù)一致性。多表關(guān)聯(lián)查詢要遵循“盡量一次查出來(lái)不要循環(huán)查庫(kù)”的原則。比如查詢居民列表時(shí)需要附帶顯示所屬網(wǎng)格名稱、樓棟名稱一條SQL用JOIN就搞定SELECT r.id, r.name, r.id_card, r.phone, g.grid_name, b.building_name, h.house_no FROM resident r LEFT JOIN grid g ON r.grid_id g.id LEFT JOIN building b ON r.building_id b.id LEFT JOIN house h ON r.house_id h.id WHERE r.deleted 0如果先查居民列表再循環(huán)根據(jù)grid_id查網(wǎng)格名稱100條數(shù)據(jù)就要查101次數(shù)據(jù)庫(kù)性能完全沒(méi)法看。這個(gè)“N1查詢”問(wèn)題是新手最容易犯的低級(jí)錯(cuò)誤面試也經(jīng)常問(wèn)務(wù)必在一開(kāi)始就養(yǎng)成習(xí)慣避免。4.3 索引設(shè)計(jì)與慢查詢優(yōu)化索引是數(shù)據(jù)庫(kù)優(yōu)化的第一手段但索引不是越多越好。每個(gè)索引都會(huì)占用額外磁盤空間并拖慢插入、更新、刪除操作的速度。我在這個(gè)項(xiàng)目里的索引設(shè)計(jì)原則是高頻查詢條件建索引區(qū)分度低的字段不建索引聯(lián)合索引按照最左前綴原則設(shè)計(jì)。居民表里除了主鍵索引和身份證號(hào)唯一索引我還建了grid_id普通索引因?yàn)榫W(wǎng)格維度的篩選是最高頻操作——網(wǎng)格員只看自己網(wǎng)格的居民。事件表里我建了一個(gè)聯(lián)合索引(status, create_time)因?yàn)椴樵冞壿嬐ǔＪ恰安槟硞€(gè)狀態(tài)下某段時(shí)間的事件”這個(gè)聯(lián)合索引既能快速過(guò)濾狀態(tài)又能按時(shí)間排序。同時(shí)這個(gè)聯(lián)合索引里的字段順序也是有講究的——status區(qū)分度高放前面create_time區(qū)分度相對(duì)低放后面。慢查詢優(yōu)化方面我一般先開(kāi)啟MySQL的慢查詢?nèi)罩驹O(shè)定閾值為1秒跑幾天后把日志導(dǎo)出來(lái)分析。結(jié)合EXPLAIN查看SQL執(zhí)行計(jì)劃重點(diǎn)看有沒(méi)有全表掃描、有沒(méi)有走錯(cuò)索引、有沒(méi)有回表過(guò)多。遇到復(fù)雜報(bào)表SQL優(yōu)先考慮SQL改寫比如子查詢轉(zhuǎn)JOIN、避免SELECT *。如果改寫解決不了再加匯總表或緩存。5. 后端核心實(shí)現(xiàn)從項(xiàng)目骨架到業(yè)務(wù)接口開(kāi)發(fā)5.1 項(xiàng)目結(jié)構(gòu)分層與初始化一個(gè)清晰的項(xiàng)目結(jié)構(gòu)能讓你后面寫代碼時(shí)心情愉悅也讓接手的人不用花三天時(shí)間摸門路。我的包結(jié)構(gòu)如下com.community.admin ├── common // 通用模塊統(tǒng)一返回結(jié)果、異常處理、工具類 ├── config // 配置類MyBatis配置、攔截器配置、跨域配置 ├── controller // 控制層接收前端請(qǐng)求 ├── entity // 實(shí)體類對(duì)應(yīng)用戶表、角色表、居民表等 ├── mapper // 數(shù)據(jù)訪問(wèn)層MyBatis的Mapper接口 ├── service // 業(yè)務(wù)邏輯層接口實(shí)現(xiàn)類 │ └── impl ├── dto // 數(shù)據(jù)傳輸對(duì)象接收前端參數(shù)避免直接暴露實(shí)體類 ├── vo // 視圖對(duì)象返回給前端的結(jié)果對(duì)象 ├── interceptor // 攔截器登錄鑒權(quán)、數(shù)據(jù)權(quán)限、操作日志 └── task // 定時(shí)任務(wù)超時(shí)預(yù)警、統(tǒng)計(jì)預(yù)計(jì)算分層設(shè)計(jì)的原則其實(shí)是各層各司其職、單向依賴controller只做參數(shù)接收和響應(yīng)封裝不寫業(yè)務(wù)邏輯service專注業(yè)務(wù)邏輯不出現(xiàn)SQL語(yǔ)句mapper只負(fù)責(zé)數(shù)據(jù)庫(kù)操作不寫業(yè)務(wù)判斷。這樣做的好處是測(cè)試時(shí)可以單獨(dú)mock每一層出了問(wèn)題也能迅速定位。初始化項(xiàng)目時(shí)我習(xí)慣直接在Spring Initializrstart.spring.io上生成勾選Web、MySQL Driver、MyBatis、Lombok等依賴。生成的pom.xml里再手動(dòng)加上MyBatis-Plus、JWT、Hutool工具包。Hutool是我非常推薦的工具庫(kù)封裝了日期、字符串、加密、文件操作等大量常用方法能省掉很多重復(fù)代碼。5.2 JWT登錄鑒權(quán)的完整實(shí)現(xiàn)社區(qū)網(wǎng)格化平臺(tái)不需要做太復(fù)雜的OAuth2.0授權(quán)前后端分離場(chǎng)景下JWT是比較成熟的方案。流程是用戶輸入用戶名密碼后端驗(yàn)證通過(guò)后簽發(fā)一個(gè)token返回給前端前端把token存在localStorage或Pinia中每次請(qǐng)求在請(qǐng)求頭帶上Authorization: Bearer token后端通過(guò)攔截器解析token并放入當(dāng)前請(qǐng)求上下文標(biāo)識(shí)當(dāng)前用戶是誰(shuí)、有哪些角色。JWT的好處是服務(wù)端無(wú)狀態(tài)不需要在服務(wù)端存session方便水平擴(kuò)容。缺點(diǎn)是沒(méi)法主動(dòng)讓token失效所以簽發(fā)時(shí)設(shè)置一個(gè)合理的過(guò)期時(shí)間很重要我設(shè)置為2小時(shí)每次請(qǐng)求時(shí)在前端判斷token是否即將過(guò)期如果只剩20分鐘就自動(dòng)調(diào)刷新接口換新token。核心代碼片段如下public String generateToken(LoginUser user) { MapString, Object claims new HashMap(); claims.put(userId, user.getId()); claims.put(username, user.getUsername()); claims.put(roles, user.getRoles()); return Jwts.builder() .setClaims(claims) .setExpiration(new Date(System.currentTimeMillis() 86400000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }注意密鑰要放到配置文件中通過(guò)Value注入不要硬編碼在代碼里。密鑰長(zhǎng)度至少要256位32字節(jié)否則HS256算法會(huì)直接報(bào)錯(cuò)。攔截器是鑒權(quán)的核心建議實(shí)現(xiàn)HandlerInterceptor接口重寫preHandle方法。放行登錄接口和靜態(tài)資源其他接口全部校驗(yàn)token。校驗(yàn)失敗時(shí)返回401狀態(tài)碼和統(tǒng)一錯(cuò)誤信息前端axios攔截器收到401后跳轉(zhuǎn)到登錄頁(yè)。5.3 使用MyBatis/MyBatis-Plus操作數(shù)據(jù)庫(kù)的關(guān)鍵代碼MyBatis-Plus讓單表CRUD變成一件極其簡(jiǎn)單的事。實(shí)體類、Mapper接口、Service層代碼合起來(lái)不超過(guò)50行// 實(shí)體類 Data TableName(grid) public class Grid { TableId(type IdType.AUTO) private Long id; private String gridName; private String gridCode; private Long communityId; private String remark; private Integer deleted; } // Mapper接口 Mapper public interface GridMapper extends BaseMapperGrid { } // Service中使用 Autowired private GridMapper gridMapper; // 查詢網(wǎng)格列表按社區(qū)ID篩選 LambdaQueryWrapperGrid wrapper new LambdaQueryWrapper(); wrapper.eq(Grid::getCommunityId, communityId) .eq(Grid::getDeleted, 0) .orderByAsc(Grid::getGridCode); ListGrid gridList gridMapper.selectList(wrapper);LambdaQueryWrapper的eq方法中傳的是方法引用Grid::getCommunityId而不是字符串字段名好處是編譯期就能發(fā)現(xiàn)字段名拼寫錯(cuò)誤重構(gòu)字段名時(shí)也不會(huì)遺漏。實(shí)體類上的TableName注解用于將Java類名映射到數(shù)據(jù)庫(kù)表名默認(rèn)情況下MyBatis-Plus會(huì)開(kāi)啟駝峰轉(zhuǎn)下劃線映射所以gridName會(huì)自動(dòng)對(duì)應(yīng)grid_name字段。多表關(guān)聯(lián)查詢則直接用XML文件寫SQL比如前面提到的居民列表JOIN查詢。XML文件的namespace要寫全限定類名方法id要對(duì)應(yīng)Mapper接口中的方法名resultMap或resultType要配置正確。resultType直接用VO對(duì)象字段名對(duì)齊SQL的別名就可以省去手寫resultMap的繁瑣。5.4 事務(wù)處理與并發(fā)控制社區(qū)網(wǎng)格化平臺(tái)的事務(wù)場(chǎng)景不算多但有幾個(gè)關(guān)鍵地方必須注意。比如事件派單時(shí)既要更新事件表的狀態(tài)為“已派單”又要給對(duì)應(yīng)網(wǎng)格員插入一條任務(wù)記錄兩個(gè)操作必須在一個(gè)事務(wù)里——任何一個(gè)失敗都要整體回滾否則會(huì)出現(xiàn)事件狀態(tài)變成已派單但網(wǎng)格員沒(méi)有收到任務(wù)的臟數(shù)據(jù)。SpringBoot的事務(wù)用起來(lái)很簡(jiǎn)單在Service方法上加上Transactional注解即可。但有幾個(gè)細(xì)節(jié)需要強(qiáng)調(diào)第一事務(wù)默認(rèn)只對(duì)RuntimeException回滾檢查異常如IOException不會(huì)觸發(fā)回滾。如果業(yè)務(wù)方法里主動(dòng)捕獲了異常又沒(méi)拋出事務(wù)也不會(huì)回滾。所以要么讓異常拋出去要么在catch塊中手動(dòng)調(diào)用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。第二自調(diào)用失效問(wèn)題。同類中A方法調(diào)用B方法B方法上的Transactional注解是不會(huì)生效的。因?yàn)镾pring事務(wù)是通過(guò)AOP代理實(shí)現(xiàn)的同類調(diào)用不走代理。解決方式是把B方法拆到另一個(gè)Service里或者通過(guò)ApplicationContext獲取代理對(duì)象調(diào)用。第三高并發(fā)下的事件重復(fù)派單。兩個(gè)管理員同時(shí)看到“待派單”事件同時(shí)點(diǎn)擊派單可能導(dǎo)致同一個(gè)事件被分給兩個(gè)網(wǎng)格員。解決方案是在事件表加一個(gè)version字段派單時(shí)用樂(lè)觀鎖判斷版本號(hào)是否匹配UPDATE event SET status 2, version version 1 WHERE id ? AND version ?受影響行數(shù)為0說(shuō)明有人搶先更新了重新查詢后提示用戶事件已被處理。這種方案比數(shù)據(jù)庫(kù)行鎖簡(jiǎn)單而且不會(huì)造成長(zhǎng)事務(wù)。6. 前端工程化實(shí)現(xiàn)Vue3 Vite Element Plus6.1 項(xiàng)目初始化和目錄結(jié)構(gòu)設(shè)計(jì)前端我用Vite構(gòu)建Vue3項(xiàng)目。初始化命令很簡(jiǎn)單npm create vitelatest community-admin -- --template vue如果之前沒(méi)裝過(guò)Vite工具鏈需要先保證Node.js版本在16以上。初始化完成后安裝依賴npm install npm install vue-router4 pinia axios element-plus element-plus/icons-vue項(xiàng)目目錄結(jié)構(gòu)如下src ├── api // 各模塊的接口請(qǐng)求封裝 ├── assets // 靜態(tài)資源 ├── components // 公共組件 ├── layout // 后臺(tái)布局框架 ├── router // 路由配置 ├── store // Pinia狀態(tài)管理 ├── utils // 工具函數(shù)請(qǐng)求封裝、token存取等 ├── views // 頁(yè)面組件 ├── App.vue // 根組件 └── main.js // 入口文件API模塊的封裝值得多說(shuō)一句。我把每個(gè)后端的接口按照業(yè)務(wù)模塊拆分為獨(dú)立的js文件比如grid.js里放網(wǎng)格相關(guān)接口、resident.js里放居民相關(guān)接口每個(gè)接口返回一個(gè)Promise。這樣頁(yè)面里調(diào)用時(shí)只需要引入對(duì)應(yīng)的api文件見(jiàn)名知意后端接口變更時(shí)只需要改一個(gè)文件。6.2 Axios請(qǐng)求攔截與響應(yīng)處理的工程化封裝前端與后端交互的核心是axios。我在utils/request.js中封裝了一個(gè)統(tǒng)一的axios實(shí)例做了三件事基礎(chǔ)URL配置、請(qǐng)求攔截器自動(dòng)附加token、響應(yīng)攔截器統(tǒng)一處理錯(cuò)誤碼和數(shù)據(jù)解包。import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.msg || 請(qǐng)求失敗) if (res.code 401) { localStorage.removeItem(token) router.push(/login) } return Promise.reject(new Error(res.msg)) } return res.data }, error { ElMessage.error(error.message || 網(wǎng)絡(luò)錯(cuò)誤) return Promise.reject(error) } ) export default request統(tǒng)一封裝的好處是頁(yè)面代碼里完全不需要關(guān)心token怎么加、錯(cuò)誤怎么處理只管調(diào)接口拿數(shù)據(jù)。遇到401未登錄時(shí)自動(dòng)跳登錄頁(yè)這個(gè)體驗(yàn)對(duì)小后臺(tái)系統(tǒng)很友好。6.3 動(dòng)態(tài)路由與權(quán)限控制系統(tǒng)有四個(gè)角色不同角色看到的菜單不同。實(shí)現(xiàn)方案是前端先定義好所有業(yè)務(wù)頁(yè)面的靜態(tài)路由再定義一個(gè)動(dòng)態(tài)路由容器用戶登錄后后端返回該用戶角色的菜單權(quán)限列表前端根據(jù)權(quán)限列表動(dòng)態(tài)添加路由并生成側(cè)邊欄菜單。核心實(shí)現(xiàn)要點(diǎn)路由守衛(wèi)在router.beforeEach中判斷是否已登錄。未登錄跳登錄頁(yè)已登錄但用戶信息為空時(shí)調(diào)獲取用戶信息接口拿到權(quán)限列表后動(dòng)態(tài)addRoute。這里有一個(gè)常見(jiàn)陷阱——?jiǎng)討B(tài)添加路由后需要調(diào)用next({...to, replace: true})重新觸發(fā)一次路由跳轉(zhuǎn)否則頁(yè)面會(huì)白屏因?yàn)槭状翁D(zhuǎn)的守衛(wèi)執(zhí)行時(shí)路由還沒(méi)被注冊(cè)。按鈕級(jí)權(quán)限的實(shí)現(xiàn)更簡(jiǎn)單登錄后調(diào)用一個(gè)接口獲取按鈕權(quán)限標(biāo)識(shí)數(shù)組存到Pinia里。頁(yè)面上定義一個(gè)新指令v-permission不足權(quán)限時(shí)從DOM中移除按鈕app.directive(permission, { mounted(el, binding) { const requiredPerm binding.value const hasPerm usePermissionStore().buttons.includes(requiredPerm) if (!hasPerm) { el.parentNode?.removeChild(el) } } })模板中用法是el-button v-permissionevent:delete刪除/el-button沒(méi)有權(quán)限的后端不返回這個(gè)按鈕標(biāo)識(shí)前端自動(dòng)隱藏雙重保障。6.4 表格、表單與彈窗組合的核心頁(yè)面實(shí)操后臺(tái)管理系統(tǒng)的高頻操作集中在“表格搜索彈窗表單分頁(yè)”。Vue3Element Plus的組合讓這套流程變得極其順手。我以一個(gè)居民信息管理頁(yè)面為例說(shuō)下完整的實(shí)現(xiàn)思路。頁(yè)面模板結(jié)構(gòu)搜索區(qū)柵格布局放多個(gè)字段、表格區(qū)el-table綁定數(shù)據(jù)、分頁(yè)區(qū)el-pagination、新增/編輯彈窗el-dialog內(nèi)嵌el-form。搜索區(qū)字段通過(guò)v-model綁定搜索表單對(duì)象點(diǎn)擊搜索時(shí)把表單參數(shù)傳給后端查詢接口。注意分頁(yè)查詢接口通常需要五個(gè)參數(shù)pageNumpageSizekeyword以及若干篩選條件。el-table的prop屬性綁定數(shù)據(jù)字段名label是列標(biāo)題。操作列放編輯、詳情、刪除按鈕。分頁(yè)組件的current-change和size-change事件對(duì)應(yīng)修改頁(yè)碼和每頁(yè)條數(shù)觸發(fā)重新加載數(shù)據(jù)。彈窗新增/編輯用的是同一個(gè)組件通過(guò)傳入的row參數(shù)區(qū)分是新增還是編輯。打開(kāi)彈窗時(shí)如果是編輯就把當(dāng)前行數(shù)據(jù)深拷貝到表單對(duì)象中避免直接修改表格數(shù)據(jù)造成問(wèn)題提交時(shí)校驗(yàn)規(guī)則通過(guò)后調(diào)用對(duì)應(yīng)的保存接口成功后關(guān)閉彈窗并刷新列表。有個(gè)小細(xì)節(jié)值得注意el-dialog組件默認(rèn)關(guān)閉時(shí)會(huì)銷毀彈窗內(nèi)的DOM但它在組件樹(shù)中依然存在。所以彈窗顯隱用v-model控制數(shù)據(jù)回顯要放在open事件回調(diào)里處理而不是mounted里否則首次打開(kāi)彈窗時(shí)數(shù)據(jù)還沒(méi)加載出來(lái)。6.5 基于ECharts實(shí)現(xiàn)數(shù)據(jù)看板的實(shí)戰(zhàn)數(shù)據(jù)看板我用ECharts實(shí)現(xiàn)。ECharts支持Vue3的封裝方式有兩種一種是使用vue-echarts組件庫(kù)一種是在組件里直接引入echarts核心庫(kù)并手動(dòng)初始化圖表實(shí)例。我偏好后者因?yàn)楦`活不受組件庫(kù)封裝的局限。核心代碼如下import * as echarts from echarts const chartRef ref(null) let chartInstance null onMounted(() { chartInstance echarts.init(chartRef.value) loadChartData() }) const loadChartData async () { const data await getGridPopulationStat() chartInstance.setOption({ xAxis: { type: category, data: data.map(d d.gridName) }, yAxis: { type: value }, tooltip: {}, series: [{ type: bar, data: data.map(d d.residentCount), barWidth: 30 }] }) }圖表自適應(yīng)寬度問(wèn)題也提醒一下echarts實(shí)例默認(rèn)尺寸固定如果瀏覽器窗口變化圖表不會(huì)跟著變。需要在window的resize事件里調(diào)用chartInstance.resize()。更優(yōu)做法是用ResizeObserver監(jiān)聽(tīng)容器變化然后執(zhí)行resize。數(shù)據(jù)統(tǒng)計(jì)部分前端只是數(shù)據(jù)的搬運(yùn)工和畫筆難點(diǎn)還是后端SQL怎么算得又快又準(zhǔn)。前文已經(jīng)介紹了匯總表方案這里不再重復(fù)。7. 常見(jiàn)“踩坑”問(wèn)題與排查手冊(cè)7.1 版本不兼容問(wèn)題這個(gè)項(xiàng)目的“坑”一半以上都出在版本上。常見(jiàn)的組合異常有JDK 17 SpringBoot 2.xSpringBoot 2.x官方支持的最高JDK版本其實(shí)是17但部分第三方庫(kù)不兼容比如舊版Lombok版本在JDK 17下編譯報(bào)錯(cuò)升級(jí)Lombok版本可解決。MySQL 8.0 舊版mysql-connector-java驅(qū)動(dòng)類名從com.mysql.jdbc.Driver變成了com.mysql.cj.jdbc.DriverURL需要加serverTimezoneAsia/Shanghai否則報(bào)時(shí)區(qū)錯(cuò)誤。Node.js 18 Vite 4部分版本組合下啟動(dòng)項(xiàng)目會(huì)報(bào)“Node.js version v18.x is not supported”需要升級(jí)Vite版本或改用Node.js 16。SpringBoot 3.x MyBatis-Plus 3.4.xMyBatis-Plus的老版本分頁(yè)插件不兼容Jakarta命名空間需要升級(jí)到3.5.3以上。如果現(xiàn)在開(kāi)始學(xué)新項(xiàng)目建議直接用SpringBoot 3.2 MyBatis-Plus 3.5.6 JDK 17組合這是2024年之后的新主流方向。排查思路很簡(jiǎn)單遇到報(bào)錯(cuò)先看堆棧的第一行識(shí)別是編譯錯(cuò)誤、依賴錯(cuò)誤還是配置錯(cuò)誤依賴錯(cuò)誤優(yōu)先檢查pom.xml中的版本列表配置錯(cuò)誤則檢查application.yml中的數(shù)據(jù)庫(kù)連接、Redis配置等。7.2 跨域問(wèn)題與代理配置前后端分離意味著開(kāi)發(fā)模式下前端跑在5173端口后端跑在8080端口瀏覽器會(huì)攔截跨域請(qǐng)求。解決方式有兩種一是后端配置CORS跨域過(guò)濾器二是前端配置Vite代理。我建議開(kāi)發(fā)環(huán)境用Vite代理生產(chǎn)環(huán)境用Nginx反向代理不給后端增加CORS負(fù)擔(dān)。Vite代理配置如下// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })這樣前端請(qǐng)求/api/user/login會(huì)被代理轉(zhuǎn)發(fā)到http://localhost:8080/api/user/login后端不需要處理CORS。但注意生產(chǎn)環(huán)境部署時(shí)需要將前端構(gòu)建產(chǎn)物dist目錄交給Nginx托管Nginx里配置靜態(tài)文件和反向代理兩個(gè)location塊。后端如果上線到Linux服務(wù)器還需要注意防火墻放行端口以及MySQL和Redis只對(duì)內(nèi)部網(wǎng)絡(luò)開(kāi)放不對(duì)公網(wǎng)暴露。7.3 MyBatis常見(jiàn)的SQL映射問(wèn)題整理我把開(kāi)發(fā)中容易踩的MyBatis問(wèn)題整理成速查表問(wèn)題表現(xiàn)原因解決方式字段找不到BadSqlGrammarExceptionJava字段名與數(shù)據(jù)庫(kù)列名不一致加TableField注解或修改SQL別名查詢結(jié)果為空列表返回空數(shù)組XML中resultType配錯(cuò)類型確認(rèn)resultType是完整的類路徑分頁(yè)失效返回所有數(shù)據(jù)分頁(yè)插件未配置添加PaginationInnerInterceptor配置類自增主鍵不返回插入數(shù)據(jù)后getId()為null主鍵策略未配置實(shí)體類主鍵字段加TableId(type IdType.AUTO)DB連接耗盡Connection is not available連接池參數(shù)太小或連接泄漏調(diào)大最大連接數(shù)、檢查事務(wù)是否正常釋放最常見(jiàn)也最難排查的是連接池耗盡問(wèn)題。典型場(chǎng)景是代碼里手動(dòng)獲取了Connection但沒(méi)有close或者在一個(gè)事務(wù)里執(zhí)行了耗時(shí)很長(zhǎng)的外部接口調(diào)用。排查方式是開(kāi)啟druid的監(jiān)控頁(yè)面看活動(dòng)連接數(shù)和等待次數(shù)結(jié)合慢SQL日志定位出問(wèn)題的接口。7.4 前后端聯(lián)調(diào)中的溝通與數(shù)據(jù)格式約定前后端聯(lián)調(diào)是項(xiàng)目開(kāi)發(fā)中最磨人的環(huán)節(jié)。很多問(wèn)題不是技術(shù)難度大而是前后端約定不統(tǒng)一。我吃過(guò)不少虧總結(jié)了幾條必須在一開(kāi)始就定死的數(shù)據(jù)規(guī)范統(tǒng)一返回格式。后端所有接口統(tǒng)一返回{ code, message, data }結(jié)構(gòu)code為200時(shí)表示成功401表示未認(rèn)證500表示服務(wù)器錯(cuò)誤。前端axios封裝里統(tǒng)一處理。分頁(yè)參數(shù)統(tǒng)一。請(qǐng)求參數(shù)固定用pageNum和pageSize返回結(jié)果固定是{ total, rows }結(jié)構(gòu)。這樣才能在前端封裝一個(gè)useTable組合式函數(shù)所有列表頁(yè)復(fù)用同一套分頁(yè)邏輯。日期格式統(tǒng)一。日期字段后端返回字符串前端展示用dayjs格式化。不要直接傳Date對(duì)象或時(shí)間戳因?yàn)闀r(shí)區(qū)和格式化規(guī)則容易出問(wèn)題前端處理起來(lái)也麻煩。金額和數(shù)值精度。統(tǒng)計(jì)看板中的百分比后端算好返回給前端保留兩位小數(shù)前端不要自己再做浮點(diǎn)運(yùn)算浮點(diǎn)精度問(wèn)題會(huì)坑死人。8. 項(xiàng)目部署上線要點(diǎn)與擴(kuò)展思路8.1 從開(kāi)發(fā)到生產(chǎn)云服務(wù)器部署實(shí)操項(xiàng)目開(kāi)發(fā)完成后上線部署是必經(jīng)之路。我分享一下典型的部署流程。后端打包成jar包上傳到服務(wù)器直接nohup java -jar community-admin.jar --spring.profiles.activeprod 運(yùn)行。注意要新建一個(gè)prod的application-prod.yml配置文件里面生產(chǎn)環(huán)境的數(shù)據(jù)庫(kù)連接、日志路徑、文件上傳路徑都要和開(kāi)發(fā)環(huán)境區(qū)分開(kāi)。前端打包是執(zhí)行npm run build生成dist目錄。把dist目錄上傳到Nginx的html目錄下配置一個(gè)server塊server { listen 80; server_name your-domain.com; location / { root /var/www/community; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html;這行很重要因?yàn)閂ue Router是history模式刷新非首頁(yè)路徑時(shí)Nginx要能找到index.html否則會(huì)出現(xiàn)404。如果不想處理這個(gè)問(wèn)題也可以改用hash模式URL中會(huì)多一個(gè)/#/不利于SEO但布配置簡(jiǎn)單。數(shù)據(jù)庫(kù)上線時(shí)要注意備份策略。我用的是mysqldump做每日凌晨全量備份再配合binlog做增量恢復(fù)。社區(qū)網(wǎng)格化的數(shù)據(jù)量級(jí)通常不大每日全量備份足夠不需要復(fù)雜的備份方案。8.2 安全加固與性能優(yōu)化上線后第一件事是改數(shù)據(jù)庫(kù)密碼和JWT密鑰。項(xiàng)目里默認(rèn)的密鑰一定要改不然等于裸奔。生產(chǎn)環(huán)境的MySQL建議用專門的賬號(hào)而不是root連接應(yīng)用這個(gè)賬號(hào)只授予應(yīng)用需要的庫(kù)的增刪改查權(quán)限。JWT密鑰建議用隨機(jī)生成的256位字符串配置在服務(wù)器的環(huán)境變量里不進(jìn)代碼倉(cāng)庫(kù)。接口層面做防SQL注入。MyBatis的${}存在注入風(fēng)險(xiǎn)能用#{}的地方絕對(duì)不用${}。確實(shí)需要?jiǎng)討B(tài)表名、動(dòng)態(tài)排序字段的場(chǎng)景用白名單校驗(yàn)比如排序字段只能從允許列表里取值。性能方面最大的收益往往來(lái)自緩存。社區(qū)網(wǎng)格化平臺(tái)里像數(shù)據(jù)字典、網(wǎng)格樹(shù)形結(jié)構(gòu)這種讀多寫少的數(shù)據(jù)非常適合用Redis做緩存。查詢時(shí)先查Redis緩存沒(méi)有再去查MySQL再回填緩存。這個(gè)項(xiàng)目目前是用SpringBoot默認(rèn)的本地緩存Caffeine如果后期并發(fā)量上來(lái)?yè)Q成Redis也很簡(jiǎn)單。8.3 項(xiàng)目擴(kuò)展方向工作流引擎與移動(dòng)端這套系統(tǒng)后期可以往兩個(gè)方向擴(kuò)展。一是集成Flowable工作流引擎把事件流轉(zhuǎn)從“寫死的狀態(tài)機(jī)”升級(jí)為“可視化的流程定義”。網(wǎng)格化平臺(tái)的很多流程不是固定的比如疫情時(shí)期的特殊事件處理流程和要求平時(shí)不同用代碼改狀態(tài)機(jī)邏輯會(huì)很痛苦但用Flowable只需要改流程定義文件BPMN重新部署流程即可。這也是熱詞里SpringBoot使用Flowable的出處。二是移動(dòng)端。網(wǎng)格員日常工作場(chǎng)景是在戶外不可能背著電腦?？梢杂肰ue3的移動(dòng)端適配方案做H5版本也可以基于uni-app把前端代碼編譯成小程序。后端接口是現(xiàn)成的移動(dòng)端只需要重新做一套UI層工作量可控。我個(gè)人試下來(lái)的體會(huì)是網(wǎng)格化平臺(tái)真正的難點(diǎn)不是技術(shù)而是對(duì)業(yè)務(wù)邊界的理解。事件狀態(tài)設(shè)計(jì)合不合理、數(shù)據(jù)權(quán)限劃分精不精準(zhǔn)、統(tǒng)計(jì)口徑對(duì)不對(duì)這些業(yè)務(wù)細(xì)節(jié)決定了系統(tǒng)上線后是“天天被夸”還是“天天被罵”。所以做這套項(xiàng)目時(shí)建議別急著堆功能先花時(shí)間把“一個(gè)網(wǎng)格員的日常一天”走一遍把他要錄入什么、要查什么、要審什么梳理清楚再動(dòng)手寫代碼。技術(shù)是為業(yè)務(wù)流程服務(wù)的這個(gè)順序搞反了代碼寫得再漂亮也是自嗨。