這兩年找我咨詢畢業(yè)設(shè)計的人里十個里有六七個都是做管理系統(tǒng)管理系統(tǒng)里“醫(yī)院門診”又是出現(xiàn)頻率最高的一類。這個題倒不是因為它有多新奇而是它的業(yè)務(wù)鏈條足夠完整從患者建檔、預(yù)約掛號到醫(yī)生接診、開具處方再到收費結(jié)算、藥房發(fā)藥每一個環(huán)節(jié)都有清晰的數(shù)據(jù)流和狀態(tài)流轉(zhuǎn)。把這條鏈路放在SpringBoot體系下實現(xiàn)既能體現(xiàn)JavaWeb的基礎(chǔ)功底又能展示數(shù)據(jù)庫建模、事務(wù)處理、權(quán)限控制這些硬技能作為畢業(yè)設(shè)計來說性價比極高。今天要聊的這套項目標(biāo)題信息很明確基于SpringBoot的智慧門診綜合服務(wù)平臺面向中小型醫(yī)院的門診業(yè)務(wù)一體化系統(tǒng)。說白了就是圍繞門診全流程把掛號、看診、收費、發(fā)藥、庫存這些事全部塞進(jìn)一個Web系統(tǒng)里統(tǒng)一管理。下面這篇內(nèi)容我會從需求拆解、技術(shù)選型、數(shù)據(jù)庫建模、核心業(yè)務(wù)流程實現(xiàn)一直講到常見坑點和排查思路。目標(biāo)是讓有Java基礎(chǔ)的同學(xué)既能完整復(fù)現(xiàn)這套系統(tǒng)又能在答辯的時候把每個設(shè)計決策都講透。愿意花十幾分鐘看完這篇大概率能幫你省下至少兩周的返工時間。1. 先拆需求門診業(yè)務(wù)到底在跑什么做系統(tǒng)最忌諱一上來就建表寫代碼。門診信息管理系統(tǒng)看著功能多實際上核心就是一條主流程加若干個支撐流程。把這層窗紙捅破整個項目的功能邊界、表結(jié)構(gòu)、接口設(shè)計就全清楚了。1.1 五個核心角色一條主線業(yè)務(wù)先捋一下用戶角色。任何醫(yī)院門診系統(tǒng)都逃不過這五個角色患者、醫(yī)生、收費員、藥房藥師、系統(tǒng)管理員?；颊呤欠?wù)的起點他需要注冊建檔、預(yù)約掛號、查看掛號記錄、接收檢查結(jié)果如果做了檢查模塊的話。醫(yī)生是業(yè)務(wù)中樞要查看排班、接診患者、寫病歷、開處方、開檢查申請單。收費員處理掛號收費、處方收費、退費退號。藥房藥師負(fù)責(zé)庫存管理、處方審核、發(fā)藥出庫。系統(tǒng)管理員維護(hù)科室、醫(yī)生排班、藥品目錄、系統(tǒng)參數(shù)和用戶權(quán)限。五個角色串起來就是一條主線患者建檔 - 預(yù)約或當(dāng)天掛號 - 分診候診 - 醫(yī)生接診 - 開處方/檢查單 - 收費確認(rèn) - 藥房發(fā)藥 - 診療結(jié)束。這個流程走完整個系統(tǒng)的核心業(yè)務(wù)就閉環(huán)了。我見過不少同學(xué)把精力全花在花哨的統(tǒng)計報表上結(jié)果主流程反而跑不通。這個項目想拿高分主流程的完整性比任何錦上添花的功能都重要。因為主流程承載的是典型業(yè)務(wù)邏輯掛號涉及并發(fā)防重收費涉及金額計算和事務(wù)發(fā)藥涉及庫存扣減退費涉及反向流程這些全是大廠面試?yán)飼环磸?fù)追問的東西放在畢業(yè)設(shè)計里就是妥妥的加分點。1.2 中小型醫(yī)院和大型三甲的系統(tǒng)差異標(biāo)題里特意強調(diào)了“面向中小型醫(yī)院”這個定位不是隨便寫的。中小型醫(yī)院、社區(qū)衛(wèi)生院和大型三甲醫(yī)院的信息化需求有本質(zhì)差別。大型三甲醫(yī)院用的通常是以HIS為核心的重型系統(tǒng)模塊幾十上百個與醫(yī)保、LIS檢驗、PACS影像、電子病歷深度集成實施周期按年來算數(shù)據(jù)庫并發(fā)和災(zāi)備要求極高。而中小型醫(yī)院或私立診所核心訴求是輕量、夠用、能落地?；颊吡繘]那么大并發(fā)壓力不高但業(yè)務(wù)流程必須完整覆蓋界面要簡單操作要直觀最好一個普通收費員經(jīng)過十分鐘培訓(xùn)就能上手。明白這個差異你的技術(shù)決策就順理成章了不需要分布式微服務(wù)不需要消息隊列不需要復(fù)雜的高可用集群。單體SpringBoot應(yīng)用夠用且穩(wěn)妥數(shù)據(jù)庫選MySQL前端根據(jù)自己基礎(chǔ)選Vue或模板渲染服務(wù)端只需要考慮好事務(wù)邊界和并發(fā)控制。這套組合資源占用小部署簡單一臺普通服務(wù)器就能扛起日常業(yè)務(wù)跟中小型門診的信息化需求天然匹配。2. 技術(shù)方案為什么是這套組合技術(shù)選型是答辯時老師必問的部分。能說清楚“為什么選它”和“為什么不選它”比羅列一堆技術(shù)名詞更有說服力。2.1 SpringBoot在門診場景下的優(yōu)勢服務(wù)端選SpringBoot幾乎是這類項目的最優(yōu)解。SpringBoot的核心價值在于自動配置和開箱即用把以前Spring時代大量的XML配置收進(jìn)約定里讓你能把主要精力放在業(yè)務(wù)代碼上。具體到門診系統(tǒng)SpringBoot帶來的好處很實在。第一內(nèi)嵌Tomcat打包成jar直接啟動部署成本極低。對中小型門診來說IT人員可能就一兩個沒時間維護(hù)復(fù)雜的中間件環(huán)境一個java -jar就能啟動的系統(tǒng)很友好。第二生態(tài)成熟和MyBatis-Plus、Spring Data JPA、Redis、Spring Security配合都有現(xiàn)成方案不需要造輪子。第三監(jiān)控和運維插件多Actuator、Druid監(jiān)控都能直接集成。第四當(dāng)前Java崗位招聘里SpringBoot幾乎是標(biāo)配做這個題目的經(jīng)歷在找工作時可以直接寫進(jìn)簡歷。我在實際帶畢業(yè)設(shè)計時經(jīng)常說一句話技術(shù)選型要考慮“項目需要什么”而不是“什么技術(shù)看起來更炫”。門診系統(tǒng)最核心的是穩(wěn)定、清晰、數(shù)據(jù)一致SpringBoot的穩(wěn)定性和低復(fù)雜度正好匹配。用Spring Cloud微服務(wù)化這個系統(tǒng)屬于典型的大炮打蚊子還容易在畢業(yè)設(shè)計階段把自己繞暈。2.2 MyBatis-Plus為什么是省心之選持久層框架我已經(jīng)連續(xù)幾年推薦MyBatis-Plus尤其在畢業(yè)設(shè)計項目里。理由很直接CRUD效率高查詢條件構(gòu)造器好用同時還能保留手寫SQL的能力。MyBatis-Plus內(nèi)置的BaseMapper提供了insert、deleteById、selectById、updateById這些單表CRUD十張表左右的業(yè)務(wù)少寫幾百行重復(fù)的XML。它的查詢條件構(gòu)造器LambdaQueryWrapper對多條件組合查詢非常友好比如門診系統(tǒng)里“按科室查今天的掛號單”“按藥品名稱模糊搜藥品”“按狀態(tài)查待收費處方”一行代碼就能拼出條件查詢。最實用的是分頁插件。門診系統(tǒng)的列表頁基本都有分頁需求MyBatis-Plus的PaginationInnerInterceptor配置一下Page對象傳進(jìn)去就能完成物理分頁不用自己拼LIMIT。還有一點它的邏輯刪除功能很適合門診系統(tǒng)的檔案管理場景比如患者刪除操作用邏輯刪除打標(biāo)記既保留歷史數(shù)據(jù)又避免關(guān)聯(lián)表的外鍵報錯。建議把基礎(chǔ)CRUD交給MyBatis-Plus掛號并發(fā)扣減、庫存扣減這類寫復(fù)雜SQL或需要鎖定行的地方直接注解手寫SQL。框架和手寫結(jié)合既有效率又有掌控感。2.3 前端方案Thymeleaf還是前后端分離前端選型常見的有兩種Thymeleaf模板渲染或者Vue Axios的前后端分離。如果你想盡可能把精力集中在后端和答辯講解上選Thymeleaf加Bootstrap。服務(wù)端使用Spring MVC的Controller返回視圖數(shù)據(jù)通過Model傳過去在HTML里用簡單語法渲染列表、循環(huán)、拼接URL。優(yōu)點是一套工程搞定不用為跨域煩惱也不用部署兩套環(huán)境。對沒有系統(tǒng)學(xué)過前端、只掌握基礎(chǔ)HTML/CSS的同學(xué)來說這個方案最友好。如果你的重點是展示現(xiàn)代Web工程能力和前后端協(xié)作可以選Vue Spring Boot前后端分離。把后端做成純RESTful API前端單獨用Vite或Vue CLI搭建。這樣做的好處是界面交互體驗更好也貼近真實工作場景但前期準(zhǔn)備工作多一截跨域處理、Token傳遞、前端環(huán)境搭建、打包部署。我的建議很實際按自己擅長的來。如果時間緊、后端吃緊果斷用Thymeleaf如果對Vue有一定基礎(chǔ)愿意多花兩周調(diào)前端那可以走前后端分離答辯時也確實多一個可展示的亮點。3. 數(shù)據(jù)庫設(shè)計先把表結(jié)構(gòu)畫明白門診系統(tǒng)能不能跑得順數(shù)據(jù)庫設(shè)計占七成。表建錯了后面接口怎么寫都別扭。這塊我會把核心表拆開講附帶關(guān)鍵的字段設(shè)計思路這些都是可以直接抄作業(yè)的。3.1 核心表清單與關(guān)系按主流程拆核心業(yè)務(wù)表我習(xí)慣分成五組基礎(chǔ)檔案sys_user登錄賬號、sys_role角色、sys_user_role用戶角色關(guān)聯(lián)、sys_dept科室、doctor_info醫(yī)生信息、patient_info患者檔案排班預(yù)約doctor_schedule醫(yī)生排班、registration掛號單診療處方medical_record病歷、prescription處方主表、prescription_item處方明細(xì)收費藥房charge_record收費記錄、refund_record退費記錄、drug_info藥品目錄、drug_stock藥品庫存輔助擴(kuò)展sys_log操作日志、schedule_config系統(tǒng)參數(shù)表之間關(guān)系也清晰。patient_info與registration是一對多一個患者可以有多次掛號。doctor_schedule與registration也是一對多一個排班格子會被多次掛號但需要限制掛號數(shù)量。registration與prescription是一對一或一對多一次就診可能開出一張主處方加多個明細(xì)項。charge_record關(guān)聯(lián)掛號單或處方一份賬單對應(yīng)一張?zhí)幏?。drug_info與drug_stock是一對一藥品基礎(chǔ)信息和庫存數(shù)量分開管理。設(shè)計時要注意一個原則主表加明細(xì)表的模式在處方模塊里最優(yōu)。prescription記錄就診ID、醫(yī)生ID、患者ID、總金額、開單時間、狀態(tài)prescription_item記錄每條藥品的藥品ID、數(shù)量、單價、單項金額。這么做的好處是打印處方時按主表信息顯示頭部按明細(xì)表逐行顯示藥品統(tǒng)計科室用藥量也直接對明細(xì)表聚合。3.2 關(guān)鍵字段設(shè)計的門道很多同學(xué)建表很隨意字段意思不夠明確類型長度拍腦袋。這里我挑幾個容易踩坑的字段細(xì)說。第一個是金額字段。處方金額、收費金額、退費金額一律用DECIMAL(10, 2)Java對應(yīng)BigDecimal。嚴(yán)禁使用Double或Float存儲金額二進(jìn)制浮點數(shù)在加減運算時會出現(xiàn)0.1加0.2不等于0.3這類精度問題門診每天幾百筆收費金額對不上賬非常麻煩。數(shù)據(jù)庫用DECIMAL傳參用BigDecimal計算過程更不允許隨手轉(zhuǎn)成double。第二個是狀態(tài)字段。掛號單狀態(tài)、處方狀態(tài)、收費狀態(tài)、退費狀態(tài)建議用TINYINT存數(shù)字不要用字符串存中文。比如掛號單狀態(tài)定義0已預(yù)約 1已掛號 2已接診 3已結(jié)賬 4已退號 5已爽約處方狀態(tài)定義0待收費 1已收費 2已發(fā)藥 3已退費。數(shù)字狀態(tài)的好處是數(shù)據(jù)庫索引效率更高后端用枚舉類統(tǒng)一維護(hù)不容易出現(xiàn)“已繳交”和“已繳費”這種同一含義兩種寫法的問題。第三個是時間字段。預(yù)約時間、就診時間、收費時間、發(fā)藥時間統(tǒng)一用datetime類型Java端用LocalDateTime。特別注意前端傳時間字符串時后端要用DateTimeFormat(pattern yyyy-MM-dd HH:mm:ss)或JsonFormat統(tǒng)一指定格式否則早晚遇到LocalDateTime反序列化報錯問題這個在本地能跑、部署后報錯的概率極高。第四個是患者主索引字段。門診系統(tǒng)的患者信息身份證號是天然的關(guān)聯(lián)標(biāo)識但存在身份證號缺失或填寫錯誤的情況。我的建議是設(shè)計一個patient_no字段作為患者唯一編號由系統(tǒng)生成業(yè)務(wù)上主鍵仍然用自增ID但整個業(yè)務(wù)查詢優(yōu)先走patient_no。這樣即使同一個患者信息被錄入了兩次通過patient_no也能快速合并。3.3 排班表與號源控制的建模思路醫(yī)生排班是掛號系統(tǒng)的前置依賴。排班表我設(shè)計成按時間段拆行而不是一張表硬塞一周的安排。doctor_schedule字段包括doctor_id、dept_id冗余科室方便查詢、schedule_date出診日期、period_type時間段如上午、下午、period_time具體起止時間可選、total_number總號數(shù)、used_number已約號數(shù)、status0正常 1停診 2已滿。有的同學(xué)喜歡把一周七天分七個字段存查詢?nèi)菀讓懙虐嗾{(diào)整極其麻煩我建議還是拆行一行就是一個可售賣的號源批次邏輯清晰控制號源就變成了對schedule表做更新。排班與掛號之間的關(guān)聯(lián)掛號時先校驗排班狀態(tài)再校驗已約號數(shù)小于總號數(shù)然后進(jìn)行扣減。這里的并發(fā)控制我會在后續(xù)模塊實現(xiàn)里詳細(xì)說但核心思路就是利用數(shù)據(jù)庫行級鎖或樂觀鎖避免兩個患者同時掛到最后一張?zhí)枴?. 核心鏈路從掛號到發(fā)藥怎么串起來功能列表寫在需求文檔里是一回事在代碼里把數(shù)據(jù)流轉(zhuǎn)串起來又是另一回事。這一章我就按主流程一關(guān)一關(guān)過每關(guān)點出最關(guān)鍵的技術(shù)問題。4.1 掛號預(yù)約防重復(fù)提交是頭號工程掛號接口是整個系統(tǒng)中并發(fā)最敏感的部分。尤其是針對熱門科室?guī)讉€患者同時掛同一醫(yī)生的剩余號源后端處理不好就會出現(xiàn)超掛。我們設(shè)計掛號的業(yè)務(wù)邏輯首先是檢查排班可用號數(shù)。使用排班表的已用號和總號數(shù)判斷當(dāng)前是否可掛。如果前端的用戶同時點了兩次提交后端若只是先select再update兩次請求都會讀到used_number8總數(shù)10于是都執(zhí)行更新數(shù)據(jù)庫里的used_number被覆蓋成9但實際生成了兩張掛號單。解決這個問題推薦兩種方式我更建議兩種結(jié)合使用。方式一數(shù)據(jù)庫樂觀鎖。更新排班表時使用條件更新UPDATE doctor_schedule SET used_number used_number 1 WHERE schedule_id ? AND used_number total_number。這條SQL本身是原子操作MySQL的UPDATE會鎖住對應(yīng)行只有滿足used_number小于total_number才更新成功。受影響行數(shù)為0說明號源已滿直接返回提示。方式二業(yè)務(wù)層冪等校驗。在registration表上建立唯一索引patient_id、schedule_id、registration_date或者用Redis的SETNX記錄“某患者今天已掛號某排班”的標(biāo)記。數(shù)據(jù)庫唯一索引靠譜且無需額外組件用Redis更靈活。我實測下來把這兩者結(jié)合最穩(wěn)。業(yè)務(wù)方法加Transactional確保掛號單插入和排班更新在同一事務(wù)里任何一個失敗都回滾。再配合事務(wù)加WHERE條件更新基本杜絕了超掛。提示不要只做“前端按鈕置灰”就以為安全了。前端防重只是體驗優(yōu)化真正的防線在后端的唯一約束和行鎖。4.2 醫(yī)生接診與處方生成患者掛號之后進(jìn)入候診列表醫(yī)生在醫(yī)生工作臺看到待接診患者。接診動作把掛號單狀態(tài)從“已掛號”更新為“已接診”然后填寫病歷再開處方。處方生成的核心邏輯是主表和明細(xì)表同時落庫。為了防災(zāi)必須先compute每行單項金額、合計總金額再一次性完成插入。這里有個細(xì)節(jié)藥品單價要從drug_info表讀取禁止前端傳單價進(jìn)來。原因是藥品調(diào)價是常見操作如果單價由前端傳入存在篡改或傳遞臟數(shù)據(jù)的風(fēng)險。后端根據(jù)藥品ID查目錄單價然后計算金額前端只負(fù)責(zé)展示。同時注意處方狀態(tài)機的推進(jìn)剛創(chuàng)建為待收費收費成功后置為已收費藥房發(fā)藥后置為已發(fā)藥。每一步都在Service層封裝成獨立方法并且更新狀態(tài)時帶上“當(dāng)前狀態(tài)”條件防止亂序更新。開處方的事務(wù)邊界先寫處方主表和明細(xì)表再更新接診狀態(tài)。假如先更新接診狀態(tài)再寫處方處方失敗時接診狀態(tài)已經(jīng)變了患者就再也進(jìn)不了接診列表了。事務(wù)要么全成功要么全回滾狀態(tài)的一致性靠這個保證。4.3 收費與庫存的聯(lián)動收費窗口拿到處方后操作員點“收費”后端要做的事不止是記錄收費流水還要關(guān)聯(lián)處方狀態(tài)、余額臺賬和藥房庫存。首先校驗處方狀態(tài)為“待收費”防止重復(fù)收費。重復(fù)點擊“收費”按鈕是真實門診環(huán)境里常見的誤操作沒做防重會出現(xiàn)一筆處方被扣兩次錢。線上線下我都遇過這種案例加一個charge_record表的唯一索引prescription_id就能擋住。校驗通過后創(chuàng)建收費記錄處方狀態(tài)改為“已收費”。這里要說明一點我建議收費時不管庫存而是發(fā)藥時扣庫存這更符合藥店業(yè)務(wù)真實邏輯。收費只是資金結(jié)算發(fā)藥才是實物出庫。收費后如果藥房庫存不足系統(tǒng)需要提示庫存不足引導(dǎo)線下想解決方案或退費處理。所以收費邏輯不復(fù)雜核心是狀態(tài)校驗和金額記錄。真正復(fù)雜一點的是發(fā)藥扣庫存。發(fā)藥動作要“刪除”對應(yīng)庫存SQL寫成原子更新UPDATE drug_stock SET stock_number stock_number - #{num} WHERE drug_id #{drugId} AND stock_number #{num}。受影響行數(shù)為0說明庫存不足本次發(fā)藥失敗。關(guān)聯(lián)處方明細(xì)循環(huán)執(zhí)行這些UPDATE同樣用事務(wù)包裹。4.4 退號退費反向流程的設(shè)計細(xì)節(jié)正向流程誰都會寫反向流程才能真正體現(xiàn)考慮是否周全。門診系統(tǒng)的退號退費其實是兩個關(guān)聯(lián)但不能混為一談的操作。退號患者掛號后未就診之前可以取消掛號。操作鏈路是掛號單狀態(tài)變?yōu)椤耙淹颂枴迸虐啾淼膗sed_number減一號源釋放。這里務(wù)必注意一定要先校驗掛號單狀態(tài)是否為“已掛號”或“已預(yù)約”已經(jīng)接診的掛號單是不能退號的否則醫(yī)生的病歷數(shù)據(jù)會失去業(yè)務(wù)載體。退費處方已經(jīng)收費但未發(fā)藥時可以退費發(fā)藥后原則上只退藥不退費走退藥流程。退費操作要創(chuàng)建一筆退費記錄金額應(yīng)該從原收費記錄中沖減不是直接刪掉原收費記錄這是對賬需求決定的。有點抽象我舉例子如果一筆處方收費200元后來退了其中一盒藥這里就出現(xiàn)部分退費必須保留原收費記錄的200元新增退費記錄返回40元最后結(jié)算報表才能認(rèn)賬。退費流程務(wù)必加狀態(tài)機校驗已發(fā)藥的處方不允許直接退費。很多同學(xué)敗在這里因為只寫了退費接口沒有寫狀態(tài)校驗測試時正常一對接真實藥房流程就出現(xiàn)負(fù)數(shù)庫存。5. 權(quán)限模型與系統(tǒng)安全設(shè)計門診系統(tǒng)是業(yè)務(wù)系統(tǒng)涉及患者隱私和收費數(shù)據(jù)權(quán)限和安全不是可有可無的功能。這塊設(shè)計好了答辯的時候也能主動說說老師會眼前一亮。5.1 JWT登錄態(tài)與用戶認(rèn)證登錄方案我推薦JWT理由是無狀態(tài)、適合前后端分離、不需要額外的Session存儲。Spring Boot Spring Security或者Sa-Token做權(quán)限框架都可以我這邊更傾向于Sa-Token因為上手簡單文檔清晰不用像Spring Security那樣寫一堆配置類。JWT的核心流程是這樣用戶提交用戶名和密碼后端從sys_user表中校驗密碼。密碼建議用BCrypt加密存儲不要明文存、不要MD5存。校驗成功后生成包含用戶ID、用戶名、角色標(biāo)識的token過期時間建議12小時或24小時。前端每次請求把token放在Authorization請求頭中后端用一個攔截器解析token解析失敗或過期則返回401未認(rèn)證。這里我踩過一個坑JWT生成時如果把用戶信息全部塞進(jìn)載荷里一旦用戶改了資料token里的信息還是舊的。穩(wěn)妥做法是token里只放user_id和登錄時間需要其他用戶信息時拿著user_id去數(shù)據(jù)庫重新查。多個Redis存儲在線token也有助于主動踢人下線但在畢業(yè)設(shè)計階段JWT加攔截器已經(jīng)足夠了。5.2 基于角色的訪問控制RBACRole-Based Access Control是權(quán)限控制的經(jīng)典模型門診系統(tǒng)里非常適用。不同角色執(zhí)行不同操作醫(yī)生能看患者的掛號單、病歷、開處方不能看到收費金額明細(xì)醫(yī)生不需要接觸錢收費員能查處方、收費退費但看不到醫(yī)生寫的病歷診斷內(nèi)容藥房藥師能看到處方明細(xì)、庫存但不能修改藥品價格系統(tǒng)管理員做基礎(chǔ)配置但不參與任何診療和收費操作。具體實現(xiàn)上后端在每個接口上定義權(quán)限標(biāo)識比如RequiresRole(doctor)或RequiresPermissions(charge:pay)加在Controller方法上。攔截器或過濾器會對請求進(jìn)行角色校驗。注意一點前端菜單只是隱藏按鈕后端接口必須做權(quán)限校驗。只做前端隱藏不做后端校驗等同于把保險柜的門畫在了墻上。5.3 關(guān)鍵數(shù)據(jù)的操作留痕門診數(shù)據(jù)敏感尤其是收費、退費、發(fā)藥這類涉及錢和貨的操作一定要做操作日志。別小看這個模塊需求方很可能明確要求。我的做法是設(shè)計一張sys_log表字段包括operator_id、operator_name、operation_type登錄、掛號、收費、退費、發(fā)藥、修改藥品、刪除檔案、target_type操作對象類別、target_id對象ID、detail操作前后的關(guān)鍵信息摘要、operation_time?？梢允褂肧pring AOP配合自定義注解一個OperationLog注解標(biāo)在方法上切面自動記錄調(diào)用者、參數(shù)、耗時實現(xiàn)無侵入式日志采集。實際操作里還有一件事容易被忘患者隱私數(shù)據(jù)展示時要脫敏。比如列表頁手機號顯示138****1234身份證號顯示前三位后四位詳情頁根據(jù)角色權(quán)限決定是否展示完整信息。這個可以做在服務(wù)端返回前的脫敏方法里或者后端做序列化時的脫敏。這屬于安全細(xì)節(jié)大多數(shù)畢業(yè)設(shè)計都會漏你做了就是差異化亮點。6. 高頻問題與排查實錄這個系統(tǒng)我前后見過不少人復(fù)現(xiàn)也親手調(diào)過不少問題。把最常見的高頻問題整理成一份排查速查如下面兩張表問題現(xiàn)象排查思路解決方案掛號重復(fù)提交生成兩條掛號單前端按鈕只禁用了一次后端沒防重registration表加唯一索引排班更新用原子UPDATE本地跑得好好的部署到服務(wù)器上時間差8小時沒配置JVM時區(qū)MySQL時區(qū)不一致連接串加serverTimezoneAsia/ShanghaiJVM啟動參數(shù)加-Duser.timezoneGMT08收費金額出現(xiàn)一堆小數(shù)位對不上賬用了Double/Float計算金額全面改BigDecimal數(shù)據(jù)庫改DECIMAL(10,2)事務(wù)方法沒生效數(shù)據(jù)寫到一半同類內(nèi)部方法調(diào)用Transactional被自調(diào)用繞過把方法拆分到獨立Service或者用AspectJ代理方式處理分頁查詢的數(shù)據(jù)重復(fù)MyBatis-Plus分頁插件未正常配置正確添加PaginationInnerInterceptor并注冊為Bean患者退費后藥房庫存變了負(fù)數(shù)發(fā)藥狀態(tài)校驗缺失退費不校驗是否已發(fā)藥增加狀態(tài)機校驗已發(fā)藥禁止直接退費必須走退藥流程前端跨域無法請求后端未配置CORS寫全局CorsFilter或Spring CORS配置類6.1 掛號并發(fā)場景下的重復(fù)提交這個是真現(xiàn)場最常翻車的點我多展開說一說細(xì)節(jié)。并發(fā)重復(fù)提交有幾種情況一個是同一個患者重復(fù)點掛號按鈕另一個是多個患者同時搶最后一個號源。它們本質(zhì)上都可能導(dǎo)致同一排班被超掛。我推薦的組合方案是數(shù)據(jù)庫唯一約束兜底 原子更新控制號源。具體這樣設(shè)計registration表加唯一索引uk_patient_schedule_datepatient_id, schedule_id, registration_date掛號Service方法上加Transactional先執(zhí)行原子上限UPDATE受影響行數(shù)大于0才繼續(xù)插入掛號單插入掛號單時如果唯一鍵沖突拋出DuplicateKeyException由全局異常處理器捕獲并提示“該患者當(dāng)天已掛過此科室請勿重復(fù)掛號”。這個方案的好處是即使遇到并發(fā)數(shù)據(jù)庫的鎖和唯一約束會保證決策一致性不會出現(xiàn)“兩人都成功掛到最后一張?zhí)枴钡碾x譜問題。我實測并發(fā)200線程壓過這個方案數(shù)據(jù)一致性是可靠的。6.2 事務(wù)不生效的類型與規(guī)避事務(wù)問題太典型了。癥狀一般是一條數(shù)據(jù)插進(jìn)去了另一張表更新失敗但數(shù)據(jù)沒有回滾。排查時優(yōu)先檢查這幾個位置。類上有沒有加Service方法有沒有加Transactional這兩個條件少一個都不行。還需要檢查方法是否是public權(quán)限。protected或private方法Spring AOP代理根本調(diào)用不到事務(wù)自然失效。還要看異常有沒有被吞掉。很多同學(xué)喜歡在Service方法里try-catch一把梭把異常捕獲了事務(wù)看到的是正常返回就不會回滾。最容易犯的自調(diào)用問題pairedService內(nèi)部方法A調(diào)用方法BB上面有Transactional但A調(diào)用B是通過this調(diào)用的沒走代理對象事務(wù)完全失效。解決方法是把B拆到獨立的Service類中然后注入調(diào)用或者在類里注入自身代理對象來調(diào)用。但拆Service更干凈也符合單一職責(zé)。對了注意事項Transactional默認(rèn)只回滾運行時異常如果需要回滾CheckedException要顯式設(shè)置rollbackForException.class。6.3 金額精度和前后端傳參金額相關(guān)的坑我一共總結(jié)出三條。第一條存儲必須用DECIMAL代碼用BigDecimal這個前面反復(fù)強調(diào)過。第二條前端輸入框允許輸入小數(shù)但用戶輸?shù)慕痤~字符串后端要用new BigDecimal(str)構(gòu)造不要用Double.parseDouble轉(zhuǎn)避免又走一遍浮點數(shù)誤差。第三條涉及金額的查詢和統(tǒng)計報表求和用SUM函數(shù)們不要先在Java里遍歷求和再轉(zhuǎn)字符串?dāng)?shù)據(jù)庫SUM對DECIMAL的處理是精確的。也有同學(xué)遇到前端收到金額變成科學(xué)計數(shù)法。這種情況下后端返回的JSON序列化器需要配置BigDecimal使用toPlainString輸出或者統(tǒng)一格式化為兩位小數(shù)返回給前端。配好之后傳參和顯示都干凈。6.4 LocalDateTime解析和時區(qū)問題用LocalDateTime替代Date是一種進(jìn)步但帶來了前后端格式處理的成本。如果后端返回的LocalDateTime字段前端直接顯示會是一串帶T的ISO字符串不符合界面展示習(xí)慣。解決辦法分兩層一是后端序列化配置注冊Jackson的JavaTimeModule并設(shè)置日期格式為yyyy-MM-dd HH:mm:ss二是每個接收時間參數(shù)的DTO字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)。如果用了MyBatis-Plus插入時對LocalDateTime的處理也需要在application.yml里開啟MapUnderscoreToCamelCase這類常規(guī)配置。時區(qū)問題剛才速查表里提過再強調(diào)一下數(shù)據(jù)庫連接串必須顯式指定serverTimezoneAsia/ShanghaiJVM如果跑在默認(rèn)時區(qū)不對的服務(wù)器上還要加-Duser.timezoneAsia/Shanghai。兩側(cè)都定死時區(qū)就不會出現(xiàn)測試時正常、部署后時間差8小時的詭異現(xiàn)象。7. 我的一些實際操作體會文章最后聊幾件我在開發(fā)過程中感觸最深的事。這算不上什么標(biāo)準(zhǔn)答案但都是真金白銀換來的經(jīng)驗供你參考。第一件事無論需求多著急先把狀態(tài)流轉(zhuǎn)圖畫出來再動手。我在做模擬項目X的時候就是先把掛號單、處方、收費記錄幾張核心表的狀態(tài)機畫在紙上從初始到終態(tài)每條線都標(biāo)出來后面寫接口基本不猶豫。狀態(tài)都不清就開始寫代碼改一個流程就要連帶改三張表耗時至少翻倍。第二件事測試數(shù)據(jù)一定要貼近真實情況。往里塞假數(shù)據(jù)的時候別用“張三李四王五”這種要做一批類似“姓名張三身份證110101199001011234掛號科室內(nèi)科就診時間2025-05-20 09:30”這樣格式完整的數(shù)據(jù)。這樣能提前發(fā)現(xiàn)時間格式問題、身份證字段長度不夠的問題、日期區(qū)間查詢的邊界問題。這些如果在驗收演示時突然報錯非常破壞印象分。第三件事合理的模塊拆分能救命。系統(tǒng)雖然小但Controller、Service、Mapper、Entity、DTO、VO這樣的分層一定要清晰。答辯時老師讓你講講某段代碼你如果指著三層嵌套的業(yè)務(wù)邏輯說不出所以然那印象分明顯受影響。分層清楚也代表你有工程習(xí)慣這本身就是加分項。最后再說一句掏心窩的話門診系統(tǒng)這類題目的價值不僅在于“完成一個系統(tǒng)”更在于讓你體驗一次真實的業(yè)務(wù)閉環(huán)。從需求分析到數(shù)據(jù)庫設(shè)計從前端交互到并發(fā)控制每跨過一次坑你學(xué)到的都比單純背八股文要多得多。復(fù)現(xiàn)這套系統(tǒng)之后如果還有余力可以考慮把檢查申請、科室?guī)齑骖A(yù)警、數(shù)據(jù)看板這幾個擴(kuò)展點加進(jìn)去這就是一個能拿去實習(xí)面試?yán)镏v完整故事的智慧門診綜合服務(wù)平臺了。