又到一年畢設(shè)季后臺收到不少私信都在問“能不能推薦一個好過、實用、還能學(xué)到真東西的題目”。今天直接聊透一個經(jīng)典中的經(jīng)典基于 SpringBoot Vue MySQL 的社區(qū)醫(yī)院管理系統(tǒng)。這個題目完全不依賴高深的算法主要考察全棧基本功業(yè)務(wù)需求也貼合普通社區(qū)醫(yī)院的真實場景做出來之后答辯時每個模塊都能拿出實際的東西講。不管是選題目、寫代碼、還是最終打包部署這篇文章會把整條鏈路的關(guān)鍵節(jié)點全部拆開細(xì)到連數(shù)據(jù)庫表怎么建、JWT 令牌怎么存、跨域怎么處理、打包文件怎么配都走一遍希望能讓準(zhǔn)備做同類項目的同學(xué)少走點彎路。1. 項目整體設(shè)計與思路拆解1.1 為什么是 SpringBoot Vue 這套組合先說選型的大邏輯。市面上畢設(shè)管理系統(tǒng)五花八門但 SpringBoot Vue MySQL 始終是主流選擇理由很現(xiàn)實這套組合對新手友好、資料齊全、就業(yè)市場上也認(rèn)可度極高。后端用 SpringBoot核心看中的是“約定大于配置”的理念。傳統(tǒng) SSM 框架需要寫一堆 XML 配置文件SpringBoot 只要依賴引入進(jìn)來自動配置機(jī)制就能把大部分組件裝配好。寫 RESTful 接口直接用 RestController、RequestMapping 一套注解一個 jar 包打出來就能跑這對時間緊、任務(wù)重的畢設(shè)黨來說實在太關(guān)鍵了。同時 Spring 家族本身的學(xué)習(xí)曲線很平滑IOC 容器幫你管理對象依賴AOP 能拿來統(tǒng)一處理日志和事務(wù)理解這些設(shè)計模式對后續(xù)面試也很有幫助。前端選 Vue 則是看中它的漸進(jìn)式框架特性。Vue 官方文檔對中文用戶極其友好模板語法上手速度比 Angular 和 React 快得多。組件化開發(fā)模式能讓頁面代碼各管各的比如系統(tǒng)管理頁面、掛號頁面、藥房頁面分別封裝成組件各改各的互不影響。Vue 的雙向數(shù)據(jù)綁定機(jī)制也讓表單操作變得非常直觀v-model 一行指令就能把表單控件和業(yè)務(wù)數(shù)據(jù)綁定起來不用像 jQuery 時代那樣手動操作 DOM 取值回填。MySQL 承擔(dān)數(shù)據(jù)存儲任務(wù)三個字總結(jié)就是夠用、免費(fèi)、通用。社區(qū)醫(yī)院的業(yè)務(wù)量大概幾千條患者記錄、幾百種藥品MySQL 輕松勝任。而且 MySQL 是絕大多數(shù)學(xué)校數(shù)據(jù)庫課程的御用數(shù)據(jù)庫學(xué)生通常已經(jīng)有一定基礎(chǔ)不用為了做個畢設(shè)再去學(xué) PostgreSQL 或 Oracle。1.2 需要提前想清楚的三個前置規(guī)劃動手寫代碼之前有幾個問題值得先想清楚第一個是業(yè)務(wù)邊界問題——社區(qū)醫(yī)院系統(tǒng)到底要覆蓋哪些模塊社區(qū)醫(yī)院和大型三甲醫(yī)院的業(yè)務(wù)體量完全不同如果把藥房、住院、手術(shù)排期、檢驗檢查全部塞進(jìn)去工作量直接爆炸。我的建議是控制在 6 到 8 個核心模塊系統(tǒng)管理用戶、角色、菜單、醫(yī)生管理、患者管理、門診掛號、醫(yī)生開方、藥房管理。這個范圍既能體現(xiàn)出系統(tǒng)的完整性又不會讓自己陷入無休止的 CRUD 泥潭。論文里也好組織內(nèi)容每個模塊對應(yīng)一章邏輯線清晰。第二個是系統(tǒng)角色劃分問題。社區(qū)醫(yī)院場景里天然存在三類用戶管理員、醫(yī)生、護(hù)士或藥房人員患者通常不直接登錄系統(tǒng)而是由護(hù)士代為操作。這樣劃分完畢后權(quán)限控制的模型就清楚了管理員管系統(tǒng)配置和全局?jǐn)?shù)據(jù)醫(yī)生管診斷與開方護(hù)士管掛號和收費(fèi)。這個角色模型直接決定數(shù)據(jù)庫的用戶表怎么設(shè)計、前端路由守衛(wèi)怎么配置。第三個問題是技術(shù)方案的盲區(qū)——相關(guān)技術(shù)到底要掌握到什么程度才足以應(yīng)對答辯時老師的深挖比如 Redis 這種緩存組件系統(tǒng)里可以用它來存 JWT 令牌或者驗證碼但有些同學(xué)對 Redis 只停留在“聽說過”的層面答辯時老師一追問緩存穿透、緩存雪崩就卡殼。我的建議是技術(shù)棧不要貪多而是保證你寫在論文里的每一個技術(shù)點自己都能解釋清楚底層原理。寧可省掉 Redis用數(shù)據(jù)庫表來實現(xiàn)驗證碼功能也要保證自己寫的每一行代碼都經(jīng)得起追問。2. 核心業(yè)務(wù)模塊與數(shù)據(jù)庫設(shè)計解析2.1 社區(qū)醫(yī)院的業(yè)務(wù)主流程搞清楚業(yè)務(wù)主流程數(shù)據(jù)庫表之間的關(guān)系自然就浮現(xiàn)了。社區(qū)醫(yī)院一個完整的就診流程是這樣的患者來到醫(yī)院 → 掛號室錄入患者信息新患者建檔老患者直接選 → 護(hù)士選擇科室和醫(yī)生進(jìn)行掛號 → 患者去診室找醫(yī)生 → 醫(yī)生查看患者基本信息可以補(bǔ)充錄入病史、癥狀描述 → 醫(yī)生做出診斷展開處方選擇藥品、數(shù)量、用法 → 患者去藥房窗口 → 藥房人員核查處方進(jìn)行出庫發(fā)藥操作。這個流程對應(yīng)到系統(tǒng)里就是一條清晰的“患者建檔 → 掛號 → 診斷 → 開方 → 發(fā)藥”業(yè)務(wù)鏈路。核心是掛號信息和處方信息兩個樞紐掛號記錄關(guān)聯(lián)了患者和醫(yī)生處方記錄關(guān)聯(lián)了就診記錄和藥品整個系統(tǒng)都是圍繞這兩條樞紐展開的。2.2 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計要點數(shù)據(jù)庫設(shè)計做得好不好直接決定寫后端代碼時是清風(fēng)拂面還是寸步難行。下面拿社區(qū)醫(yī)院系統(tǒng)的核心表來講講設(shè)計思路。用戶表sys_user所有系統(tǒng)賬號信息都在這里。關(guān)鍵字段有 id、username、password、real_name、role_id、status。密碼必須經(jīng)過 BCrypt 加密再存儲絕對不能明文存放。status 字段做啟用禁用控制status 1 表示啟用0 表示鎖定。role_id 關(guān)聯(lián)角色表用外鍵邏輯維護(hù)?；颊弑韕atient字段包括 id、name、gender、birth_date、id_card、phone、address、allergy_history、create_time。這里有兩個坑值得注意一是身份證號要用 VARCHAR 類型而不是 BIGINT因為身份證號超過 BIGINT 的精度范圍用整型存會丟精度二是過敏史字段強(qiáng)烈建議預(yù)留社區(qū)醫(yī)院場景下這個信息對醫(yī)生用藥非常重要錯過這個字段會讓系統(tǒng)專業(yè)度大打折扣。醫(yī)生表doctor字段包含 id、user_id、name、department_id、title、introduction、schedule_time。注意字段冗余的核心技巧——醫(yī)生姓名和所屬科室除了在醫(yī)生表里存儲同時可以在掛號記錄表里冗余一份。這樣查詢掛號記錄時不用每次 join 醫(yī)生表和科室表特別是在列表頁需要頻繁展示這些信息的時候省掉的聯(lián)表開銷非?？捎^?？剖冶韉epartment字段為 id、name、description。有些同學(xué)喜歡直接把科室名字寫死在醫(yī)生表里這種不可持續(xù)的方案在寫統(tǒng)計報表或篩選功能時會非常痛苦。獨立出一張科室表后續(xù)擴(kuò)展科室簡介、科室排班都方便前端下拉框的數(shù)據(jù)來源也有了著落。掛號記錄表registration這個是核心業(yè)務(wù)表。字段包括 id、patient_id、doctor_id、department_id、register_date、period、visit_status、fee、operator_id。visit_status 的典型狀態(tài)值有 0待就診、1已就診、2已退號。period 字段表示坐診時段可以劃分為上午和下午。一條掛號記錄應(yīng)該同時冗余存了患者姓名、醫(yī)生姓名、科室名稱方便列表頁面直接展示。處方表prescription字段有 id、registration_id、diagnosis、advice、total_amount、create_time。一個掛號記錄可以對應(yīng)一張?zhí)幏教幏嚼锿ㄟ^明細(xì)表和藥品關(guān)聯(lián)。diagnosis 字段存醫(yī)生診斷的文本內(nèi)容advice 存醫(yī)囑信息。處方明細(xì)表prescription_item這是典型的中間關(guān)聯(lián)表字段有 id、prescription_id、drug_id、quantity、usage_method、dosage。為什么處方和藥品需要一張中間表而不是在處方表里存一個藥品 JSON 字符串因為藥房出庫時需要對每一種藥品做扣減庫存操作逐條遍歷明細(xì)記錄就能精確更新每個藥品的庫存和本次發(fā)藥數(shù)量。如果設(shè)計成字符串存儲統(tǒng)計用藥量、查藥品銷售排行這些功能會變得非常痛苦。藥品表drug字段為 id、drug_code、name、specification、unit、manufacturer、purchase_price、sale_price、stock_quantity、status。庫存字段在整個業(yè)務(wù)鏈路中是最敏感的數(shù)據(jù)藥房發(fā)藥時量必須做事務(wù)處理減庫存且藥品價格采用零售價而不是進(jìn)價符合醫(yī)院實際收費(fèi)邏輯。核心表設(shè)計完畢后表之間的邏輯關(guān)系就清晰了sys_user 上聯(lián)角色表醫(yī)生和護(hù)士的賬號關(guān)聯(lián)到員工信息patient 通過 registration 和 doctor 關(guān)聯(lián)prescription 作為樞紐連接 registration 和 drug。外鍵約束建議在物理表中建立但實際開發(fā)中建議以邏輯外鍵為主、物理外鍵為輔因為物理外鍵會影響刪除操作靈活性系統(tǒng)內(nèi)置的強(qiáng)制約束注定了后期維護(hù)成本高。2.3 表字段設(shè)計的幾個實用經(jīng)驗建表的時候有幾個通用經(jīng)驗畢設(shè)項目里用上會顯得很專業(yè)每張表都保留 create_time、update_time 兩個審計字段。MyBatis Plus 提供的自動填充功能只需要配兩個 MetaObjectHandler 處理器就能自動維護(hù)這兩個字段的值不需要每寫一條 SQL 手動 set 時間。這個細(xì)節(jié)代碼量不大但答辯評委看到的會是一個具備“工程素養(yǎng)”的作品而不只是“作業(yè)”。刪除方式統(tǒng)一使用邏輯刪除而不是物理刪除。表里加一個 deleted 字段默認(rèn) 0刪除操作變成 UPDATE而不是 DELETE。這樣患者誤刪了可以恢復(fù)也更貼合醫(yī)院檔案管理的合規(guī)需求。MyBatis Plus 有 TableLogic 注解配置后所有查詢都會自動過濾掉已刪除的數(shù)據(jù)代碼層面對這個機(jī)制完全透明。金額字段統(tǒng)一用 DECIMAL(10, 2) 而不是 DOUBLE。浮點數(shù)在金額計算中會有精度誤差比如 1.1 2.2 3.3000000000000003這在收費(fèi)場景里是絕對無法接受的。DECIMAL 類型在 MySQL 中基于字符串存儲精度完全可控Java 對應(yīng)使用 BigDecimal 類型。這個細(xì)節(jié)做到位論文里可以直接寫出一小段關(guān)于“金額精度控制設(shè)計”的內(nèi)容。3. 前后端核心功能實現(xiàn)與實際編碼3.1 后端接口與認(rèn)證授權(quán)設(shè)計后端項目推薦用 Maven 構(gòu)建組織結(jié)構(gòu)能清晰地體現(xiàn)分層架構(gòu)controller、service、mapper、entity、config、common、dto 這些包各司其職。entity 放數(shù)據(jù)庫表映射實體dto 放請求和響應(yīng)對象common 放統(tǒng)一返回結(jié)果類 Result 和異常處理類。統(tǒng)一返回結(jié)果類是后端設(shè)計的亮點代碼大概長這樣public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.code 200; result.message success; result.data data; return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.code code; result.message message; return result; } }每個 Controller 方法都返回 Result 包裝的響應(yīng)體前端拿到數(shù)據(jù)后只需判斷 code 是否為 200再決定是否渲染數(shù)據(jù)。這種統(tǒng)一封裝能極大簡化前后端對接成本也是答辯時值得好好講的設(shè)計點。登錄認(rèn)證模塊的選型方案主流有兩種JWT 令牌和 Session。無狀態(tài)方案用 JWT 最合適流程是這樣的用戶登錄提交用戶名密碼 → 后端校驗 BCrypt 密碼 → 生成 JWT 令牌 → 返回給前端 → 前端存入 localStorage → 之后每次請求在請求頭帶上 Authorization: Bearer token → 后端攔截器解析 token 并校驗有效性。相比 Session 機(jī)制JWT 不需要在后端存會話記錄天然適合將來做前后端分離部署。攔截器配置是 JWT 認(rèn)證的關(guān)鍵環(huán)節(jié)核心代碼邏輯要處理放行登錄接口、OPTIONS 請求、靜態(tài)資源其余接口一律驗證 tokenpublic class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equals(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { String realToken token.substring(7); if (JwtUtil.verify(realToken)) { return true; } } response.setStatus(401); return false; } }這里有兩個特別容易踩坑的點一是預(yù)檢請求處理——瀏覽器發(fā)跨域請求前會先發(fā)一個 OPTIONS 預(yù)檢測請求不把這個情況放行掉前端調(diào)接口時會出現(xiàn)一直報 401 的現(xiàn)象二是 token 過期情況——JWT 中應(yīng)設(shè)置合理過期時間比如 12 小時過期后需要前端攔截 401 響應(yīng)自動跳轉(zhuǎn)到登錄頁。這兩點處理好登錄態(tài)體驗就會順暢很多。3.2 數(shù)據(jù)庫連接與表操作MySQL項目配置文件中數(shù)據(jù)庫連接相關(guān)信息是基礎(chǔ)中的基礎(chǔ)同時要注意幾個要點。dataSource 的 url 建議加上這兩個參數(shù)useUnicodetruecharacterEncodingutf8 保證中文不亂碼serverTimezoneAsia/Shanghai 保證時區(qū)一致。針對 MySQL 8.x 的驅(qū)動配置是 com.mysql.cj.jdbc.DriverMySQL 5.x 則是 com.mysql.jdbc.Driver——版本不匹配會直接導(dǎo)致連接失敗這個坑非常多同學(xué)踩過。配合 MyBatis Plus 使用Mapper 層不需要寫 XML。舉個實際例子查詢當(dāng)天的掛號列表只需要在 Mapper 接口里寫一個方法用注解寫 SQLMapper public interface RegistrationMapper extends BaseMapperRegistration { Select(SELECT * FROM registration WHERE register_date #{date} ORDER BY create_time DESC) ListRegistration selectByRegisterDate(LocalDate date); }MyBatis Plus 的 BaseMapper 內(nèi)置了單表增刪改查方法復(fù)雜一點的多表關(guān)聯(lián)查詢就直接寫自定義 SQL兩種方式的靈活度兼顧得很好。這里建議團(tuán)隊分工的時候記住一條鐵律多表操作務(wù)必用自定義 SQL 而非多個單表查詢在 Java 里做內(nèi)存組裝——在數(shù)據(jù)量小的時候兩者看不出來差別但一旦患者表數(shù)據(jù)過千內(nèi)存聯(lián)表就會成為性能瓶頸也是答辯時潛在的高頻問題點。3.3 前端 Vue 項目結(jié)構(gòu)設(shè)計前端推薦用 Vue CLI 創(chuàng)建項目主流的目錄結(jié)構(gòu)會形成這樣一種組織方式views 目錄下按模塊分類頁面admin、doctor、nurse、patientcomponents 目錄放公共組件api 目錄放模塊化接口請求文件router 目錄管理路由表store 目錄Pinia保存全局狀態(tài)比如當(dāng)前登錄用戶信息。路由守衛(wèi)是前端權(quán)限控制的核心實現(xiàn)。下面代碼實現(xiàn)了“未登錄訪問要登錄的頁面則跳轉(zhuǎn)登錄頁、已登錄訪問登錄頁則跳回首頁”的邏輯同時可以從路由 meta 字段讀取所需角色做精細(xì)化權(quán)限控制router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.path ! /login !token) { next({ path: /login }); return; } if (to.path /login token) { next({ path: / }); return; } const role localStorage.getItem(role); if (to.meta.roles !to.meta.roles.includes(role)) { next({ path: / }); return; } next(); });http 請求封裝方面使用了 axios 實例統(tǒng)一配置 baseURL 和 token 附帶的請求頭再用響應(yīng)攔截器統(tǒng)一處理后端返回的狀態(tài)碼。業(yè)務(wù)碼非 200 時彈出錯誤提示直接拿后端 Result 里的 message 展示給醫(yī)生或護(hù)士看。這樣能避免每個頁面各自去寫一遍彈窗提示邏輯代碼風(fēng)格也更統(tǒng)一。3.4 核心業(yè)務(wù)頁面實現(xiàn)細(xì)節(jié)拿醫(yī)生端開處方這個功能來舉例。醫(yī)生頁面點擊“我的今日待診列表”瀏覽器向后端發(fā)起 GET 請求后端查詢當(dāng)前醫(yī)生當(dāng)日所有待就診狀態(tài)的掛號記錄返回給前端渲染成列表。醫(yī)生點擊“開始接診”前端跳轉(zhuǎn)到就診詳情頁面頁面頂部顯示患者姓名、性別、年齡、過敏史下方是診斷錄入框和處方明細(xì)編輯區(qū)——藥品名稱輸入框帶自動補(bǔ)全基于 element-ui 的 Autocomplete 組件選定藥品后自動填入規(guī)格和零售價格只需要填寫數(shù)量、用法、用量。計算總金額的前端邏輯很簡單遍歷處方明細(xì)數(shù)組單價乘數(shù)量求和。這個操作在前端做沒有問題但要強(qiáng)調(diào)后端在下發(fā)保存接口時不要直接用前端傳來的 total_amount而是要在后端重新計算——原因在于醫(yī)院收費(fèi)的嚴(yán)肅性絕不能信任客戶端。后端計算邏輯大概是public Prescription createPrescription(PrescriptionDTO dto) { BigDecimal totalAmount BigDecimal.ZERO; Prescription prescription new Prescription(); prescription.setDiagnosis(dto.getDiagnosis()); prescription.setAdvice(dto.getAdvice()); ListPrescriptionItem items new ArrayList(); for (PrescriptionItemDTO itemDTO : dto.getItems()) { Drug drug drugMapper.selectById(itemDTO.getDrugId()); if (drug null || drug.getStockQuantity() itemDTO.getQuantity()) { throw new BizException(藥品庫存不足); } BigDecimal itemTotal drug.getSalePrice() .multiply(BigDecimal.valueOf(itemDTO.getQuantity())); totalAmount totalAmount.add(itemTotal); // 構(gòu)造明細(xì)數(shù)據(jù) PrescriptionItem item new PrescriptionItem(); item.setDrugId(drug.getId()); item.setQuantity(itemDTO.getQuantity()); item.setUsageMethod(itemDTO.getUsageMethod()); item.setDosage(itemDTO.getDosage()); item.setPrice(drug.getSalePrice()); items.add(item); } prescription.setTotalAmount(totalAmount); prescriptionMapper.insert(prescription); // 批量插入明細(xì) 扣減庫存在事務(wù)中執(zhí)行 return prescription; }注意這段代碼里隱藏的事務(wù)關(guān)鍵點創(chuàng)建處方時必須同步扣減庫存這兩個操作必須在一個數(shù)據(jù)庫事務(wù)里執(zhí)行任何一個失敗都要全部回滾否則會出現(xiàn)處方生成成功但庫存沒減、或者庫存扣了但處方創(chuàng)建失敗的嚴(yán)重數(shù)據(jù)不一致問題。Spring 的 Transactional 注解就是為這種場景準(zhǔn)備的加上之后數(shù)據(jù)庫會自動開啟事務(wù)管理。藥房發(fā)藥頁面相對簡單根據(jù)狀態(tài)篩選待發(fā)藥處方點擊發(fā)藥按鈕后后端執(zhí)行發(fā)藥確認(rèn)操作更新處方狀態(tài)為“已發(fā)藥”、更新藥品實際出庫記錄整個操作同樣需要事務(wù)控制。4. 部署文檔、論文寫作與常見問題排查實錄4.1 知乎上“部署”到底部署什么很多同學(xué)對“部署文檔”的理解停留在“能啟動就行”但一份合格的項目部署文檔是別人按照里邊步驟操作能完全復(fù)現(xiàn)環(huán)境并成功運(yùn)行的完整鏈條。我自己寫部署文檔習(xí)慣按環(huán)境維度分成三塊本地開發(fā)環(huán)境、服務(wù)器生產(chǎn)環(huán)境、數(shù)據(jù)庫初始化流程。本地開發(fā)環(huán)境主要交代 JDK 版本、Maven 版本、Node 版本、MySQL 版本的匹配矩陣。生產(chǎn)部署這一塊強(qiáng)烈建議使用寶塔面板對新手非常友好不用從零敲 Linux 命令。部署步驟概覽服務(wù)器裝寶塔 → 裝 MySQL、Nginx → 創(chuàng)建數(shù)據(jù)庫并導(dǎo)入 SQL 文件 → 上傳后端 jar 包 → 配置 Systemd 服務(wù)或直接寶塔的 Java 項目管理功能啟動 → 前端項目 npm run build 生成 dist 目錄 → 在 Nginx 中配置靜態(tài)目錄和反向代理 /api 到后端端口。整個過程捋得清清楚楚論文里抽出“系統(tǒng)部署”這一章也能直接使用實操中復(fù)雜的防火墻配置、端口占用、Maven 打包失敗等問題的處理過程也都要寫進(jìn)文檔作為FQ。數(shù)據(jù)庫初始化流程很重要但常常被忽略。社區(qū)醫(yī)院系統(tǒng)的 init.sql 腳本應(yīng)該包含完整的建表語句、初始管理員賬號用戶名 admin密碼經(jīng)過 BCrypt 加密、預(yù)設(shè)的科室數(shù)據(jù)以及演示用醫(yī)生、護(hù)士賬號。寫部署文檔時把數(shù)據(jù)庫腳本和賬號清單附表整理出來效果會非常好。4.2 后端打包部署的常見坑后端打包時最常遇到的坑就是 Maven 配置文件覆蓋問題。本地開發(fā)的 application.yml 和服務(wù)器部署的配置不相同比如 MySQL 密碼不同、端口可能被占用。解決方式是用 Maven Profile 機(jī)制配置多環(huán)境application-dev.yml 對應(yīng)本地開發(fā)環(huán)境application-prod.yml 對應(yīng)服務(wù)器正式環(huán)境。打包的時候用 -Pprod 參數(shù)指定激活哪個 profile不同環(huán)境打包出來的 jar 包會自動選取對應(yīng)配置文件。另一個高頻坑是 jar 包名稱和版本覆蓋問題。pom.xml 里 build 節(jié)點要配置 finalName將最終 jar 名整理為簡單的名稱比如 community-hospital-system.jar。否則打出來的 jar 包名又帶時間戳又帶版本號在服務(wù)器上手動敲命令啟動時會非常痛苦每次升級還得改腳本配置。前端部署還有一個經(jīng)典問題vite 配置的 proxy 只在開發(fā)環(huán)境下生效build 出來的文件沒有代理功能。所以生產(chǎn)環(huán)境下 Nginx 必須單獨配置反向代理server { listen 80; server_name your-domain.com; location / { root /opt/community-hospital/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }有個容易被忽略但影響巨大的點try_files $uri $uri/ /index.html; 這一行如果不寫刷新非根路徑的路由頁面時會直接 404因為 Vue Router 的 history 模式?jīng)]有對應(yīng)的物理文件。有些同學(xué)在本地調(diào)試時一直用默認(rèn)的 hash 模式?jīng)]發(fā)現(xiàn)問題部署后一刷新就崩這個點是部署現(xiàn)場排查手冊里最值得記錄的問題。4.3 常見問題與排查技巧速查表下面把實際開發(fā)和管理過程中最常見的坑整理成一張速查表遇到問題可以直接對照排除問題現(xiàn)象可能原因處理方式后端啟動報“Access denied for user”數(shù)據(jù)庫用戶名或密碼錯誤檢查 application.yml 中的賬號密碼確認(rèn) MySQL 權(quán)限列表前端請求接口跨域報錯后端未配置 CORS 或開發(fā)代理失效確認(rèn) Vue 開發(fā)環(huán)境使用 proxy 進(jìn)行代理生產(chǎn)環(huán)境檢查 Nginx 配置中文數(shù)據(jù)顯示為問號數(shù)據(jù)庫表編碼不是 utf8mb4建表時指定 ENGINEInnoDB DEFAULT CHARSETutf8mb4登錄后請求接口返回 401Token 過期或未正確放置請求頭檢查 axios 攔截器中是否配置 Authorization 請求頭確認(rèn) token 有效期時間字段顯示相差 8 小時數(shù)據(jù)庫時區(qū)和代碼時區(qū)不一致在 JDBC 連接串上添加 serverTimezoneAsia/Shanghai刷新頁面后出現(xiàn) 404Vue history 路由缺少 fallback 配置Nginx 配置中添加 try_files 規(guī)則Maven 打包后代碼還是舊的未執(zhí)行 clean 清理舊產(chǎn)物使用 mvn clean package 重新構(gòu)建前端 element-ui 組件樣式不生效樣式文件未全部引入main.js 中 import 完整樣式文件或按需引入的插件沒配好發(fā)起發(fā)藥操作后藥品庫存為負(fù)數(shù)扣減庫存邏輯未做校驗或事務(wù)異常在發(fā)藥前嚴(yán)格判斷 stock_quantity 是否足夠事務(wù)內(nèi)校驗庫存并拋出異常4.4 論文組織結(jié)構(gòu)與撰寫要點既然標(biāo)題帶了“論文部署文檔”論文這一環(huán)幾乎占了畢設(shè)一半的分?jǐn)?shù)。論文章節(jié)安排建議按這個骨架走第一章緒論背景、意義、國內(nèi)外現(xiàn)狀、第二章需求分析業(yè)務(wù)流程分析、角色分析、功能需求分析、第三章系統(tǒng)設(shè)計總體架構(gòu)、功能模塊設(shè)計、數(shù)據(jù)庫設(shè)計、第四章系統(tǒng)實現(xiàn)每個模塊的截圖核心代碼講解、第五章系統(tǒng)測試功能測試用例、性能測試、第六章總結(jié)不足與展望。核心寫作技巧只有一條系統(tǒng)測試章節(jié)千萬不要隨便寫“經(jīng)過測試系統(tǒng)運(yùn)行正常”。更專業(yè)一點的操作是把測試用戶、測試步驟、預(yù)期結(jié)果、實際結(jié)果列成一張完整的測試用例表格每個核心模塊至少列 5 條以上的用例覆蓋正常流與異常流。比如測試一個醫(yī)生開方功能正常流是“醫(yī)生選擇患者→填寫診斷→添加藥品→校驗庫存充足→保存成功”異常流就要覆蓋“藥品庫存不足時系統(tǒng)提示補(bǔ)貨”“沒有填寫診斷信息時系統(tǒng)攔截提交”。這樣的測試報告答辯的時候老師看了會非常放心覺得你是真正做過驗證的。摘要部分的寫法也值得注意絕對不能是“本文研究了一個系統(tǒng)”。好的摘要結(jié)構(gòu)要像這樣先交代背景社區(qū)醫(yī)院信息化建設(shè)需求、再說結(jié)果基于 SpringBoot Vue 實現(xiàn)了哪些模塊、再帶一個量化結(jié)果系統(tǒng)完成了 6 大模塊覆蓋日常診療流程經(jīng)過完整測試能穩(wěn)定運(yùn)行。文獻(xiàn)綜述部分一般列 10 到 15 篇文獻(xiàn)中英文各占一半其中部分內(nèi)容是 Springer、IEEE 數(shù)據(jù)庫里的英文文獻(xiàn)會讓論文看起來更有學(xué)術(shù)功底。5. 答辯準(zhǔn)備與避坑指南5.1 答辯前必須演練的高頻問題答辯環(huán)節(jié)老師要考察的其實不是代碼從哪兒來而是你是不是真的理解自己在做什么。以下幾個問題基本是每次必問提前打好腹稿再上會穩(wěn)得多“為什么選這個技術(shù)?！眲e只背“SpringBoot 好用、Vue 好用”要從架構(gòu)演進(jìn)的角度講傳統(tǒng)單體 JSP 模式前后端耦合嚴(yán)重改動一個頁面要把整個后端重新部署前后端分離后前端可以獨立開發(fā)和測試后端接口標(biāo)準(zhǔn)化后甚至能實現(xiàn)對多端復(fù)用小程序端和 Web 端共用一套接口?！绊椖康牧咙c在哪”不能只回答“功能齊全”要從細(xì)節(jié)里拎出亮點比如 JWT 無狀態(tài)認(rèn)證方案的設(shè)計、邏輯刪除保證檔案可追溯、金額精度統(tǒng)一用 BigDecimal 處理、庫存事務(wù)一致性控制。這些細(xì)節(jié)在架子上看不大但都是真正工程化項目里的常見難點?！叭绻颊吡孔兇笤趺磾U(kuò)展”這個問題考察架構(gòu)視野合理的回答是分布式層面橫向擴(kuò)展后端服務(wù)Redis 緩存熱點數(shù)據(jù)MySQL 做主從分離。注意不要做“大餅式”回答要落到具體細(xì)節(jié)比如哪些數(shù)據(jù)適合緩存、哪些接口適合加 Nginx 負(fù)載均衡想清楚再說會體現(xiàn)真實的邏輯水平。5.2 畢設(shè)項目后續(xù)可以怎么演進(jìn)如果畢設(shè)做完還有余力或者答辯想出一些“深色調(diào)味料”可以考慮下面幾個輕量演進(jìn)方向第一個方向是把訪問量大的接口加一層本地緩存。比如科室列表、藥品字典這些變動極少的數(shù)據(jù)可以考慮緩存起來避免每次請求都打數(shù)據(jù)庫。第二個方向是把文件存儲對象存儲化。社區(qū)醫(yī)院系統(tǒng)如果需要上傳檢查報告圖片可以考慮把圖片壓到云端的存儲桶里而不只是存在服務(wù)器本地靜態(tài)目錄。第三個方向是加一個數(shù)據(jù)可視化大屏。用 ECharts 做一個管理端首頁大屏展示今日掛號量、各科室就診人數(shù)排行、常用藥品消耗趨勢效果非常驚艷而且前端引入 ECharts 的代碼量并不大。做出來之后論文的“系統(tǒng)實現(xiàn)”章節(jié)能多放兩頁截圖演示效果也拔群。5.3 做畢設(shè)期間的時間管理建議從零開始做這個項目合理安排大概需要 4 到 6 周時間。第一周定技術(shù)棧、畫用例圖、建數(shù)據(jù)庫第二周完成后端基礎(chǔ)框架、登錄注冊和用戶管理模塊第三周完成患者管理和掛號模塊第四周完成處方、藥房模塊第五周集中寫系統(tǒng)測試和論文初稿最后留一周查漏補(bǔ)缺。給后面的同學(xué)留個建議不要最后兩周才開始動工數(shù)據(jù)庫表和前端路由結(jié)構(gòu)在開工前沒規(guī)劃好的話中期做需求變更很容易把自己搞崩。每天固定寫 1 到 2 個小時保持代碼的連續(xù)性和手感比最后三天狂趕通宵效率更高、心態(tài)也更穩(wěn)。6. 寫在最后個人經(jīng)驗小結(jié)這個項目做下來最大的體會是“畢設(shè)的意義不在題目本身而在推動你把零散的知識點串成一條完整的鏈路”。在課堂上學(xué)過 Spring、MySQL、Vue但只有在做一個全棧項目時才會真正意識到數(shù)據(jù)庫事務(wù)和庫存扣減之間的聯(lián)系、JWT 和前端路由守衛(wèi)的配合、以及部署時居然有這么多隱藏的細(xì)節(jié)。做完這個系統(tǒng)你后續(xù)去找實習(xí)寫簡歷時介紹項目能非常流暢地把架構(gòu)、技術(shù)選型、功能模塊、部署方案講完這一套完整的項目敘事本身就是很值錢的競爭力。一個小提醒網(wǎng)上已經(jīng)有很多現(xiàn)成的“社區(qū)醫(yī)院管理系統(tǒng)源碼”在流傳但直接下載時的學(xué)不到東西答辯更是一問一個不吱聲。這個題目本身并不難核心業(yè)務(wù)鏈條清晰照著這篇文章一步步做下來把每一層SQL、代碼、部署步驟都親手敲一遍確保自己理解了再運(yùn)行一個星期左右完成主體開發(fā)是完全可行的。等你看到自己的系統(tǒng)在服務(wù)器上通過域名穩(wěn)定運(yùn)行的那一天那種成就感和安全感是直接抄代碼永遠(yuǎn)無法替代的。