快到畢業(yè)季了后臺(tái)總有人私信問(wèn)我“藥房購(gòu)藥系統(tǒng)”這類(lèi)題目該怎么下手。作為經(jīng)常幫畢業(yè)生審代碼、理思路的老學(xué)長(zhǎng)我今天就以這套基于JAVA的藥房購(gòu)藥系統(tǒng)為例子把從需求拆解、技術(shù)選型、數(shù)據(jù)庫(kù)設(shè)計(jì)到核心代碼實(shí)現(xiàn)的完整鏈路掰開(kāi)揉碎講一遍。這套系統(tǒng)不只是應(yīng)付答辯你要是真能把它吃透Spring Boot Vue 的前后端分離開(kāi)發(fā)、RBAC權(quán)限模型、訂單狀態(tài)機(jī)這些硬技能都能實(shí)實(shí)在在落到簡(jiǎn)歷上。先給還不清楚狀況的同學(xué)定位一下這是一個(gè)典型的JavaWeb方向的管理信息系統(tǒng)業(yè)務(wù)邊界清晰技術(shù)棧主流特別適合計(jì)算機(jī)專(zhuān)業(yè)、軟件工程、信息管理類(lèi)專(zhuān)業(yè)的畢業(yè)設(shè)計(jì)。系統(tǒng)解決的核心痛點(diǎn)很樸素——傳統(tǒng)藥房靠手工記賬、紙質(zhì)處方管理藥品庫(kù)存靠人工盤(pán)點(diǎn)效期管理靠肉眼排查而這套系統(tǒng)要做的就是把這些線(xiàn)下流程搬到線(xiàn)上實(shí)現(xiàn)藥品信息管理、庫(kù)存預(yù)警、前臺(tái)購(gòu)藥結(jié)算、訂單追蹤、角色權(quán)限控制的一體化閉環(huán)。如果只是隨便找個(gè)開(kāi)源項(xiàng)目改改名字交差那你大概率會(huì)在答辯時(shí)被問(wèn)懵。我這篇博文的目標(biāo)是讓你真正理解每個(gè)設(shè)計(jì)決策背后的原因?yàn)槭裁从唵谓痤~用BigDecimal而不是double為什么用戶(hù)表和角色表要拆開(kāi)為什么庫(kù)存扣減要放在數(shù)據(jù)庫(kù)事務(wù)里做把這些“為什么”搞明白你不僅能順利通過(guò)答辯還能在以后的面試?yán)锒鄮追值讱狻?. 項(xiàng)目整體設(shè)計(jì)與需求拆解1.1 從“購(gòu)藥”到“管藥”一個(gè)完整的業(yè)務(wù)閉環(huán)很多人拿到這個(gè)題目第一反應(yīng)是“這不就是個(gè)網(wǎng)上商城嗎把賣(mài)衣服換成賣(mài)藥不就行了”。這是最大的誤區(qū)。藥房購(gòu)藥系統(tǒng)雖然長(zhǎng)得像電商系統(tǒng)但它的業(yè)務(wù)復(fù)雜度遠(yuǎn)超普通商城核心差異在于三個(gè)地方第一個(gè)差異是藥品的雙重屬性。藥品既是商品也是特殊監(jiān)管對(duì)象它有關(guān)聯(lián)的批準(zhǔn)文號(hào)、生產(chǎn)廠(chǎng)家、批號(hào)、有效期、處方類(lèi)型處方藥與非處方藥、儲(chǔ)存條件這些額外字段。普通商城只需要管理SKU和價(jià)格藥品管理系統(tǒng)必須管理效期和批號(hào)因?yàn)榕R近過(guò)期的藥不能賣(mài)過(guò)了效期的藥必須鎖定下架。第二個(gè)差異是用戶(hù)角色的多樣化。一套完整的藥房系統(tǒng)至少要有四類(lèi)角色管理員管人和管數(shù)據(jù)、藥師審核處方、上下架藥品、收銀員銷(xiāo)售開(kāi)單、普通用戶(hù)瀏覽藥品、下單購(gòu)藥。不同角色看到的界面不同操作的權(quán)限不同這就牽扯到RBAC權(quán)限模型的設(shè)計(jì)。第三個(gè)差異是庫(kù)存精度要求更高。普通商品庫(kù)存少一個(gè)多一個(gè)影響頂多是補(bǔ)貨藥品庫(kù)存出錯(cuò)會(huì)直接影響患者用藥安全。所以庫(kù)存操作必須做事務(wù)控制每次出庫(kù)入庫(kù)都要留操作日志方便事后追溯。搞清楚這三點(diǎn)你再回來(lái)看這個(gè)選題就會(huì)發(fā)現(xiàn)它其實(shí)是個(gè)“麻雀雖小、五臟俱全”的綜合訓(xùn)練——既有常規(guī)CRUD又有權(quán)限控制、事務(wù)處理、狀態(tài)流轉(zhuǎn)、報(bào)表統(tǒng)計(jì)該有的難點(diǎn)全都有。1.2 核心需求逐條拆解我習(xí)慣先畫(huà)功能樹(shù)再寫(xiě)代碼。這套系統(tǒng)的功能規(guī)劃大致如下前臺(tái)用戶(hù)端針對(duì)普通購(gòu)藥用戶(hù)用戶(hù)注冊(cè)、登錄、個(gè)人信息維護(hù)、密碼修改藥品分類(lèi)瀏覽、關(guān)鍵字搜索、藥品詳情查看含說(shuō)明書(shū)、用法用量購(gòu)物車(chē)管理加入、修改數(shù)量、刪除、批量結(jié)算提交訂單、在線(xiàn)模擬支付、查看訂單狀態(tài)與歷史訂單常見(jiàn)問(wèn)題FAQ與留言反饋后臺(tái)管理端針對(duì)管理員、藥師、收銀員登錄認(rèn)證與基于角色的菜單權(quán)限控制藥品管理增刪改查、上架/下架、藥品圖片上傳、效期預(yù)警分類(lèi)管理藥品類(lèi)別維護(hù)支持二級(jí)分類(lèi)庫(kù)存管理入庫(kù)登記、出庫(kù)登記、庫(kù)存盤(pán)點(diǎn)、低庫(kù)存預(yù)警訂單管理訂單列表篩選、訂單狀態(tài)更新發(fā)貨、完成、取消、訂單明細(xì)導(dǎo)出用戶(hù)管理用戶(hù)列表、禁用/啟用賬號(hào)、重置密碼輪播圖與系統(tǒng)公告管理這里要特別說(shuō)明一下處方藥流程。很多畢設(shè)偷懶把所有藥品都當(dāng)普通商品直接下單這是不專(zhuān)業(yè)的。但在畢業(yè)設(shè)計(jì)階段完整實(shí)現(xiàn)處方上傳、藥師審核、審核通過(guò)后才能支付的流程工作量確實(shí)偏大。實(shí)際操作中多數(shù)優(yōu)質(zhì)畢設(shè)會(huì)把處方藥設(shè)計(jì)成“加入購(gòu)物車(chē)時(shí)需要填寫(xiě)用藥人信息并勾選已確診聲明”然后在后端加一道藥師審核節(jié)點(diǎn)這樣既體現(xiàn)了業(yè)務(wù)理解深度又不至于把項(xiàng)目周期拖得太長(zhǎng)。1.3 系統(tǒng)架構(gòu)前后端分離還是單體應(yīng)用這個(gè)問(wèn)題幾乎每個(gè)來(lái)問(wèn)我的人都糾結(jié)過(guò)。我的建議很直接有基礎(chǔ)就上前后端分離沒(méi)基礎(chǔ)就用單體Bootstrap模板引擎兩種方案都能做出優(yōu)質(zhì)畢設(shè)關(guān)鍵看你怎么選。前后端分離方案是當(dāng)前工業(yè)界的主流形態(tài)后端用Spring Boot暴露RESTful API前端用Vue 3 Element Plus構(gòu)建單頁(yè)應(yīng)用通過(guò)JSON交換數(shù)據(jù)。好處是技術(shù)棧新、代碼組織清晰、簡(jiǎn)歷上好看壞處是你要同時(shí)掌握后端接口設(shè)計(jì)和前端組件開(kāi)發(fā)調(diào)試跨域、處理token過(guò)期這類(lèi)問(wèn)題的排查鏈路更長(zhǎng)。單體模板方案是Spring Boot Thymeleaf或者JSP頁(yè)面由后端渲染邏輯簡(jiǎn)單直接沒(méi)有跨域煩惱開(kāi)發(fā)速度快。缺點(diǎn)是技術(shù)棧相對(duì)傳統(tǒng)前端交互體驗(yàn)一般。我個(gè)人強(qiáng)烈推薦前后端分離因?yàn)榇疝q時(shí)老師大概率會(huì)問(wèn)“為什么選前后端分離”這個(gè)問(wèn)題的標(biāo)準(zhǔn)答案本身就體現(xiàn)了你對(duì)現(xiàn)代開(kāi)發(fā)流程的理解。而且后端API的測(cè)試、前端組件的復(fù)用這些實(shí)踐都是可以直接帶到工作中的。后面我講的代碼示例也是以后端API為視角展開(kāi)的。2. 技術(shù)選型與開(kāi)發(fā)環(huán)境搭建2.1 技術(shù)棧逐項(xiàng)解析這套系統(tǒng)我采用的是Java生態(tài)里最經(jīng)典也最穩(wěn)妥的組合后端主體JDK 8 或 JDK 11JDK 11是分水嶺畢業(yè)設(shè)計(jì)用8也行但11的局部變量類(lèi)型推斷等特性更好用Spring Boot 2.7.x不用最新的3.x因?yàn)?.x要求JDK 17而且很多配套組件版本變化較大容易給自己挖坑MyBatis-Plus 3.5.x數(shù)據(jù)持久層相比純MyBatis省去大量單表操作的XML配置MySQL 8.0關(guān)系型數(shù)據(jù)庫(kù)8.0以上更好用支持窗口函數(shù)Redis 可選用于緩存驗(yàn)證碼、token如果不想引入中間件本地Map也能應(yīng)付前端主體Vue 3 Vite構(gòu)建速度快組合式API寫(xiě)邏輯更順手Element Plus組件庫(kù)表格、表單、彈窗、分頁(yè)都是現(xiàn)成的Pinia狀態(tài)管理比Vuex更簡(jiǎn)潔AxiosHTTP請(qǐng)求庫(kù)ECharts可視化圖表用于首頁(yè)統(tǒng)計(jì)輔助工具M(jìn)aven依賴(lài)管理JWT Spring Security 或者 Sa-Token認(rèn)證授權(quán)Lombok簡(jiǎn)化實(shí)體代碼Hutool工具類(lèi)庫(kù)處理日期、加密、驗(yàn)證碼很方便這個(gè)組合是目前B站和培訓(xùn)機(jī)構(gòu)主流的教學(xué)組合資料多、報(bào)錯(cuò)網(wǎng)上都能搜到解決方案對(duì)畢設(shè)來(lái)講是風(fēng)險(xiǎn)最低的選擇。2.2 為什么不用SSM框架很多同學(xué)在選題時(shí)后臺(tái)老師會(huì)列“Spring SpringMVC MyBatisSSM”讓你選。我的意見(jiàn)是能不用SSM就不用。SSM屬于上一個(gè)時(shí)代的開(kāi)發(fā)方式配置繁瑣——光一個(gè)Spring配置和MyBatis配置就要寫(xiě)幾十行XML而Spring Boot通過(guò)自動(dòng)配置把這些問(wèn)題全部抹平了。你做畢設(shè)是為了展示工程能力不是為了證明自己能手工拼裝XML。同理為什么不推薦用ShiroShiro和Spring Security都能做權(quán)限控制但Spring Security在最近版本中不斷演進(jìn)社區(qū)活躍度更高與Spring Boot的集成更無(wú)縫。當(dāng)然如果你擅長(zhǎng)Shiro選它也完全沒(méi)問(wèn)題核心是你要能講清楚Session認(rèn)證與Token認(rèn)證的區(qū)別。我這個(gè)項(xiàng)目用的是Sa-Token它的學(xué)習(xí)曲線(xiàn)平緩API設(shè)計(jì)對(duì)初學(xué)者非常友好文檔又全屬于小眾但非常香的選擇。2.3 環(huán)境搭建的坑與版本匹配環(huán)境搭建這一步我見(jiàn)過(guò)太多人卡死在版本匹配上。直接給一套我已驗(yàn)證可用的版本組合JDK1.8.0_202 或 Amazon Corretto 8Maven3.6.3 或 3.8.xSpring Boot2.7.14MyBatis-Plus3.5.3.1注意3.5.4之后分頁(yè)插件寫(xiě)法有變化MySQL8.0.32 或 5.7.265.7也可以但注意時(shí)區(qū)配置Node.js16.20.x 或 18.xVite 4需要Node 16.20npm8.x一個(gè)非常容易踩的坑是Maven倉(cāng)庫(kù)依賴(lài)下載緩慢或版本沖突。建議在Maven的settings.xml里配置阿里云鏡像并且只用spring-boot-starter-parent做統(tǒng)一版本管理不要自己隨意指定子模塊版本否則極容易出現(xiàn)NoSuchMethodError之類(lèi)的問(wèn)題。遇到啟動(dòng)報(bào)錯(cuò)先別急著懷疑代碼按這個(gè)順序排查Maven依賴(lài)是否下載完整 → 數(shù)據(jù)庫(kù)連接配置是否有誤 → 端口是否被占用 → 啟動(dòng)類(lèi)位置是否放對(duì)Spring Boot默認(rèn)掃描啟動(dòng)類(lèi)所在包及其子包。80%的啟動(dòng)失敗都能用這四步解決。3. 數(shù)據(jù)庫(kù)設(shè)計(jì)藥房業(yè)務(wù)的地基3.1 數(shù)據(jù)表全景數(shù)據(jù)庫(kù)設(shè)計(jì)是面試和答辯時(shí)老師最?lèi)?ài)深挖的地方也是最能體現(xiàn)你水平的地方。這張表結(jié)構(gòu)圖我建議直接背下來(lái)并能講出每一張表為什么這么設(shè)計(jì)。核心表sys_user用戶(hù)表用戶(hù)ID、用戶(hù)名、密碼、昵稱(chēng)、頭像、手機(jī)、郵箱、角色標(biāo)識(shí)、狀態(tài)、創(chuàng)建時(shí)間sys_role角色表角色I(xiàn)D、角色編碼、角色名稱(chēng)sys_user_role用戶(hù)角色關(guān)聯(lián)表多對(duì)多關(guān)系drug_category藥品分類(lèi)表分類(lèi)ID、父分類(lèi)ID、分類(lèi)名稱(chēng)、排序drug_info藥品信息表藥品ID、批準(zhǔn)文號(hào)、藥品名稱(chēng)、通用名、規(guī)格、劑型、單位、生產(chǎn)廠(chǎng)家、儲(chǔ)存條件、處方類(lèi)型、零售價(jià)、會(huì)員價(jià)、庫(kù)存數(shù)量、預(yù)警值、圖片、說(shuō)明書(shū)、創(chuàng)建時(shí)間drug_stock_log庫(kù)存變動(dòng)日志表日志ID、藥品ID、變動(dòng)數(shù)量、變動(dòng)類(lèi)型入庫(kù)/出庫(kù)/盤(pán)點(diǎn)調(diào)整、操作前后數(shù)量、操作人、操作時(shí)間、備注cart_item購(gòu)物車(chē)表購(gòu)物車(chē)ID、用戶(hù)ID、藥品ID、藥品數(shù)量、加入時(shí)間order_info訂單主表訂單號(hào)、用戶(hù)ID、訂單總金額、實(shí)付金額、訂單狀態(tài)、收貨人、聯(lián)系電話(huà)、收貨地址、下單時(shí)間、支付時(shí)間、完成時(shí)間order_item訂單明細(xì)表明細(xì)ID、訂單ID、藥品ID、藥品名稱(chēng)快照、單價(jià)快照、數(shù)量、小計(jì)金額sys_notice公告表公告ID、標(biāo)題、內(nèi)容、發(fā)布時(shí)間sys_pic輪播圖表圖片ID、圖片地址、跳轉(zhuǎn)鏈接、排序這幾張表覆蓋了一個(gè)藥房系統(tǒng)的全部核心鏈路。多說(shuō)一句訂單明細(xì)表里的藥品名稱(chēng)快照字段特別重要它是為了防止藥品信息被修改后歷史訂單數(shù)據(jù)跟著變臟的做法。畢業(yè)設(shè)計(jì)能考慮到這一點(diǎn)答辯時(shí)是明顯的加分項(xiàng)。3.2 關(guān)鍵字段設(shè)計(jì)意圖解讀我挑幾個(gè)容易踩坑的字段詳細(xì)說(shuō)說(shuō)。藥品價(jià)格字段必須使用DECIMAL(10,2)。我審過(guò)不少畢設(shè)代碼發(fā)現(xiàn)有人圖省事用double存價(jià)格這是嚴(yán)重的低級(jí)錯(cuò)誤。float和double在二進(jìn)制浮點(diǎn)運(yùn)算中會(huì)產(chǎn)生誤差0.1 0.2輸出的結(jié)果不是0.3這在涉及金額累加、優(yōu)惠折扣計(jì)算時(shí)會(huì)造成分級(jí)別錯(cuò)誤。Java后端對(duì)應(yīng)使用BigDecimal所有價(jià)格計(jì)算必須通過(guò)BigDecimal的add、subtract、multiply方法完成禁止直接使用算術(shù)運(yùn)算符。庫(kù)存字段藥品表冗余存一個(gè)當(dāng)前庫(kù)存字段同時(shí)用庫(kù)存變動(dòng)日志表記錄每一次出入庫(kù)明細(xì)。為什么這么設(shè)計(jì)因?yàn)槿绻豢咳罩颈頃r(shí)時(shí)SUM統(tǒng)計(jì)庫(kù)存訂單并發(fā)高的時(shí)候性能撐不住而且查詢(xún)歷史維度特別麻煩如果只存一個(gè)當(dāng)前庫(kù)存數(shù)字又無(wú)法追溯“這個(gè)月總共入庫(kù)多少、出庫(kù)多少”。兩者互補(bǔ)才是完整方案。訂單狀態(tài)字段用int類(lèi)型TINYINT存狀態(tài)值配合后端狀態(tài)機(jī)做流轉(zhuǎn)校驗(yàn)。不要用字符串狀態(tài)直接存因?yàn)椴煌K對(duì)狀態(tài)的叫法可能不一致比如前端叫“待付款”后端叫“PENDING_PAY”用數(shù)字枚舉后端統(tǒng)一維護(hù)并配合狀態(tài)機(jī)限制流轉(zhuǎn)路徑比如“已發(fā)貨”狀態(tài)下不能直接跳到“已取消”這種限制能防止臟數(shù)據(jù)。3.3 物理外鍵與邏輯外鍵的選擇這是個(gè)很經(jīng)典的開(kāi)發(fā)爭(zhēng)議話(huà)題。很多教科書(shū)鼓勵(lì)建外鍵約束但我實(shí)際做項(xiàng)目時(shí)的習(xí)慣是數(shù)據(jù)庫(kù)層面不建物理外鍵邏輯外鍵由代碼控制。原因很簡(jiǎn)單——物理外鍵會(huì)導(dǎo)致幾個(gè)問(wèn)題一是每次插入子表都要檢查主表寫(xiě)并發(fā)高的時(shí)候性能受損二是刪除主表數(shù)據(jù)時(shí)如果被外鍵約束攔住會(huì)出現(xiàn)一堆“刪除失敗”的詭異報(bào)錯(cuò)三是項(xiàng)目運(yùn)行中如果要調(diào)整表結(jié)構(gòu)比如分庫(kù)分表外鍵是最難遷移的。所以在互聯(lián)網(wǎng)公司里物理外鍵幾乎絕跡都是靠開(kāi)發(fā)人員在業(yè)務(wù)層保證引用完整性。但在答辯時(shí)如果老師質(zhì)疑“為什么沒(méi)有外鍵”你要能解釋清楚這套邏輯而不是支支吾吾答不上來(lái)。這本身就是設(shè)計(jì)思維的體現(xiàn)。4. 核心功能模塊的實(shí)現(xiàn)細(xì)節(jié)4.1 用戶(hù)認(rèn)證JWT令牌機(jī)制用戶(hù)登錄是整套系統(tǒng)的第一道門(mén)。我不建議用傳統(tǒng)的Session方案因?yàn)榍昂蠖朔蛛x的場(chǎng)景下Session天然要依賴(lài)Cookie而跨域場(chǎng)景下Cookie處理很麻煩。這里采用JWTJSON Web Token方案。簡(jiǎn)單講用戶(hù)輸入用戶(hù)名密碼后端校驗(yàn)通過(guò)后生成一個(gè)帶簽名的令牌前端把令牌存到本地每次請(qǐng)求在請(qǐng)求頭里帶上Authorization: Bearer xxx后端過(guò)濾器攔截并驗(yàn)簽。這套機(jī)制的核心價(jià)值是無(wú)狀態(tài)——服務(wù)器不需要保存會(huì)話(huà)信息天然支持水平擴(kuò)容。JWT的生成代碼在用Sa-Token時(shí)非常簡(jiǎn)單PostMapping(/login) public ResultString login(RequestBody LoginDTO dto) { // 1. 校驗(yàn)驗(yàn)證碼防止暴力破解 // 2. 根據(jù)用戶(hù)名查用戶(hù) SysUser user userService.getByUsername(dto.getUsername()); // 3. 密碼加密比對(duì)BCrypt加密 if (user null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error(用戶(hù)名或密碼錯(cuò)誤); } // 4. 賬號(hào)是否被禁用 if (user.getStatus() 0) { return Result.error(賬號(hào)已被禁用請(qǐng)聯(lián)系管理員); } // 5. 簽發(fā)token StpUtil.login(user.getUserId()); return Result.success(StpUtil.getTokenValue()); }這里要強(qiáng)調(diào)一個(gè)核心原則數(shù)據(jù)庫(kù)里的密碼絕不能存明文。正確的做法是使用BCrypt或Spring Security自帶的加密器對(duì)密碼做哈希處理登錄時(shí)用BCrypt.checkpw比對(duì)。如果你在項(xiàng)目里發(fā)現(xiàn)密碼直接明文存儲(chǔ)答辯時(shí)這就是被攻擊的點(diǎn)——老師只要問(wèn)一句“數(shù)據(jù)庫(kù)泄露了怎么辦”你就無(wú)言以對(duì)。4.2 庫(kù)存扣減事務(wù)控制藥品下單是整個(gè)系統(tǒng)里并發(fā)風(fēng)險(xiǎn)最高的操作。比如100個(gè)用戶(hù)同時(shí)爭(zhēng)搶庫(kù)存僅剩3盒的藥品如果代碼寫(xiě)成“先查庫(kù)存-判斷足夠-再減庫(kù)存”在高并發(fā)場(chǎng)景下會(huì)產(chǎn)生嚴(yán)重的超賣(mài)問(wèn)題。因?yàn)椴閹?kù)存和減庫(kù)存兩步之間有時(shí)間窗其他請(qǐng)求可能在這期間插進(jìn)來(lái)大家都查到庫(kù)存是3都以為自己能買(mǎi)結(jié)果最終扣成負(fù)數(shù)。正確做法是用數(shù)據(jù)庫(kù)層面的原子更新加事務(wù)控制Transactional(rollbackFor Exception.class) public void deductStock(ListCartItem items) { for (CartItem item : items) { // 原子更新庫(kù)存大于購(gòu)買(mǎi)數(shù)量時(shí)才扣減 int rows drugInfoMapper.deductStock(item.getDrugId(), item.getQuantity()); if (rows 0) { throw new RuntimeException(庫(kù)存不足商品 item.getDrugName()); } // 記錄庫(kù)存變動(dòng)日志 drugStockLogService.recordLog(item.getDrugId(), -item.getQuantity(), ...); } }對(duì)應(yīng)Mapper中的SQLUPDATE drug_info SET stock stock - #{quantity} WHERE drug_id #{drugId} AND stock #{quantity}注意這段SQL的巧妙之處它在一條語(yǔ)句里同時(shí)完成了“判斷庫(kù)存是否充足”和“扣減庫(kù)存”兩個(gè)操作利用數(shù)據(jù)庫(kù)行鎖保證了并發(fā)安全。如果影響行數(shù)為0說(shuō)明條件不成立那就拋異常讓整個(gè)事務(wù)回滾訂單也不會(huì)創(chuàng)建。這種寫(xiě)法比你“先select后update”的方式在性能和安全性上高出不止一個(gè)檔次。庫(kù)存扣減還有兩個(gè)細(xì)節(jié)需要注意。第一必須在Transactional里執(zhí)行一旦后面的訂單創(chuàng)建、明細(xì)寫(xiě)入任何一個(gè)環(huán)節(jié)報(bào)錯(cuò)庫(kù)存能跟著回滾不會(huì)出現(xiàn)“錢(qián)沒(méi)收到、藥卻扣了”的局面。第二可以額外設(shè)計(jì)一個(gè)庫(kù)存預(yù)警機(jī)制——當(dāng)庫(kù)存低于預(yù)警值時(shí)后臺(tái)首頁(yè)會(huì)提示采購(gòu)員補(bǔ)貨這個(gè)邏輯在數(shù)據(jù)字典里有預(yù)警值字段。4.3 訂單狀態(tài)機(jī)與異常處理訂單模塊看起來(lái)只是簡(jiǎn)單的insert和update但真正折磨人的是各種邊界狀態(tài)。用戶(hù)下單后不支付怎么辦支付了但不發(fā)貨怎么辦發(fā)貨了但用戶(hù)要退貨怎么辦如果代碼里沒(méi)有約束就會(huì)出現(xiàn)任意狀態(tài)跳到任意狀態(tài)的混亂情況。我建議用一個(gè)私有方法集中處理狀態(tài)流轉(zhuǎn)public boolean changeOrderStatus(String orderNo, int targetStatus) { OrderInfo order this.getByOrderNo(orderNo); // 合法狀態(tài)流轉(zhuǎn)映射 MapInteger, ListInteger validTransitions new HashMap(); validTransitions.put(0, Arrays.asList(1, 5)); // 待支付 - 已支付 / 已取消 validTransitions.put(1, Arrays.asList(2)); // 已支付 - 已發(fā)貨 validTransitions.put(2, Arrays.asList(3, 4)); // 已發(fā)貨 - 已完成 / 已退款 ListInteger allowed validTransitions.get(order.getStatus()); if (allowed null || !allowed.contains(targetStatus)) { throw new BizException(非法的訂單狀態(tài)流轉(zhuǎn)); } // 執(zhí)行更新 }這200行不到的狀態(tài)映射表是你答辯時(shí)說(shuō)明“對(duì)業(yè)務(wù)有完整理解”的絕佳材料。老師問(wèn)“你怎么保證訂單狀態(tài)不亂”你就可以拿這個(gè)類(lèi)直接講設(shè)計(jì)思路。訂單模塊還有幾個(gè)容易遺漏的細(xì)節(jié)生成訂單號(hào)要保證唯一且有序一般用時(shí)間戳加隨機(jī)數(shù)或雪花算法保存收貨地址要單獨(dú)存字符串快照而不是存地址ID防止用戶(hù)修改地址后歷史訂單地址跟著變刪除訂單只能做軟刪除避免破壞與明細(xì)表之間的引用關(guān)系。4.4 前端頁(yè)面的核心交互邏輯前端部分藥房購(gòu)藥系統(tǒng)的核心頁(yè)面包括首頁(yè)輪播圖 藥品展示 公告、藥品列表分類(lèi)篩選 關(guān)鍵詞搜索 分頁(yè)、藥品詳情、購(gòu)物車(chē)頁(yè)、訂單結(jié)算頁(yè)、個(gè)人中心、后臺(tái)管理頁(yè)。這里提兩個(gè)前端頁(yè)面里最值得優(yōu)化的交互點(diǎn)。第一個(gè)是購(gòu)物車(chē)數(shù)量加減的防抖處理。用戶(hù)在購(gòu)物車(chē)?yán)锩孢B續(xù)點(diǎn)擊“”號(hào)時(shí)如果每次都發(fā)一次請(qǐng)求更新數(shù)據(jù)庫(kù)會(huì)產(chǎn)生大量無(wú)用請(qǐng)求而且容易導(dǎo)致數(shù)據(jù)錯(cuò)亂。正確做法是前端在200毫秒內(nèi)合并點(diǎn)擊操作只發(fā)最后一次請(qǐng)求或者更穩(wěn)妥的做法是購(gòu)物車(chē)數(shù)量變動(dòng)只在內(nèi)存中操作等用戶(hù)點(diǎn)擊“去結(jié)算”時(shí)才批量提交后端。后端再根據(jù)提交的數(shù)據(jù)進(jìn)行數(shù)量重新校驗(yàn)避免用戶(hù)直接篡改價(jià)格或數(shù)量。第二個(gè)是訂單提交前的秒殺式重復(fù)點(diǎn)擊防護(hù)。用戶(hù)點(diǎn)擊“提交訂單”后按鈕立刻變成loading狀態(tài)同時(shí)生成一個(gè)前端請(qǐng)求序列號(hào)后端判斷該序列號(hào)是否已處理過(guò)處理過(guò)就直接返回結(jié)果而不是再建一次單。這些細(xì)節(jié)雖然不起眼但答辯時(shí)被問(wèn)“系統(tǒng)有哪些安全設(shè)計(jì)”時(shí)你能說(shuō)出這些點(diǎn)老師會(huì)非常認(rèn)可。前端還有一塊容易被忽視的是路由權(quán)限控制。Vue Router里定義路由meta信息比如meta: { roles: [admin] }路由守衛(wèi)里根據(jù)當(dāng)前用戶(hù)的角色過(guò)濾。這不難但能讓后臺(tái)管理系統(tǒng)的不同角色進(jìn)入不同菜單屬于必須有的體驗(yàn)。5. 開(kāi)發(fā)全流程記錄與踩坑實(shí)錄5.1 從建表到跑通首個(gè)接口的開(kāi)發(fā)順序很多同學(xué)拿到題目不知道先干什么。我梳理一個(gè)我認(rèn)為最高效的開(kāi)發(fā)順序第一步畫(huà)數(shù)據(jù)庫(kù)ER圖建表并插入測(cè)試數(shù)據(jù)。這一步花兩天時(shí)間都不為過(guò)因?yàn)楹罄m(xù)的所有代碼都圍繞表結(jié)構(gòu)寫(xiě)。測(cè)試數(shù)據(jù)要造得像樣藥品名、批準(zhǔn)文號(hào)、生產(chǎn)廠(chǎng)家都要真實(shí)比如“阿莫西林膠囊 0.25g*24粒 國(guó)藥準(zhǔn)字H20003263”這種。第二步搭后端骨架建項(xiàng)目、配置數(shù)據(jù)庫(kù)連接、寫(xiě)實(shí)體類(lèi)、Mapper先跑通一個(gè)登錄接口。到這里你的項(xiàng)目已經(jīng)能啟動(dòng)了。第三步實(shí)現(xiàn)用戶(hù)端核心鏈路注冊(cè)登錄 - 藥品列表 - 藥品詳情 - 加入購(gòu)物車(chē) - 提交訂單 - 模擬支付 - 查看訂單。這個(gè)流程打通之后系統(tǒng)的大梁就算是立住了。第四步實(shí)現(xiàn)后臺(tái)核心鏈路藥品CRUD - 分類(lèi)管理 - 庫(kù)存出入庫(kù) - 訂單處理發(fā)貨/取消 - 用戶(hù)管理。到這里你的系統(tǒng)已經(jīng)可以真實(shí)使用了。第五步做輔助功能輪播圖管理、公告管理、數(shù)據(jù)統(tǒng)計(jì)圖表、個(gè)人中心。這些都是錦上添花的內(nèi)容工作量可控但非常提升完成度。最后是測(cè)試和補(bǔ)充用Postman把每個(gè)接口測(cè)一遍記錄異常情況并修復(fù)檢查權(quán)限接口是否被正確攔截處理前端控制臺(tái)警告編寫(xiě)部署說(shuō)明文檔。5.2 前后端分離聯(lián)調(diào)時(shí)的跨域問(wèn)題前后端分離項(xiàng)目第一個(gè)攔路虎就是跨域。前端跑在5173端口后端跑在8080端口瀏覽器的同源策略會(huì)直接攔截Ajax請(qǐng)求控制臺(tái)報(bào)錯(cuò)CORS policy。有三種主流解決方案一是在后端寫(xiě)全局跨域配置類(lèi)二是前后端通過(guò)Nginx反向代理同一域名下轉(zhuǎn)發(fā)三是用Spring Cloud Gateway之類(lèi)的東西做網(wǎng)關(guān)代理。對(duì)畢設(shè)而言第一種最簡(jiǎn)單直接。Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns(*)與allowCredentials(true)必須同時(shí)使用只寫(xiě)allowedOrigins(*)在部分瀏覽器版本上會(huì)與credentials沖突?？缬騿?wèn)題排查不難但如果你不知道原理改半天代碼都找不到問(wèn)題在哪最后往往是后端過(guò)濾器把OPTIONS預(yù)檢請(qǐng)求攔截了。5.3 MyBatis-Plus分頁(yè)失效問(wèn)題分頁(yè)可以說(shuō)是查詢(xún)功能里必踩的坑。MyBatis-Plus使用分頁(yè)需要配置一個(gè)分頁(yè)插件Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }如果你忘記配置這個(gè)插件調(diào)用selectPage不會(huì)報(bào)錯(cuò)但數(shù)據(jù)會(huì)全部返回分頁(yè)完全失效。更隱蔽的問(wèn)題是分頁(yè)查詢(xún)返回的total值默認(rèn)是普通count如果數(shù)據(jù)量極大這種count是全表掃描的性能很差。MyBatis-Plus默認(rèn)做了優(yōu)化但如果你的查詢(xún)SQL里包含多表joincount語(yǔ)句可能會(huì)統(tǒng)計(jì)出錯(cuò)誤的總數(shù)需要手動(dòng)指定optimizeCountSql或單獨(dú)的處理方式。另一個(gè)常見(jiàn)問(wèn)題是分頁(yè)時(shí)帶上條件查詢(xún)MyBatis-Plus會(huì)自動(dòng)拼接條件但如果你在條件里傳了模糊匹配的搜索詞而這個(gè)詞帶%或_這種SQL通配符就會(huì)導(dǎo)致查詢(xún)結(jié)果異常。需要用QueryWrapper的like方法配合Escape處理或者自己手動(dòng)轉(zhuǎn)義。5.4 文件上傳藥品圖片的存儲(chǔ)策略藥品管理里圖片上傳看似簡(jiǎn)單其實(shí)有個(gè)規(guī)劃問(wèn)題圖片存到哪里常見(jiàn)三種方案。方案一是存本地磁盤(pán)上傳路徑寫(xiě)在配置文件里前端通過(guò)Nginx映射訪(fǎng)問(wèn)。這種方案適合畢設(shè)簡(jiǎn)單可靠但要注意服務(wù)器重啟后路徑配置不能寫(xiě)死。方案二是存到數(shù)據(jù)庫(kù)的Blob字段但這種方案極度不推薦數(shù)據(jù)庫(kù)文件過(guò)大會(huì)拖性能備份和遷移都是災(zāi)難。方案三是存到云端對(duì)象存儲(chǔ)阿里云OSS/MinIO畢設(shè)用MinIO自建就夠。如果不想引入額外組件方案一在本地環(huán)境足夠了。上傳接口用Spring Boot自帶的MultipartFile接收配合Hutool的FileUtil生成隨機(jī)文件名限制文件大小2MB校驗(yàn)文件后綴名。這些代碼網(wǎng)上都有但你要能講清楚為什么限制大小和類(lèi)型答案是防惡意上傳這屬于系統(tǒng)安全設(shè)計(jì)的一部分。5.5 報(bào)表統(tǒng)計(jì)模塊的數(shù)據(jù)組織藥房系統(tǒng)的首頁(yè)儀表盤(pán)通常要展示今日銷(xiāo)售額、今日訂單數(shù)、會(huì)員總數(shù)、庫(kù)存預(yù)警藥品數(shù)、近一周銷(xiāo)售趨勢(shì)圖。這部分我用ECharts來(lái)實(shí)現(xiàn)效果很直觀(guān)。數(shù)據(jù)庫(kù)層面的做法是寫(xiě)聚合SQLSELECT DATE(create_time) AS order_date, SUM(total_amount) AS amount, COUNT(*) AS cnt FROM order_info WHERE create_time DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(create_time) ORDER BY order_date;后端把這個(gè)List返回給前端前端ECharts直接把日期和金額作為x軸、y軸渲染成折線(xiàn)圖。這部分在答辯時(shí)是非常出彩的展示亮點(diǎn)建議認(rèn)真做。5.6 常見(jiàn)的啟動(dòng)與運(yùn)行異常速查表記一份異常排查手冊(cè)可以省掉很多上網(wǎng)搜索的時(shí)間。異常現(xiàn)象可能原因解決方案啟動(dòng)報(bào)Consider defining a bean of type xxxMapperMapper接口沒(méi)有被掃描到在啟動(dòng)類(lèi)加MapperScan注解前端請(qǐng)求返回401 UnauthorizedToken缺失或過(guò)期檢查前端請(qǐng)求攔截器是否帶了請(qǐng)求頭用Postman直接測(cè)后端驗(yàn)證中文寫(xiě)入數(shù)據(jù)庫(kù)變成?數(shù)據(jù)庫(kù)連接URL未指定characterEncoding在JDBC URL中加?useUnicodetruecharacterEncodingutf8上傳圖片后訪(fǎng)問(wèn)404靜態(tài)資源路徑未映射配置WebMvcConfigurer的addResourceHandlersjava.sql.SQLException: Access denied for user數(shù)據(jù)庫(kù)賬號(hào)密碼錯(cuò)誤或權(quán)限不足在MySQL里執(zhí)行GRANT ALL PRIVILEGES ON db_name.* TO rootlocalhost啟動(dòng)時(shí)端口被占用其他進(jìn)程占了8080用netstat -anoRedis連接超時(shí)Redis未啟動(dòng)或密碼錯(cuò)誤啟動(dòng)Redis服務(wù)或檢查密碼如果使用Windows版Redis檢查服務(wù)狀態(tài)前端npm run dev啟動(dòng)失敗Node版本過(guò)低或依賴(lài)不完整升級(jí)Node到16.20刪掉node_modules重新安裝6. 項(xiàng)目?jī)?yōu)化方向與答辯準(zhǔn)備經(jīng)驗(yàn)6.1 比基本功能再多走一步的優(yōu)化方案如果你的系統(tǒng)已經(jīng)按上述功能完成了且還有時(shí)間精力我建議按性?xún)r(jià)比從高到低挑幾個(gè)方向做強(qiáng)化第一藥品效期管理。在藥品信息表中增加生產(chǎn)日期和有效期字段用定時(shí)任務(wù)掃描即將過(guò)期的藥品假設(shè)有效期低于3個(gè)月在后臺(tái)首頁(yè)生成警告列表臨期藥品在列表頁(yè)打上特殊標(biāo)簽。這個(gè)功能尤其貼合醫(yī)藥行業(yè)屬性答辯時(shí)說(shuō)“我用Scheduled定時(shí)任務(wù)實(shí)現(xiàn)了效期預(yù)警”這是非常亮眼的工程亮點(diǎn)。第二操作日志審計(jì)。用一個(gè)AOP切面記錄管理員的所有敏感操作比如刪除藥品、修改價(jià)格、強(qiáng)制下架。在設(shè)計(jì)層面體現(xiàn)合規(guī)意識(shí)醫(yī)藥行業(yè)對(duì)操作留痕要求很高。第三訂單超時(shí)未支付自動(dòng)取消。用戶(hù)下單后15分鐘不支付訂單自動(dòng)關(guān)閉并回滾庫(kù)存。這里有兩個(gè)實(shí)現(xiàn)方案一是后端定時(shí)任務(wù)掃描超時(shí)訂單批量處理二是使用延遲消息或者Redisson的延遲隊(duì)列精準(zhǔn)觸發(fā)。畢設(shè)用定時(shí)任務(wù)就夠了但如果你能主動(dòng)講出兩種方案的區(qū)別說(shuō)明你真的理解系統(tǒng)設(shè)計(jì)而不只是能寫(xiě)出代碼。第四數(shù)據(jù)導(dǎo)入導(dǎo)出。藥品信息支持Excel批量導(dǎo)入訂單列表支持導(dǎo)出Excel。用EasyExcel或Hutool的Excel工具就能做工作量半天起步但“批量導(dǎo)入”功能對(duì)管理員來(lái)說(shuō)很實(shí)用也是答辯時(shí)容易被追問(wèn)的點(diǎn)。6.2 答辯時(shí)的高頻問(wèn)題與回答思路我能猜到你最緊張的是什么沒(méi)錯(cuò)就是答辯。整理幾個(gè)高頻問(wèn)題及回答思路老師問(wèn)“你這個(gè)系統(tǒng)的角色權(quán)限是怎么實(shí)現(xiàn)的”回答主線(xiàn)RBAC模型 用戶(hù)-角色多對(duì)多表 菜單權(quán)限攔截器。在攔截器里判斷當(dāng)前登錄用戶(hù)的角色標(biāo)識(shí)決定哪些接口能訪(fǎng)問(wèn)。前端再根據(jù)角色渲染對(duì)應(yīng)的菜單。強(qiáng)調(diào)RBAC的核心理念是“權(quán)限不直接綁定用戶(hù)而是綁定角色”這樣新增角色、調(diào)整權(quán)限不用改代碼。老師問(wèn)“藥品庫(kù)存你是怎么保證數(shù)據(jù)準(zhǔn)確性的”回答主線(xiàn)數(shù)據(jù)庫(kù)事務(wù) 原子更新SQL 庫(kù)存變動(dòng)日志。解釋清楚UPDATE drug_info SET stock stock - quantity WHERE stock quantity這條SQL在并發(fā)場(chǎng)景下如何避免超賣(mài)事務(wù)回滾如何保證數(shù)據(jù)一致性庫(kù)存日志如何實(shí)現(xiàn)事后追溯。這一套邏輯下來(lái)老師基本不會(huì)繼續(xù)追問(wèn)了。老師問(wèn)“訂單支付這塊你做的是模擬支付安全和真實(shí)支付有什么區(qū)別”回答主線(xiàn)坦率回答這是模擬支付真實(shí)支付需要對(duì)接微信支付或支付寶流程包括下單時(shí)生成支付二維碼、支付回調(diào)通知、回調(diào)驗(yàn)簽、訂單狀態(tài)異步刷新。重點(diǎn)說(shuō)出“真實(shí)支付的核心難點(diǎn)在于回調(diào)處理與冪等設(shè)計(jì)”展示出你對(duì)真實(shí)業(yè)務(wù)的理解而不是硬吹自己實(shí)現(xiàn)得多完善。老師問(wèn)“你的系統(tǒng)有哪些地方可以繼續(xù)優(yōu)化”回答主線(xiàn)千萬(wàn)不要說(shuō)“沒(méi)有了”。準(zhǔn)備兩個(gè)方向一是引入Redis做緩存把藥品熱門(mén)數(shù)據(jù)查詢(xún)放緩存降低數(shù)據(jù)庫(kù)壓力二是引入消息隊(duì)列在訂單高峰期削峰填谷提高系統(tǒng)的并發(fā)處理能力。這樣既展示了你的問(wèn)題意識(shí)也說(shuō)明你有架構(gòu)演進(jìn)思維。6.3 源碼管理與論文撰寫(xiě)的配合最后聊聊源碼管理和論文。如果你用Git做版本管理每次寫(xiě)完一個(gè)功能模塊就提交一次commit message寫(xiě)清功能含義比如feat: 實(shí)現(xiàn)購(gòu)物車(chē)結(jié)算功能。答辯時(shí)展示Git提交記錄能直觀(guān)證明項(xiàng)目是你一步步做的而不是網(wǎng)上搬的。論文寫(xiě)作方面核心章節(jié)要對(duì)應(yīng)系統(tǒng)設(shè)計(jì)第三章寫(xiě)系統(tǒng)分析第四章寫(xiě)系統(tǒng)設(shè)計(jì)功能模塊圖 數(shù)據(jù)庫(kù)E-R圖 表結(jié)構(gòu)第五章寫(xiě)系統(tǒng)實(shí)現(xiàn)每個(gè)核心功能的截圖 核心代碼片段完美呼應(yīng)。論文里引用的每張圖表都是你系統(tǒng)里真實(shí)運(yùn)行出來(lái)的這種真實(shí)性就是高分的基礎(chǔ)。寫(xiě)在最后的一點(diǎn)體會(huì)做畢業(yè)設(shè)計(jì)這個(gè)東西說(shuō)穿了是一個(gè)“一個(gè)人扮演一個(gè)團(tuán)隊(duì)”的過(guò)程。你可能要在同一個(gè)項(xiàng)目里同時(shí)當(dāng)產(chǎn)品經(jīng)理、后端工程師、前端工程師、測(cè)試工程師、部署運(yùn)維還得當(dāng)自己的答辯教練。這個(gè)過(guò)程確實(shí)累但請(qǐng)相信我只要你按“理解業(yè)務(wù) - 拆分功能 - 設(shè)計(jì)數(shù)據(jù) - 實(shí)現(xiàn)鏈路 - 打磨細(xì)節(jié)”的順序走下來(lái)你得到的收獲絕對(duì)不只是那一紙成績(jī)單。你會(huì)在不知不覺(jué)里搞明白什么叫事務(wù)、什么叫狀態(tài)機(jī)、什么叫權(quán)限模型而這些概念寫(xiě)在簡(jiǎn)歷上比任何修飾詞都更有說(shuō)服力。這套藥房購(gòu)藥系統(tǒng)不算難但也不簡(jiǎn)單它的業(yè)務(wù)閉環(huán)天然適合作為JavaWeb的綜合性訓(xùn)練項(xiàng)目。不管你是打算照著這個(gè)思路自己寫(xiě)一遍還是拿到了完整源碼想把它吃透改成自己的東西我的建議都一樣把每個(gè)模塊的代碼讀一遍自己動(dòng)手改兩個(gè)功能把數(shù)據(jù)庫(kù)里的數(shù)據(jù)查一查然后在答辯前自己把系統(tǒng)從頭到尾操作三遍。做到這個(gè)程度你就能自信地說(shuō)——這個(gè)項(xiàng)目里每一行代碼的意圖你都清楚。祝順利。