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