作為一個常年泡在項目堆里的技術博主我最近在好幾個技術群里看到不少人貼出同一個項目的名字城鄉(xiāng)居民基本醫(yī)療信息管理系統(tǒng)源碼SpringBoot后端加Vue前端配MySQL還特別標注了“可直接運行”。很多同學私信問我這東西到底怎么樣、值不值得下載來研究甚至有人上來就問“能不能幫我跑通”。說真的我看了那么多號稱畢業(yè)設計、課程設計的開源項目這一個方向偏冷門但業(yè)務邏輯一點都不簡單。借著這個機會我把這套城鄉(xiāng)居民基本醫(yī)療信息管理系統(tǒng)完整拆一遍講清楚代碼背后到底藏著什么設計思路怎么在本地把它跑起來以及真正容易踩坑的地方在哪兒。這個系統(tǒng)本質(zhì)上是一個典型的行政區(qū)劃級基層政務業(yè)務系統(tǒng)面向的是城鄉(xiāng)居民基本醫(yī)療的參保登記、繳費核定、報銷結算、待遇查詢等場景。跟常見的電商后臺、博客系統(tǒng)不一樣它的數(shù)據(jù)模型里充滿了居民身份屬性、醫(yī)保批次參數(shù)、報銷比例規(guī)則這類業(yè)務字段對表結構設計、角色權限劃分、前后端數(shù)據(jù)流轉(zhuǎn)的要求都比較高。也正因為它業(yè)務不復雜、又沒有特別畸形的技術坑非常適合用來理解SpringBoot加Vue前后端分離項目的完整閉環(huán)從頁面錄入、接口請求、服務端校驗、數(shù)據(jù)庫讀寫一直到統(tǒng)計匯總。適合的人群也很明確準備做畢設的在校生、剛學完框架想找個中小型實戰(zhàn)項目練手的新人以及想快速搭一個行政管理域業(yè)務原型給領導或客戶演示的開發(fā)者。這個項目跑起來只需要一臺普通開發(fā)電腦不需要高配置。但跑通只是第一步把里面的業(yè)務邏輯吃透才是真收獲。1. 一個看著不起眼的項目為什么值得好好拆一遍很多人第一眼看到“城鄉(xiāng)居民基本醫(yī)療信息管理系統(tǒng)”這種命名第一反應是“這是不是那種很老套的管理系統(tǒng)是不是就用表格堆一堆增刪改查”。我只能說這個刻板印象害人不淺。表面上它確實是一個后臺管理項目但只要你打開數(shù)據(jù)庫表結構看到參保人、家庭成員、繳費批次、報銷申請、補償比例、醫(yī)療機構這幾個核心實體之間的關系你就會明白這類系統(tǒng)的信息量遠大于普通的商品管理。1.1 城鄉(xiāng)居民基本醫(yī)療信息管理系統(tǒng)到底在管什么城鄉(xiāng)居民基本醫(yī)療主要面向的是沒有參加職工基本醫(yī)療的人群比如農(nóng)村居民、城鄉(xiāng)失業(yè)人員、老人和未成年人。這類人群的特點是數(shù)量大、分布散、動態(tài)變化頻繁而且參保狀態(tài)跟戶籍屬性、人員類別、繳費檔次是強綁定的。具體到信息管理系統(tǒng)里面你需要處理的數(shù)據(jù)大體就是幾類參保登記數(shù)據(jù)個人基本信息、身份證號、戶籍地址、參保狀態(tài)、人員類別普通居民、低保對象、特困人員等、繳費檔次。繳費核定數(shù)據(jù)年度繳費批次、每人繳費金額、財政補助金額、繳費時間、是否到賬。報銷結算數(shù)據(jù)門診記錄、住院記錄、發(fā)票金額、目錄內(nèi)費用、報銷比例、實際報銷金額、個人自付金額?；A配置數(shù)據(jù)各級醫(yī)療機構的報銷比例參數(shù)、藥品目錄/診療項目目錄、年度封頂線、起付線。對比一下常見的電商項目商品、訂單、支付這種模型在業(yè)務上相對通用但醫(yī)保繳費和報銷結算的數(shù)據(jù)規(guī)則往往帶有很強的地區(qū)性參數(shù)而且審批、校驗、記錄留痕的環(huán)節(jié)更多。比如報銷申請就要經(jīng)過提交材料、審核錄入、核定金額、財務發(fā)放等多個狀態(tài)節(jié)點。因此這個系統(tǒng)雖然叫“信息管理”本質(zhì)上是一個帶流程性質(zhì)的業(yè)務系統(tǒng)做起來比普通CRUD要復雜一層。1.2 這套技術組合的背后邏輯為什么用SpringBoot加Vue加MySQL而不是其他組合這個問題不只是選型偏好背后有一套很實際的理由。先從后端說。SpringBoot能夠成為這類中小型管理系統(tǒng)最常被選擇的基礎框架核心在于幾個能力Spring IoC容器管理對象Starter機制把常用功能做成開箱即用的依賴內(nèi)嵌Tomcat讓部署變成一條java -jar命令。相較早期用SSH或者JSP做的老系統(tǒng)SpringBoot項目里不需要你手工寫一堆XML配置也不需要你把頁面模板和后端邏輯攪在一起。再配合MyBatis或JPA操作MySQL整個后端可以拆成清晰的層級控制層接收請求、服務層處理業(yè)務、數(shù)據(jù)訪問層操作數(shù)據(jù)庫。再從Vue的角度看。Vue在整個前端技術圈里一直以上手平滑、中文資料多著稱它的雙向綁定和組件化非常適合這類頁面多、表單多的管理系統(tǒng)。管理端要做幾十個頁面如果全部采用傳統(tǒng)模板渲染光JS文件的維護就夠喝一壺。Vue把頁面拆成組件左邊菜單欄、頂部導航、權限路由、表格分頁、表單彈窗這些都是可以復用的組件開發(fā)效率和可讀性都能往上走一大截。最后是MySQL。有人說MySQL是不是太基礎了要不要換PostgreSQL。我的看法是這類系統(tǒng)的數(shù)據(jù)量通?？刂圃趲资f條以內(nèi)MySQL無論是在安裝維護、備份遷移、還是新手上手成本上都會比PostgreSQL更順一些。它自帶的數(shù)據(jù)類型、索引機制以及事務保證已經(jīng)足以應對參保記錄、繳費記錄、報銷記錄的存儲和查詢場景。在真實的政務系統(tǒng)選型里你確實能看到Oracle或者國產(chǎn)數(shù)據(jù)庫但那是出于采購規(guī)范和歷史原因?qū)σ惶组_源學習項目來說MySQL是性價比最高的存在。用一個不那么精確但很好懂的類比SpringBoot是店里的后廚負責接單、洗菜、炒菜Vue是前廳的點餐屏幕和餐桌顧客直接看到菜單、下單、等菜MySQL是后廚的儲物倉庫所有食材和半成品都按規(guī)則碼放在不同的貨架上。前后端分離就是前廳只管展示和交互后廚只管把菜品做好兩個環(huán)節(jié)之間通過一道道菜單傳遞信息。2. 技術選型與系統(tǒng)架構逐個盤搞清楚系統(tǒng)要解決什么問題后再看源碼的時候就要把注意力放在結構上。很多同學拿到項目壓縮包直接就是一頓點擊啟動遇到報錯就發(fā)在群里問。我非常不建議這種跑法。你要先在一個整體的高度上知道每個目錄、每個配置文件是干什么用的這樣即便報錯了也能自己判斷問題出在哪個環(huán)節(jié)。2.1 后端SpringBoot的分層與核心模塊這套系統(tǒng)的后端部分典型的目錄結構大概長這樣src/main/java ├── com.xxx.medical │ ├── controller // 控制層接收HTTP請求 │ ├── service // 業(yè)務層處理核心邏輯 │ ├── mapper // 數(shù)據(jù)訪問層對接數(shù)據(jù)庫 │ ├── entity // 實體類對應數(shù)據(jù)表 │ ├── config // 攔截器、跨域配置、數(shù)據(jù)源配置 │ ├── common // 統(tǒng)一返回結構、異常處理、工具類 │ └── MedicalApplication.java // 啟動類controller這一層做得非常薄只負責接到前端傳過來的參數(shù)、調(diào)用service、把結果包裝成統(tǒng)一結構返回。真正的業(yè)務判斷都在service層比如報銷金額怎么算、參保狀態(tài)能不能變更、重復繳費怎么攔截這些邏輯都不應該塞在controller里面。數(shù)據(jù)層則通過MyBatis的接口跟實體對應如果你拿到的是普通Maven項目你會看到resources目錄下還有一堆mapper XML文件里面寫的是SQL這是MyBatis風格最常見的組織方式。再來看后端提供哪些模塊。核心模塊大致可以分為用戶登錄與權限、參保人信息管理、家庭關系管理、繳費批次管理、繳費記錄管理、報銷申請與審核、參保統(tǒng)計報表。其中每個模塊都可以獨立出控制器和服務這樣代碼可讀性高后期如果要做微服務拆分也能照著模塊邊界去切。關于統(tǒng)一返回結構我多說一句。很多自己寫的demo項目返回給前端的東西非常隨意有時直接返回一個實體對象有時返回一個Map有時又直接返回字符串這樣的話聯(lián)調(diào)階段會被反復扯皮。這類系統(tǒng)一般會封裝一個Result對象里面放著code、message、data三個字段。前端拿到響應之后先判斷code是否等于200再做后續(xù)操作。有一個統(tǒng)一的返回約定前后端協(xié)作的溝通成本會低很多。2.2 前端Vue的雙角色界面前端部分基于Vue開發(fā)的話常見的項目結構是使用Vue CLI或Vite創(chuàng)建的單頁應用。管理系統(tǒng)的頁面通常分成兩類使用場景一類是系統(tǒng)管理員/經(jīng)辦人員使用的管理后臺另一類是參保居民自己使用的查詢與申請界面。這兩類角色的菜單、頁面、功能都有很大的區(qū)別。管理后臺端一般包括登錄頁、首頁工作臺、參保人管理、保障家庭管理、繳費管理、報銷審核管理、系統(tǒng)用戶管理和系統(tǒng)配置。頁面以表格、搜索表單、狀態(tài)篩選為主并配合新增、編輯、刪除、導出的操作彈窗。這個角色的核心訴求是“錄入、批量處理、審核、留痕”。居民用戶端相對簡單一般包括個人參保信息查看、家庭成員綁定、繳費記錄查看、報銷進度查詢、報銷申請發(fā)起。這個角色的核心訴求是“能不能少跑腿、能不能查清楚”。這樣一套系統(tǒng)在設計的時候會把前端路由做權限控制管理員登錄后能看到管理菜單普通居民登錄后只能看到個人相關頁面。有一個很容易被忽略的細節(jié)前端頁面的信息展示和后端接口字段一定要對齊。如果后端返回的日期字段是時間戳前端就要做格式化如果后端返回的金額單位是“分”前端展示就要除以100。這類項目跑通之后你最常遇到的就是“接口沒報錯、但頁面顯示不對”的情況基本都是字段名不一致或者單位沒轉(zhuǎn)換。2.3 數(shù)據(jù)庫表結構設計的關鍵數(shù)據(jù)庫設計是這類系統(tǒng)能不能做好的一半。打開SQL腳本或者數(shù)據(jù)庫后你需要重點關注幾張核心表和表之間的關系。第一張是系統(tǒng)用戶表用來存登錄賬號和密碼注意不要把參保人和登錄用戶混成一張表。系統(tǒng)用戶表管的是“能進系統(tǒng)的人”而參保人信息表存的是“醫(yī)療保障的對象”一個人可能是管理員同時也可能是參保家屬但這是兩個維度必須拆開。第二張是參保人表核心字段包括姓名、身份證號、性別、出生日期、戶籍地址、參保狀態(tài)、人員類別、聯(lián)系方式等。身份證號是一個高權重字段由于居民基本醫(yī)療按人管理同一人重復參?；蛘呖绲貐^(qū)重復參保都是要避免的事情所以這張表上通常會對身份證號建唯一索引。第三張是繳費記錄表關聯(lián)字段包括參保人ID、繳費年度、繳費檔次、個人繳費金額、財政補助金額、繳費狀態(tài)、繳費時間。養(yǎng)老保險和醫(yī)療保險的繳費體系在細節(jié)上各有不同但在管理系統(tǒng)層面都要能實現(xiàn)“按年度繳費、按人核銷”的邏輯。第四張是報銷申請表這個表是整個系統(tǒng)業(yè)務鏈條最長的表。字段包括參保人ID、醫(yī)院名稱、就診開始時間和結束時間、總費用、目錄內(nèi)費用、起付線、報銷比例、報銷金額、個人自付金額、審核狀態(tài)、審核人等。報銷涉及的字段非常多經(jīng)常有人把本地自付和目錄內(nèi)費用搞混這個在數(shù)據(jù)庫層面就要保證計算邏輯正確。另外還有字典表比如醫(yī)院等級字典、費用類別字典、人員類別字典。字典表的存在意義在于避免在前端頁面上寫死各種下拉選項。你以后要改報銷比例分類或人員類別名稱不需要動代碼改數(shù)據(jù)庫里一條記錄就行了。2.4 前后端聯(lián)調(diào)的核心約定前后端分離項目的開發(fā)模式里接口約定決定了整個團隊的工作效率。這套源碼里后端接口一般會統(tǒng)一以/api開頭比如/api/insured/list、/api/payment/save、/api/reimburse/audit。前端在發(fā)起請求的時候會統(tǒng)一指定baseURL開發(fā)環(huán)境通過代理轉(zhuǎn)發(fā)生產(chǎn)環(huán)境通過Nginx反向代理。這里特別想提醒一句很多新手在開發(fā)環(huán)境里直接把前端的請求地址寫成http://localhost:8080這樣確實能通但如果后端接口部署的地址以后變了前端所有請求地址都要改非常麻煩。正確做法是前端用相對路徑/api開頭在vue.config.js或者Vite配置里加一個開發(fā)代理把/api轉(zhuǎn)發(fā)到后端的localhost:8080。這樣你以后把前端打包扔到任何一臺服務器上只需要配置Nginx轉(zhuǎn)發(fā)規(guī)則不用改前端代碼。登錄態(tài)的保持也是前后端協(xié)作的核心之一。常見方案是基于SpringBoot的攔截器加Token校驗前端登錄成功后把Token存到本地或者請求頭里。需要注意Token過期后前端要攔截到401狀態(tài)碼自動跳回登錄頁不要讓用戶一直停留在看起來還在線的界面上。3. 本地跑通這套源碼的完整步驟很多文章到了架構講解就停了但我覺得真正費時間的是“怎么把它跑起來”。這里我按照我自己的實踐把從零到一跑通這套城鄉(xiāng)居民基本醫(yī)療信息管理系統(tǒng)的過程拆成具體步驟每個步驟里都有版本要求和注意事項。3.1 環(huán)境準備版本對齊是第一個坑先確認你本機已經(jīng)安裝好了下面這些環(huán)境版本不一定完全一致但至少不能差得太離譜。環(huán)境建議版本說明JDK1.8或11SpringBoot 2.x用1.8沒問題3.x需要17以上先看pom依賴再定Maven3.6用于拉取后端依賴或用IDE內(nèi)置MavenNode.js14.x~18.x前端依賴安裝和構建需要版本太高可能出現(xiàn)兼容問題npm/yarnnpm 6 / yarn 1.x安裝Vue項目依賴MySQL5.7或8.0數(shù)據(jù)庫建議8.0字符集要選utf8mb4這些版本號里面最容易出問題的就是JDK和Node.js。有的電腦上裝著JDK 17但后端項目pom文件里編譯版本還寫的1.8一啟動就會報錯說“無效的目標發(fā)行版”。還有的電腦上Node版本到了20執(zhí)行npm install的時候會報一些內(nèi)部依賴錯誤這種情況要么換Node 16左右的LTS版本要么把npm源切到國內(nèi)鏡像再試。3.2 后端啟動從建庫到登錄第一步是建庫。打開MySQL命令行或者圖形化客戶端執(zhí)行項目里的SQL腳本。這個SQL腳本可能是單個.sql文件也可能是一堆SQL文件按模塊拆開。執(zhí)行之前先檢查腳本開頭有沒有建庫語句比如CREATE DATABASE medical;有的話你就只需要在客戶端里選中作為默認數(shù)據(jù)庫執(zhí)行沒有的話你先手工建一個空庫然后切換過來執(zhí)行。第二步是改配置。找到后端項目里的application.yml或application.properties文件把數(shù)據(jù)庫地址、賬號、密碼改成你自己的。這里多說一句如果你MySQL的密碼含有特殊字符比如或者#在YAML文件里不加引號會導致解析失敗。建議密碼里盡量不要用特殊字符或者在YAML里給密碼加單引號。還要注意URL里的時區(qū)參數(shù)常見寫法是spring: datasource: url: jdbc:mysql://localhost:3306/medical?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456有人不寫serverTimezone也能跑但有可能會在時間字段讀寫的時候產(chǎn)生8小時的偏差。加上Asia/Shanghai就是告訴驅(qū)動用東八區(qū)時間算是最省心的做法。第三步是啟動后端。用IDEA打開項目之后等Maven把依賴拉完直接運行啟動類。如果你的項目不是IDEA打開而是命令行運行可以在項目根目錄執(zhí)行mvn spring-boot:run啟動成功之后控制臺會出現(xiàn)Spring Boot的啟動橫幅和Tomcat端口號默認是8080。為了確認接口真的可用可以在瀏覽器里訪問http://localhost:8080/api/user/info這類接口如果返回的是JSON而不是404說明后端業(yè)務接口已經(jīng)在線了。3.3 前端啟動代理與端口前端部分用IDEA或VS Code打開以后先看目錄里有沒有package.json。在項目根目錄執(zhí)行安裝依賴npm install如果網(wǎng)絡慢建議臨時切換npm源在國內(nèi)環(huán)境下速度提升會非常明顯npm config set registry https://registry.npmmirror.com依賴安裝完以后執(zhí)行npm run serve如果是Vite項目執(zhí)行npm run dev啟動成功以后控制臺會顯示一個本地訪問地址比如http://localhost:8081。注意前端端口和后端端口不要沖突如果前端用了8080后端也用了8080那就是端口起了沖突啟動其中一個就會報Address already in use。前后端配置里通常會有一個用8080另一個用8081或者8082不要強行都改成一個地址。打開前端地址能看到登錄頁就說明前端起來了。輸入系統(tǒng)初始化賬號密碼如果后端也正常就能跳轉(zhuǎn)到首頁。如果登錄按鈕一直轉(zhuǎn)圈或者提示網(wǎng)絡錯誤先按F12打開瀏覽器的開發(fā)者工具看Network面板檢查請求是不是真的發(fā)出去、狀態(tài)碼是不是200、響應體里有沒有報錯。這一步是整個聯(lián)調(diào)過程中排查問題最高頻的手段。3.4 目錄結構速覽與啟動順序總結拿到源碼后不要上來就跑先把目錄結構和依賴配置看一遍。我這里給出一個常見的目錄速覽medical-manage ├── backend // SpringBoot后端 │ ├── src │ ├── pom.xml │ └── sql │ └── medical.sql └── frontend // Vue前端 ├── src ├── package.json └── vue.config.js啟動順序一定是先MySQL再后端最后前端。MySQL沒起來就啟動后端后端會報數(shù)據(jù)庫連接失敗后端沒起來就啟動前端前端頁面能打開但所有接口都會失敗。整個過程做一遍之后你就能在本地跑通一套完整體驗的前后端分離項目。提示首次啟動不要糾結“為什么后端啟動這么慢”SpringBoot要掃描的組件比較多加上Maven還會做依賴加載這很正常。真正需要警覺的是日志里出現(xiàn)紅字異常之后再判斷問題類型。4. 核心業(yè)務實現(xiàn)里的關鍵細節(jié)項目能跑通之后真正有價值的工作才開始。這里我挑幾個我認為在這個項目中值得深挖的細節(jié)也是面試或者答辯時容易被問到的點。4.1 登錄與權限密碼加密和攔截要一起看登錄模塊是每個系統(tǒng)都有的但很多項目在密碼安全上做得不合格。這套系統(tǒng)的后端通常不會用明文存儲密碼而是用MD5加鹽或者BCrypt格式存儲。最簡單的觀察方式是打開數(shù)據(jù)庫用戶表看一下密碼字段的值是不是一串固定長度且不規(guī)則的字符串。如果是說明做了加密如果直接是123456這種說明沒做加密這是安全上的一個明顯缺陷。權限控制上后端一般用攔截器統(tǒng)一處理。SpringBoot中的攔截器要注冊到WebMvcConfigurer里去常見做法是寫一個LoginInterceptor在里面判斷請求頭里的Token是否存在以及是否有效。對于免登錄接口比如前端獲取驗證碼、用戶登錄要在配置文件里排除掉對應的路徑。這里有一個很容易踩的坑攔截器路徑寫得太寬把靜態(tài)資源也攔截了導致前端頁面能打開但圖片加載不出來寫得太窄又會導致有些需要鑒權的接口被任意訪問。如果你要改進這套項目把Token從固定字符串換成JWT是一個很好的升級點。JWT的好處是服務端不需要保存會話狀態(tài)Token本身就帶著用戶的ID和過期時間但缺點是如果用戶修改密碼之前簽發(fā)的Token無法立刻失效。對這個項目來說也可以選擇把Token存到Redis里方便主動踢人或統(tǒng)一失效但需要額外引入Redis依賴從零開始改造會有一點工作量。4.2 報銷結算的計算邏輯比例參數(shù)不能寫死在代碼里城鄉(xiāng)居民基本醫(yī)療的報銷計算是整套系統(tǒng)里最有業(yè)務含金量的一段。報銷金額并不是簡單的“總費用乘以統(tǒng)一比例”。真實的核算過程要考慮起付線、封頂線、目錄內(nèi)費用、報銷比例等多個因素。用公式表示大概是報銷額 (目錄內(nèi)費用 - 起付線) × 報銷比例 個人自付 總費用 - 報銷額而且報銷比例不是固定的跟醫(yī)院等級有關一級醫(yī)院可能報銷85%三級醫(yī)院可能報銷70%跟人員類別也有關低保對象、特困人員往往有更高比例。設計的合理做法是把這些比例配置放到系統(tǒng)參數(shù)表或者字典表里后端在計算時從配置中去取而不是在代碼里硬編碼。很多剛入門的開發(fā)者拿到這類項目時會覺得“報銷金額直接調(diào)一個接口算出來就行”。實際上如果在代碼里直接寫if (hospitalLevel 3) return 0.7那以后醫(yī)院等級調(diào)整比例、或者新增一檔醫(yī)院級別都要改代碼重新部署這在真實項目里是不可接受的。你要做的應該是給報銷比例增加一個可配置的表前端管理員在后臺能修改參數(shù)后端計算時動態(tài)讀取。這樣既鍛煉了你對數(shù)據(jù)建模的理解也讓項目在答辯時更有亮點。4.3 數(shù)據(jù)權限與身份綁定這個系統(tǒng)還有一個容易被忽略的問題數(shù)據(jù)權限。系統(tǒng)中的用戶分為管理員和居民。管理員可以查看所有參保人的信息但居民登錄后應該只能看到自己及家庭成員的記錄。如果后端接口只做了“登錄驗證”而沒做“數(shù)據(jù)歸屬校驗”那一個居民用戶就能遍歷出所有人的身份證號和報銷記錄這是嚴重的數(shù)據(jù)泄露風險。正確做法是查詢參保人詳情的接口除了要求登錄還要比對當前登錄用戶的ID是否等于被查詢的參保人ID或者是該參保人家庭關系中的成員。具體實現(xiàn)方式是在查詢SQL里帶上一個當前用戶ID的過濾條件。這個細節(jié)在很多SSM項目中都沒做但它在真實的系統(tǒng)中是一個硬性需求。如果你是拿這個項目去面試或做畢業(yè)設計把這個點做好絕對是一個明顯的加分項。4.4 前端表格、校驗與狀態(tài)轉(zhuǎn)換再從前端角度說兩個操作細節(jié)。表格頁面是一眼就能看到的普通管理頁面但真正寫得好的表格遠不止調(diào)一個后端列表接口、然后用循環(huán)渲染出來。你需要處理分頁參數(shù)、加載狀態(tài)、空數(shù)據(jù)展示、操作按鈕的權限開關、搜索表單的重置。這套系統(tǒng)里我建議你先重點看繳費記錄列表頁和報銷審核列表頁這兩個頁面涉及最多的狀態(tài)字段比如待繳費、已繳費、待審核、已審核、已駁回不同狀態(tài)下按鈕和標簽顏色都不一樣。表單校驗也是一個細節(jié)密集的地方。身份證號校驗要兼容15位和18位還要能識別最后一位X手機號校驗要符合國內(nèi)號碼規(guī)則日期選擇器要限制結束日期不能早于開始日期。這個系統(tǒng)里身份證號是一個核心主鍵性質(zhì)的字段前端校驗只是第一步后端也必須做同樣的校驗不能只信任前端傳過來的數(shù)據(jù)。5. 啟動運行中的常見問題排查實錄我在這類項目上幫不少人排查過問題下面這些場景是出現(xiàn)頻率最高的我把現(xiàn)象、原因和解決辦法整理成一份速查表?，F(xiàn)象可能的根因處理方式后端啟動報數(shù)據(jù)庫連接失敗MySQL沒啟動、賬號密碼錯誤、URL寫錯、服務端口不對先用客戶端工具測試連通性確認后改application配置后端啟動報端口被占用8080被其他程序占用在配置文件中改用server.port或找占用端口進程殺掉前端頁面能打開登錄請求404前端代理沒配好、后端上下文路徑不一致檢查vue.config.js里的proxy確認是否指向正確的后端地址登錄后返回401Token過期、請求頭沒帶Token、攔截器配置過寬重新登錄檢查axios請求攔截器里的Token設置中文亂碼數(shù)據(jù)庫字符集不是utf8mb4、連接URL沒指定編碼建庫時就指定utf8mb4連接URL加useUnicodetrue和characterEncodingutf8分頁不生效前后端分頁參數(shù)名字不統(tǒng)一檢查pageNum/pageSize/current/size這幾種命名時間顯示差了8小時數(shù)據(jù)庫時區(qū)與JVM時區(qū)不一致連接URL加serverTimezoneAsia/Shanghai前端再格式化npm install報錯Node版本太高或缺少依賴源后端切換到16版本換用npmmirror源再執(zhí)行再補充一個我在實際過程中遇到過的“經(jīng)典陷阱”執(zhí)行SQL腳本時如果MySQL版本是8.0而你的腳本里用了老版本的字段類型或索引寫法執(zhí)行到一半會報錯。解決辦法是先確認腳本針對的MySQL版本如果腳本里出現(xiàn)了ENGINEInnoDB DEFAULT CHARSETutf8在8.0里也能執(zhí)行但如果有PASSWORD()函數(shù)這類老語法就需要手工調(diào)整。還有一次我看到一個同學的數(shù)據(jù)庫里所有表都建好了但頁面查詢時報“表不存在”原因是SQL腳本執(zhí)行時連接到了默認的test庫建表都建到了另一個庫里后端配置的connection庫和建表的庫不是同一個。這種問題排查起來特別容易讓人崩潰所以建庫之前一定要看清當前選中的數(shù)據(jù)庫。前端還有一個非常高發(fā)的點頁面一直白屏打開控制臺顯示Cannot read properties of undefined。這種報錯大部分是某個接口返回的數(shù)據(jù)結構和前端預期不匹配比如后端返回了一條空數(shù)組但前端還是直接取data.list再取第一項data.list[0].name。解決方式是前端做防御性判斷或者梳理接口文檔統(tǒng)一字段。6. 從“能跑”到“會用”后續(xù)擴展建議和個人經(jīng)驗項目跑通、代碼也看明白了并不是終點。我建議你在這個基礎上做一點自己的東西哪怕只是很小的改動也能讓這個項目變成真正屬于你的作品。6.1 基于這套源碼最值得加的三個功能第一個值得加的是數(shù)據(jù)可視化看板?，F(xiàn)在的系統(tǒng)里肯定有參保人數(shù)、繳費金額、報銷金額這些數(shù)據(jù)在首頁用ECharts做幾個統(tǒng)計圖比如按年月展示繳費趨勢、按鄉(xiāng)鎮(zhèn)展示參保人數(shù)、按醫(yī)院等級展示報銷金額占比項目的展示效果立刻上一個檔次。數(shù)據(jù)可視化在前后端分離項目中不需要額外引入太重的內(nèi)容只需要后端寫一個統(tǒng)計接口返回聚合數(shù)據(jù)前端用圖表組件渲染。第二個值得加的是批量導入導出。醫(yī)保系統(tǒng)中從Excel導入?yún)⒈Ｈ诵畔⑹欠浅傂璧牟僮?。你可以用后端解析Excel逐行校驗數(shù)據(jù)格式再批量插入數(shù)據(jù)庫。同時把查詢結果導出為Excel文件這個功能在答辯現(xiàn)場演示的時候效果很好。用EasyExcel或者POI都可以實現(xiàn)建議優(yōu)先用EasyExcel內(nèi)存占用低且API更簡單。第三個值得加的是消息通知。繳費提醒、報銷進度通知這類場景可以通過系統(tǒng)站內(nèi)信或者短信通知實現(xiàn)。作為學習項目可以先做一個站內(nèi)信模塊的新增和已讀功能把通知表接到業(yè)務狀態(tài)變更點上比如報銷審核通過之后自動寫入一條站內(nèi)信。這樣你就把“流程”和“通知”結合起來了而不只是做一個簡單的數(shù)據(jù)庫寫入。6.2 換業(yè)務域復用的思路這套系統(tǒng)的開發(fā)模式也可以快速遷移到其他業(yè)務場景。把“參保人”換成“業(yè)主”把“繳費記錄”換成“物業(yè)費流水”把“報銷申請”換成“維修工單”再把字段名稱改一下你就能很快搭出來一套物業(yè)管理系統(tǒng)。同理換上教師、學生和課程數(shù)據(jù)也能變成校園管理平臺。原因在于這種系統(tǒng)的骨架是通用的一套登錄權限體系加一套主數(shù)據(jù)和從屬記錄的管理模型再加上一條狀態(tài)流程。真正需要重寫的是業(yè)務規(guī)則計算比如報銷比例、起付線、封頂線這種東西換成其他行業(yè)就完全不通用了。所以我在學習任何一套系統(tǒng)源碼的時候都會刻意把“通用骨架”和“行業(yè)規(guī)則”分開看。骨架幫你提升開發(fā)效率而行業(yè)規(guī)則才是你和別人拉開差距的地方。6.3 一點個人體會做這類前后端分離的管理系統(tǒng)我個人最大的體會是跑通一個項目不等于學會一個項目。很多同學第一件事就是一鍵啟動看到界面出來就覺得完事了。但如果你真的把數(shù)據(jù)表一張接一張看過去把報銷計算的步驟用代碼走讀一遍再跟著前端的路由和API請求把一條業(yè)務流串起來這個項目對你的價值會翻好幾倍。我在實際做過的類似系統(tǒng)里踩過不少坑其中印象最深的一次是上線時沒留意前端代理配置導致打包后的靜態(tài)文件發(fā)到服務器上之后所有請求都還在往localhost發(fā)。這個問題看起來低級但在聯(lián)調(diào)和部署階段非常常見。后來我的習慣是前端代碼里永遠不寫死完整后端地址本地用代理生產(chǎn)用Nginx轉(zhuǎn)發(fā)。這個習慣在這套源碼上同樣適用——你以后把它部署到任何環(huán)境只要專配好反向代理就不用翻著前端代碼改請求地址。這套項目本身不算大但它把SpringBoot、Vue和MySQL的組合用法完整串聯(lián)起來了。對想要打牢基礎的人來說靜下心來把里面每一張表、每一個接口、每一步業(yè)務流轉(zhuǎn)都吃透比急著去學微服務和分布式架構要實在得多。最后再分享一個小技巧拿到這類帶源碼的項目先在SQL腳本里看表結構再順著“登錄-參保登記-繳費-報銷”這條主線去讀代碼你的理解速度要比從代碼逐行看快得多。