手里這套“Java SpringBootVue3MyBatis 疾病防控綜合系統(tǒng)”源碼我自己斷斷續(xù)續(xù)改了大概三周。做之前以為就是個(gè)普通的管理系統(tǒng)真正動(dòng)手才發(fā)現(xiàn)疾病防控這個(gè)業(yè)務(wù)場(chǎng)景比一般的CRUD系統(tǒng)難在數(shù)據(jù)流轉(zhuǎn)和狀態(tài)管理上病例從發(fā)現(xiàn)、上報(bào)、審核、復(fù)核到轉(zhuǎn)歸每一步都有嚴(yán)格的流程要求而且報(bào)表統(tǒng)計(jì)、趨勢(shì)分析這類需求特別多。如果你正準(zhǔn)備拿這套源碼做畢業(yè)設(shè)計(jì)、面試項(xiàng)目或者想自己從零搭一套前后端分離管理系統(tǒng)那這篇文章應(yīng)該能幫你少踩不少坑。先說(shuō)明一下整個(gè)系統(tǒng)的骨架后端是SpringBoot 2.7 MyBatis MySQL 8.0前端是Vue3 Vite Element Plus前后端完全分離通過(guò)RESTful API通信鑒權(quán)用的是JWT。這個(gè)技術(shù)棧組合在當(dāng)前Java全棧項(xiàng)目里算比較主流既不會(huì)太老也沒(méi)有激進(jìn)到會(huì)給新手造成額外負(fù)擔(dān)。這套系統(tǒng)我實(shí)際跑下來(lái)的感受是功能模塊完整度很高健康檔案、風(fēng)險(xiǎn)上報(bào)、流調(diào)記錄、物資臺(tái)賬、數(shù)據(jù)分析看板、用戶權(quán)限管理都有代碼結(jié)構(gòu)也清晰適合二次開發(fā)和擴(kuò)展。下面我按實(shí)際開發(fā)順序把整個(gè)系統(tǒng)的設(shè)計(jì)思路、核心實(shí)現(xiàn)和踩坑過(guò)程詳細(xì)拆開講。1. 項(xiàng)目整體設(shè)計(jì)與技術(shù)棧選型為什么我最終選了這套組合1.1 從需求反推技術(shù)選型先聊選型。很多人上來(lái)就糾結(jié)“SpringBoot還是SSM”“Vue3還是Vue2”但我的習(xí)慣是先看業(yè)務(wù)。疾病防控綜合系統(tǒng)這類項(xiàng)目核心需求可以拆成三塊一是多角色數(shù)據(jù)上報(bào)和審核二是大量病例數(shù)據(jù)的登記和檢索三是基于時(shí)間維度的統(tǒng)計(jì)分析和可視化。這三塊需求決定了技術(shù)選型的方向。后端用SpringBoot幾乎是必然選擇社區(qū)生態(tài)成熟自動(dòng)配置大大減少了XML配置的繁瑣程度內(nèi)嵌Tomcat也省去了單獨(dú)部署Web服務(wù)器的步驟。MyBatis則是因?yàn)檫@類業(yè)務(wù)系統(tǒng)SQL復(fù)雜動(dòng)態(tài)條件檢索多用MyBatis可以在XML里精細(xì)控制SQL比JPA那種“幫你生成好一切”的方式更可控也更容易排查性能問(wèn)題。MySQL做數(shù)據(jù)庫(kù)不用多說(shuō)開源免費(fèi)、部署簡(jiǎn)單、性能足夠。前端選Vue3而不是Vue2核心原因是Composition API在復(fù)雜業(yè)務(wù)頁(yè)面里的組織能力更強(qiáng)而且Vite構(gòu)建速度比Webpack快一個(gè)量級(jí)開發(fā)體驗(yàn)完全不一樣。Element Plus作為Vue3對(duì)應(yīng)的組件庫(kù)表格、表單、日期選擇器這些后臺(tái)管理常用的組件都很齊全能省不少時(shí)間。這里順便說(shuō)下這套系統(tǒng)的數(shù)據(jù)可視化看板用的是ECharts。市面上有些系統(tǒng)會(huì)集成大而全的DataV、AntV等可視化框架但ECharts按需引入后體積可控、文檔全、網(wǎng)上示例多在這個(gè)體量下性價(jià)比是最高的。1.2 前后端分離的分工與模塊規(guī)劃前后端分離這個(gè)詞很多人掛在嘴邊但真正落地時(shí)容易分不干凈。我的劃分原則很簡(jiǎn)單后端只負(fù)責(zé)數(shù)據(jù)和業(yè)務(wù)規(guī)則前端只負(fù)責(zé)交互和展示。比如“審核病例”這個(gè)操作后端接口只接收病例ID和審核結(jié)果返回成功或失敗至于審核按鈕怎么渲染、彈窗怎么寫都是前端的事。系統(tǒng)功能模塊按業(yè)務(wù)域可以拆成這幾塊健康檔案管理人員基本信息、聯(lián)系方式、健康狀況、既往病史等基礎(chǔ)信息維護(hù)。風(fēng)險(xiǎn)監(jiān)測(cè)與上報(bào)疑似/確診情況的上報(bào)、審核、復(fù)核支持批量導(dǎo)入。流調(diào)信息管理病例活動(dòng)軌跡、密切接觸者關(guān)聯(lián)、流調(diào)報(bào)告附件。物資管理防護(hù)物資、消殺物資、藥品的入庫(kù)、出庫(kù)、庫(kù)存預(yù)警。數(shù)據(jù)分析看板按地區(qū)、時(shí)間、人群維度統(tǒng)計(jì)新增、治愈、轉(zhuǎn)歸等指標(biāo)。系統(tǒng)管理用戶、角色、菜單、字典、操作日志。模塊劃分清楚之后前后端并行開發(fā)就很順暢。我在實(shí)際開發(fā)時(shí)先定接口文檔前端用Mock數(shù)據(jù)先行開發(fā)后端按照接口文檔同步開發(fā)最后聯(lián)調(diào)時(shí)問(wèn)題就少很多。1.3 權(quán)限模型RBAC與多角色數(shù)據(jù)隔離權(quán)限設(shè)計(jì)是這類系統(tǒng)的重頭戲。疾病防控系統(tǒng)角色天然就多系統(tǒng)管理員、疾控中心人員、醫(yī)療機(jī)構(gòu)上報(bào)員、基層排查人員、只讀訪客等。我采用的是一套標(biāo)準(zhǔn)的RBAC基于角色的訪問(wèn)控制模型用戶關(guān)聯(lián)角色、角色關(guān)聯(lián)菜單和操作權(quán)限同時(shí)給每個(gè)用戶掛一個(gè)數(shù)據(jù)歸屬單位字段用單位ID做數(shù)據(jù)隔離。數(shù)據(jù)隔離這塊容易踩坑。比如市級(jí)賬號(hào)應(yīng)該能看到下轄區(qū)縣的數(shù)據(jù)而區(qū)縣級(jí)賬號(hào)只能看本區(qū)的數(shù)據(jù)。如果只做菜單權(quán)限就會(huì)出“越權(quán)查看”的問(wèn)題。我的處理方式是在后端查詢時(shí)自動(dòng)拼接單位層級(jí)條件核心SQL強(qiáng)制帶上WHERE unit_id IN (SELECT id FROM unit WHERE path LIKE xxx%)這類條件從接口層規(guī)避數(shù)據(jù)越權(quán)。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)疾病防控系統(tǒng)的核心其實(shí)是表結(jié)構(gòu)2.1 主業(yè)務(wù)表拆解與關(guān)系設(shè)計(jì)這類系統(tǒng)的技術(shù)難點(diǎn)不在增刪改查而在表結(jié)構(gòu)能不能支撐復(fù)雜業(yè)務(wù)。我畫完ER圖之后最大的感受是業(yè)務(wù)表可以多但不能亂關(guān)鍵要理清主表和流水表的關(guān)系。以“病例”為例我先建了一張person表保存人員靜態(tài)信息包括姓名、身份證號(hào)、性別、年齡、聯(lián)系電話、現(xiàn)住址等。身份證號(hào)是天然的冪等鍵一個(gè)人只能有一條健康檔案。然后針對(duì)每次上報(bào)建一張report_record流水表記錄上報(bào)時(shí)間、上報(bào)單位、癥狀描述、檢驗(yàn)結(jié)果、風(fēng)險(xiǎn)等級(jí)、審核狀態(tài)、審核意見(jiàn)。這樣設(shè)計(jì)的好處是一個(gè)人可以有多次上報(bào)記錄但只有一條最新?tīng)顟B(tài)既保住了歷史軌跡又方便取“當(dāng)前狀態(tài)”。流調(diào)信息我單獨(dú)建了trace_record表存活動(dòng)軌跡表格數(shù)據(jù)時(shí)間點(diǎn)、地點(diǎn)、停留時(shí)長(zhǎng)、接觸人員類別。每條流調(diào)記錄都關(guān)聯(lián)report_id形成一對(duì)多的關(guān)系。物資表和審批表也都是典型的流水表設(shè)計(jì)這里不展開。2.2 病例狀態(tài)機(jī)用數(shù)據(jù)庫(kù)字段管理業(yè)務(wù)流轉(zhuǎn)這是我做這個(gè)項(xiàng)目收獲最大的一部分。病例狀態(tài)不能靠“改個(gè)字段就完事”得設(shè)計(jì)成狀態(tài)機(jī)。我把狀態(tài)定義為待審核、已審核、待復(fù)核、已復(fù)核、已排除、已轉(zhuǎn)歸。每個(gè)流轉(zhuǎn)節(jié)點(diǎn)在業(yè)務(wù)代碼里都做合法性校驗(yàn)比如“已排除”的病例不能直接跳到“已轉(zhuǎn)歸”必須經(jīng)過(guò)復(fù)核環(huán)節(jié)。具體到數(shù)據(jù)庫(kù)設(shè)計(jì)我的做法是在report_record表里加兩個(gè)字段status當(dāng)前狀態(tài)和version樂(lè)觀鎖版本號(hào)。更新時(shí)使用UPDATE report_record SET status #{newStatus}, version version 1 WHERE id #{id} AND version #{oldVersion}這樣能防止并發(fā)操作導(dǎo)致?tīng)顟B(tài)錯(cuò)亂。這個(gè)設(shè)計(jì)在多人同時(shí)審核的場(chǎng)景下非常重要實(shí)戰(zhàn)中真的遇到過(guò)兩個(gè)審核員同時(shí)審?fù)环萆蠄?bào)、導(dǎo)致舊數(shù)據(jù)覆蓋新數(shù)據(jù)的情況。2.3 查詢優(yōu)化與索引設(shè)計(jì)疾病防控系統(tǒng)的查詢有一個(gè)特點(diǎn)列表頁(yè)條件多但每次查詢的數(shù)據(jù)量其實(shí)有限。我建索引的原則是“先滿足等值查詢?cè)賰?yōu)化范圍查詢”。核心表索引設(shè)計(jì)供參考person表id_card建唯一索引name建普通索引unit_id建普通索引。report_record表person_id建索引report_time建復(fù)合索引(unit_id, report_time)。trace_record表report_id建普通索引activity_time建普通索引。索引不是越多越好寫多讀少的表索引多了反而拖慢插入速度。我實(shí)際測(cè)試過(guò)優(yōu)化索引后百萬(wàn)級(jí)數(shù)據(jù)量下復(fù)合條件查詢基本穩(wěn)定在200ms以內(nèi)完全夠用。另外所有狀態(tài)字段我用TINYINT存數(shù)字枚舉值不用字符串這樣既能節(jié)省空間查詢也更快但需要在代碼里維護(hù)好枚舉映射關(guān)系。3. 后端實(shí)現(xiàn)SpringBoot MyBatis的落地細(xì)節(jié)3.1 工程分層與JWT認(rèn)證后端工程我按標(biāo)準(zhǔn)的三層結(jié)構(gòu)組織controller接口層、service業(yè)務(wù)層、mapper數(shù)據(jù)訪問(wèn)層另外加entity、dto、vo三層對(duì)象模型。一個(gè)容易被忽略的細(xì)節(jié)是entity對(duì)應(yīng)數(shù)據(jù)庫(kù)表結(jié)構(gòu)dto接收前端參數(shù)vo返回前端數(shù)據(jù)三者不能混用。很多初學(xué)者喜歡一個(gè)實(shí)體類走天下圖省事結(jié)果頁(yè)面多一個(gè)字段就報(bào)錯(cuò)后面維護(hù)起來(lái)非常痛苦。認(rèn)證用的是JWT流程是登錄成功后后端生成token返回給前端前端把token存到localStorage每次請(qǐng)求在請(qǐng)求頭帶Authorization: Bearer token后端攔截器校驗(yàn)token并解析出用戶信息和權(quán)限列表。JWT的過(guò)期時(shí)間我設(shè)的是12小時(shí)同時(shí)做了token續(xù)期邏輯在過(guò)期前1小時(shí)內(nèi)訪問(wèn)接口就自動(dòng)發(fā)新token。這里注意JWT的密鑰必須放到application.yml的獨(dú)立配置項(xiàng)里別硬編碼在代碼里。3.2 MyBatis動(dòng)態(tài)SQL復(fù)雜查詢的殺手锏MyBatis最大的優(yōu)勢(shì)就是動(dòng)態(tài)SQL。疾病防控系統(tǒng)的查詢條件極多比如病例列表要支持按姓名模糊查詢、按狀態(tài)篩選、按時(shí)間范圍篩選、按風(fēng)險(xiǎn)等級(jí)篩選而且這些條件可以任意組合。用if標(biāo)簽可以很優(yōu)雅地解決select idselectReportList resultTypecom.example.vo.ReportVO SELECT r.id, p.name, p.id_card, r.status, r.risk_level, r.report_time, r.audit_status FROM report_record r LEFT JOIN person p ON r.person_id p.id where if testname ! null and name ! AND p.name LIKE CONCAT(%, #{name}, %) /if if teststatus ! null AND r.status #{status} /if if teststartTime ! null AND r.report_time gt; #{startTime} /if if testendTime ! null AND r.report_time lt; #{endTime} /if /where ORDER BY r.report_time DESC LIMIT #{offset}, #{pageSize} /select用where標(biāo)簽的好處是它自動(dòng)處理掉第一個(gè)條件前面的AND不用自己寫WHERE 11這種丑寫法。每次看到初學(xué)者寫WHERE 11我都會(huì)勸改掉雖然結(jié)果一樣但可讀性和執(zhí)行計(jì)劃都有差異。還有一個(gè)容易踩坑的點(diǎn)是if teststatus ! null判斷的是Java屬性如果入?yún)⑹前b類型一定要判斷是否為空否則MyBatis會(huì)報(bào)There is no getter for property named xxx之類的異常。另外需要先判斷狀態(tài)字段是否是空字符串時(shí)用status ! null and status ! 兩個(gè)條件都不能少。3.3 大名單上報(bào)場(chǎng)景下的批量插入優(yōu)化疾病防控系統(tǒng)有一個(gè)高頻操作批量上報(bào)。可能是幾十條也可能是一次性上千條人員名單導(dǎo)入。最開始我用循環(huán)單條插入結(jié)果導(dǎo)入2000條數(shù)據(jù)花了將近10秒根本沒(méi)法用。后來(lái)改成MyBatis的foreach批量插入性能提升非常明顯insert idbatchInsert parameterTypelist INSERT INTO report_record ( person_id, status, risk_level, report_time, report_unit_id, symptom_desc, create_time ) VALUES foreach collectionlist itemitem separator, (#{item.personId}, #{item.status}, #{item.riskLevel}, #{item.reportTime}, #{item.reportUnitId}, #{item.symptomDesc}, NOW()) /foreach /insert2000條數(shù)據(jù)的插入時(shí)間從10秒降到了1秒左右效果立竿見(jiàn)影。但這里有兩個(gè)坑必須注意一是MySQL默認(rèn)會(huì)校驗(yàn)max_allowed_packet超過(guò)這個(gè)大小的SQL會(huì)被拒絕批量插入條數(shù)過(guò)多時(shí)需要調(diào)大該參數(shù)二是foreach拼接SQL有長(zhǎng)度限制我實(shí)際測(cè)試單批500條比較安全數(shù)據(jù)量大時(shí)分批提交。如果你使用的是MyBatis-Plus它有內(nèi)置的saveBatch方法底層同樣走批量插入但有一個(gè)配置項(xiàng)需要留意JDBC連接串要加上rewriteBatchedStatementstrue否則預(yù)編譯語(yǔ)句不會(huì)真正合并執(zhí)行MyBatis-Plus的批量插入性能提升會(huì)大打折扣。這套源碼用的是原生MyBatis也值得了解這一點(diǎn)方便以后遷移。3.4 啟動(dòng)項(xiàng)與配置文件里的幾個(gè)坑這部分要重點(diǎn)說(shuō)因?yàn)槲以谶@上面浪費(fèi)了不少時(shí)間。SpringBoot版本問(wèn)題在熱詞里頻繁出現(xiàn)確實(shí)是個(gè)高頻坑。之前遇到過(guò)SpringBoot 3.x版本配JDK 8啟動(dòng)直接報(bào)錯(cuò)的場(chǎng)景因?yàn)镾pringBoot 3.0開始強(qiáng)制要求JDK 17以上。如果你本機(jī)裝的是JDK 8老老實(shí)實(shí)用SpringBoot 2.7.x別追新版本。版本號(hào)不是越高越好而是要和JDK版本匹配。另一個(gè)坑是首次啟動(dòng)Maven依賴下載卡在downloading...不動(dòng)。原因是默認(rèn)走了Maven中央倉(cāng)庫(kù)國(guó)內(nèi)網(wǎng)絡(luò)訪問(wèn)慢。解決辦法是在settings.xml里配置阿里云鏡像倉(cāng)庫(kù)mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共倉(cāng)庫(kù)/name urlhttps://maven.aliyun.com/repository/public/url /mirror配置完之后依賴下載速度直接翻幾倍。還有java: OutOfMemoryError: Insufficient Memory這個(gè)問(wèn)題多半是IDEA里Maven編譯時(shí)內(nèi)存不夠。解決辦法是在Help - Change Memory Settings里調(diào)大IDEA的堆內(nèi)存同時(shí)在maven的VM options里加-Xmx1024m。如果是運(yùn)行SpringBoot應(yīng)用爆內(nèi)存則在啟動(dòng)配置的VM options里調(diào)整-Xms256m -Xmx512m能緩解大部分內(nèi)存不足的情況。3.5 自定義Banner一個(gè)提升體驗(yàn)的小細(xì)節(jié)熱詞里出現(xiàn)了“springboot banner生成器”這里順帶說(shuō)一個(gè)提升項(xiàng)目格調(diào)的小技巧。SpringBoot啟動(dòng)時(shí)默認(rèn)打印的那個(gè)Spring圖案太單調(diào)了你可以去網(wǎng)上搜“Spring Boot Banner Generator”在線生成一段ASCII藝術(shù)字把生成的內(nèi)容保存到src/main/resources/banner.txt里。啟動(dòng)項(xiàng)目時(shí)就會(huì)顯示你自定義的圖案比如系統(tǒng)名稱。這個(gè)操作不復(fù)雜但要提醒一句banner.txt不要用中文部分終端對(duì)中文ASCII藝術(shù)字的顯示寬度處理不一致會(huì)出現(xiàn)錯(cuò)位。我用過(guò)一次中文直接亂碼后來(lái)全換成英文才正常。4. 前端實(shí)戰(zhàn)Vue3 Element Plus的實(shí)施記錄4.1 前端工程初始化與目錄規(guī)劃前端我用Vite創(chuàng)建Vue3項(xiàng)目命令是npm create vitelatest frontend -- --template vue然后安裝element-plus、axios、vue-router、pinia、echarts這幾個(gè)核心依賴。Vite項(xiàng)目的驅(qū)動(dòng)速度比Webpack快太多了熱更新基本是秒級(jí)開發(fā)體驗(yàn)提升明顯。目錄規(guī)劃供參考src/ ├── api/ # 接口請(qǐng)求封裝 ├── assets/ # 靜態(tài)資源 ├── components/ # 通用組件 ├── layout/ # 布局組件 ├── router/ # 路由配置 ├── stores/ # pinia狀態(tài)管理 ├── utils/ # 工具函數(shù) └── views/ # 頁(yè)面組件這里有一個(gè)實(shí)操建議api目錄下每個(gè)模塊單獨(dú)建一個(gè)文件比如report.js、person.js、equipment.js文件里導(dǎo)出一個(gè)個(gè)方法對(duì)應(yīng)后端接口。不要在頁(yè)面上直接寫axios.get(/api/xxx)否則接口一多、地址一變改起來(lái)想哭。4.2 組合式APIcomputed、watch與hooks復(fù)用Vue3開發(fā)讓我最舒服的是Composition API。以前Vue2里業(yè)務(wù)邏輯分散在data、methods、watch這些選項(xiàng)里遇到復(fù)雜頁(yè)面要反復(fù)上下拖動(dòng)找代碼。現(xiàn)在可以按業(yè)務(wù)維度組織script setup import { ref, computed, onMounted } from vue import { getReportList } from /api/report const loading ref(false) const tableData ref([]) const queryParams ref({ status: null, keyword: , pageNum: 1, pageSize: 10 }) const total ref(0) const isFiltering computed(() { return queryParams.value.status ! null || queryParams.value.keyword ! }) async function fetchList() { loading.value true try { const res await getReportList(queryParams.value) tableData.value res.data.records total.value res.data.total } finally { loading.value false } } async function handleReset() { queryParams.value { status: null, keyword: , pageNum: 1, pageSize: 10 } await fetchList() } onMounted(fetchList) /scriptcomputed在這里用來(lái)派生“當(dāng)前是否處于篩選狀態(tài)”這種依賴其他響應(yīng)式數(shù)據(jù)自動(dòng)更新的邏輯在Vue2的computed里也有但配合script setup寫法整體代碼量少了很多。搜索、重置、分頁(yè)、刷新這幾個(gè)操作通過(guò)統(tǒng)一調(diào)用fetchList來(lái)更新表格邏輯鏈路很清晰。條件渲染也需要注意一點(diǎn)Vue3中動(dòng)態(tài)表格列和表單域很多人在v-for和v-if同時(shí)用在一處時(shí)收到編譯警告。它們的優(yōu)先級(jí)在Vue3里和Vue2不一樣同元素上同時(shí)使用很容易產(chǎn)生邏輯問(wèn)題。我的建議是要么拆層標(biāo)簽要么用computed先過(guò)濾再遍歷不要在同一元素上同時(shí)寫。4.3 兩個(gè)高頻樣式與組件問(wèn)題用Element Plus做后臺(tái)管理會(huì)遇到兩個(gè)高頻問(wèn)題一是修改Tabs標(biāo)簽頁(yè)樣式二是富文本編輯器兼容性。Tabs標(biāo)簽頁(yè)樣式定制需要檢查瀏覽器渲染出來(lái)的class名稱在style langscss scoped里直接用:deep()穿透樣式隔離即可。比如想改Tab的選中色:deep(.el-tabs__item.is-active) { color: #2f6fed; font-weight: 600; }:deep()是Vue3處理scoped樣式穿透的標(biāo)準(zhǔn)寫法Vue2里用的/deep/和在Vue3里不建議使用。富文本編輯器這塊要重點(diǎn)提一下熱詞里出現(xiàn)了“vue-quill-editor vue3”這里有個(gè)很常見(jiàn)的坑。vue-quill-editor這個(gè)庫(kù)主要為Vue2設(shè)計(jì)在Vue3里使用會(huì)有兼容性問(wèn)題。我的建議是不要硬折騰直接換用其他支持Vue3的方案。我當(dāng)時(shí)采用的方案是直接封裝Quill或者換成vueup/vue-quill安裝后注冊(cè)組件直接使用省心很多import { QuillEditor } from vueup/vue-quill import vueup/vue-quill/dist/vue-quill.snow.css4.4 路由權(quán)限與動(dòng)態(tài)菜單前端權(quán)限控制的通用做法是登錄成功后后端返回當(dāng)前用戶的角色和菜單列表前端動(dòng)態(tài)注冊(cè)路由并生成側(cè)邊欄菜單。具體實(shí)現(xiàn)是靜態(tài)路由只保留登錄頁(yè)、404頁(yè)等公共頁(yè)面業(yè)務(wù)頁(yè)面全部用router.addRoute()動(dòng)態(tài)添加。這里有一個(gè)體驗(yàn)優(yōu)化的細(xì)節(jié)動(dòng)態(tài)添加路由后用戶直接刷新頁(yè)面會(huì)白屏因?yàn)樗⑿聲r(shí)路由還沒(méi)注冊(cè)完。我的處理是在路由守衛(wèi)里加一個(gè)“路由已初始化”的全局標(biāo)記如果沒(méi)初始化先初始化再放行否則直接放行。類似這種異步路由控制邏輯寫的時(shí)候要注意防止死循環(huán)。router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) return } if (token !store.routerLoaded) { store.generateRoutes().then(() { next({ ...to, replace: true }) }) return } next() })5. 踩坑記錄與排查速查表源碼跑通前一定要看5.1 MySQL環(huán)境相關(guān)mysql安裝教程、mysql安裝配置、mysql下載官網(wǎng)安裝MySQL 8.0時(shí)去官網(wǎng)下載免安裝版或者用安裝包。安裝時(shí)務(wù)必記住root密碼安裝完成后用mysql -uroot -p測(cè)試連接。如果忘記密碼需要通過(guò)skip-grant-tables模式重置過(guò)程比較麻煩盡量一次設(shè)好。使用MySQL Workbench時(shí)連接如果報(bào)Authentication plugin caching_sha2_password錯(cuò)誤是因?yàn)镸ySQL 8.0默認(rèn)認(rèn)證插件和舊客戶端不兼容。要么在Workbench連接配置里改插件要么創(chuàng)建用戶時(shí)指定mysql_native_password。這個(gè)報(bào)錯(cuò)在本地開發(fā)時(shí)非常常見(jiàn)。導(dǎo)入SQL腳本時(shí)如果提示Unknown database需要先建庫(kù)再選擇庫(kù)CREATE DATABASE IF NOT EXISTS disease_control DEFAULT CHARACTER SET utf8mb4;然后USE disease_control;再執(zhí)行SOURCE導(dǎo)入。編碼集推薦統(tǒng)一用utf8mb4能有效避免中文亂碼。MySQL中int 5這類“字段直接參與運(yùn)算”的操作要謹(jǐn)慎。比如統(tǒng)計(jì)累加時(shí)如果字段是INT類型直接在SQL里UPDATE table SET count count 5是沒(méi)問(wèn)題的但要考慮并發(fā)場(chǎng)景下丟更新需要配合行鎖或樂(lè)觀鎖。mysql update語(yǔ)法的坑更新多表時(shí)MySQL的UPDATE JOIN語(yǔ)法和SQL Server、PostgreSQL不太一樣注意表別名別省略。另外更新時(shí)不小心把WHERE去掉會(huì)導(dǎo)致全表更新這種事故我們行業(yè)里叫“生產(chǎn)事故預(yù)制菜”寫更新語(yǔ)句時(shí)先確認(rèn)影響行數(shù)再執(zhí)行。5.2 SpringBoot配置與啟動(dòng)相關(guān)springboot版本太高再次強(qiáng)調(diào)JDK版本決定SpringBoot大版本。JDK 8選2.7.xJDK 17選3.x。如果已經(jīng)用了高版本且不想降就把JDK換到對(duì)應(yīng)版本兩者必須匹配。springboot配置核心配置文件分application.yml和application-dev.yml開發(fā)環(huán)境和生產(chǎn)環(huán)境分開維護(hù)通過(guò)spring.profiles.activedev指定生效環(huán)境。配置數(shù)據(jù)庫(kù)連接時(shí)務(wù)必加上serverTimezoneAsia/ShanghaiuseSSLfalsecharacterEncodingutf8這些參數(shù)避免時(shí)區(qū)錯(cuò)亂和SSL警告。springboot集成mybatis一直報(bào)錯(cuò)最常見(jiàn)的原因是Mapper接口沒(méi)有被Spring容器掃描到。解決辦法是在啟動(dòng)類上加MapperScan(com.example.mapper)或者在每一個(gè)Mapper接口上加Mapper注解。兩個(gè)都加也不會(huì)沖突。這個(gè)錯(cuò)誤報(bào)的“No qualifying bean of type”很典型大家遇到別慌先檢查掃描路徑。eclipse里集成MyBatis報(bào)錯(cuò)排查邏輯同IDEA但要注意Eclipse的JDK編譯級(jí)別默認(rèn)可能比較低需要手動(dòng)調(diào)成1.8。5.3 MyBatis運(yùn)行期問(wèn)題mybatis配置打印開發(fā)階段建議在application.yml里開啟SQL日志觀察每條SQL的執(zhí)行情況mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl生產(chǎn)環(huán)境記得關(guān)掉否則大量日志輸出會(huì)影響性能。如果用的是MyBatis-Plus生態(tài)有l(wèi)og-easy-plus這類插件可以把參數(shù)和結(jié)果集格式化得更易讀不過(guò)原生StdOutImpl也夠用。mybatis if test indexof有朋友問(wèn)if testname.indexOf(張) ! -1能不能這么寫。答案是能indexOf是Java字符串方法在OGNL表達(dá)式里可以調(diào)用。但注意如果name為null直接調(diào)用indexOf會(huì)拋NPE。安全寫法是先判空再用字符序列判斷if testname ! null and name.indexOf(張) ! -1。不過(guò)在SQL里這樣用通常沒(méi)必要直接用LIKE更高效。mybatis緩存MyBatis的一級(jí)緩存默認(rèn)開啟作用域是SqlSession在Spring集成環(huán)境下多次查詢可能共用同一個(gè)SqlSession所以會(huì)出現(xiàn)“修改數(shù)據(jù)后查到的還是舊值”的假象。排查思路是檢查是不是緩存了對(duì)象引用未刷新或者在SQL日志中看是否有新的查詢語(yǔ)句執(zhí)行。二級(jí)緩存如果沒(méi)把握盡量不要開啟分布式部署時(shí)容易出現(xiàn)臟數(shù)據(jù)。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象排查方向推薦解決方式啟動(dòng)依賴下載卡在downloading倉(cāng)庫(kù)訪問(wèn)慢或被墻配置阿里云Mirror見(jiàn)上文啟動(dòng)報(bào)OutOfMemoryErrorIDEA/Maven內(nèi)存不足調(diào)大IDEA設(shè)置里內(nèi)存參數(shù)接口返回401或token失效JWT過(guò)期或密鑰不一致檢查請(qǐng)求頭攜帶token確認(rèn)前后端密鑰一致表格數(shù)據(jù)中文亂碼數(shù)據(jù)庫(kù)/連接串編碼不一致數(shù)據(jù)庫(kù)統(tǒng)一utf8mb4連接串加characterEncodingutf8POST請(qǐng)求跨域報(bào)錯(cuò)前后端分離未配置CORS后端加CORS過(guò)濾器或CrossOrigin生產(chǎn)用Nginx反向代理同源解決批量插入報(bào)PacketTooBigmax_allowed_packet過(guò)小調(diào)大MySQL該參數(shù)并分批插入SQL查詢慢缺索引或條件未走索引EXPLAIN分析執(zhí)行計(jì)劃補(bǔ)充復(fù)合索引最后說(shuō)幾句我個(gè)人的實(shí)操體會(huì)這套系統(tǒng)做下來(lái)我最想分享的一點(diǎn)是技術(shù)棧本身不難難的是把業(yè)務(wù)狀態(tài)梳理清楚。疾病防控系統(tǒng)里大量操作是“改變狀態(tài)”如果一開始沒(méi)把狀態(tài)機(jī)設(shè)計(jì)妥當(dāng)后面加需求時(shí)每一次都要?jiǎng)雍诵倪壿嬙礁脑絹y。所以如果你要二開這套源碼我強(qiáng)烈建議先把數(shù)據(jù)庫(kù)表結(jié)構(gòu)和狀態(tài)流轉(zhuǎn)摸透再下手改業(yè)務(wù)代碼。還有一個(gè)小技巧前端表格里日期格式化反復(fù)用可以封裝成全局過(guò)濾器或者工具函數(shù)。包括接口統(tǒng)一的返回結(jié)構(gòu){ code, msg, data }后端封裝好之后所有接口都走同一套規(guī)范聯(lián)調(diào)效率和穩(wěn)定性都會(huì)明顯提升。另外一個(gè)實(shí)際經(jīng)驗(yàn)是開發(fā)過(guò)程中把a(bǔ)pplication-dev.yml里的MySQL密碼、JWT密鑰等敏感信息與代碼分開維護(hù)不要提交到公共倉(cāng)庫(kù)。我見(jiàn)過(guò)不止一次因?yàn)樵创a連帶數(shù)據(jù)庫(kù)密碼一起泄露出去的案例這個(gè)習(xí)慣越早養(yǎng)成越好。最后說(shuō)個(gè)擴(kuò)展方向。這套系統(tǒng)目前看板主要是桌面端我特別建議你可以往移動(dòng)端適配或消息觸達(dá)方向擴(kuò)展比如病例審核通過(guò)后給上報(bào)人推送一條通知這類需求在實(shí)際業(yè)務(wù)中一定會(huì)出現(xiàn)。要是能往這個(gè)方向做深整個(gè)項(xiàng)目的完整度和面試含金量都會(huì)提高不少。