先說明一下這種“中小型醫(yī)院網(wǎng)站系統(tǒng)”的項(xiàng)目我在實(shí)際開發(fā)里接過不止一次。別誤會不是真的給醫(yī)院建核心HIS系統(tǒng)而是很多高校實(shí)訓(xùn)、畢業(yè)設(shè)計(jì)、以及一些小型診所或私立機(jī)構(gòu)的對外門戶站需求都是這一掛能展示科室和醫(yī)生、能掛號和預(yù)約、有簡單的后臺管理。技術(shù)棧固定得很死SpringBoot Vue MyBatis MySQL前后端分離要完整源碼要能跑起來。這篇文章就把我從零搭這套系統(tǒng)的完整思路、表結(jié)構(gòu)設(shè)計(jì)、核心接口實(shí)現(xiàn)、前端聯(lián)調(diào)細(xì)節(jié)、以及部署時(shí)容易踩的坑全部捋一遍。項(xiàng)目不大但五臟俱全搞懂這套同類管理系統(tǒng)你基本都能拿下來。1. 需求定位與功能模塊梳理1.1 中小型醫(yī)院網(wǎng)站到底要做什么很多人一上來就把項(xiàng)目想復(fù)雜了一個(gè)門診部級別的醫(yī)院網(wǎng)站硬要往三甲醫(yī)院綜合信息系統(tǒng)上靠結(jié)果前后端代碼堆了一堆沒用的功能最后演示時(shí)連核心流程都跑不通。我做了幾個(gè)這類項(xiàng)目之后總結(jié)下來的經(jīng)驗(yàn)是中小型醫(yī)院網(wǎng)站系統(tǒng)的核心價(jià)值就三個(gè)詞——信息展示、預(yù)約掛號、后臺管理。信息展示是門面包括醫(yī)院簡介、科室介紹、醫(yī)生排班、健康科普文章。用戶進(jìn)來先看這個(gè)覺得靠譜才會用下一步的預(yù)約功能。預(yù)約掛號是業(yè)務(wù)核心用戶選科室、選醫(yī)生、選時(shí)間段提交預(yù)約單后臺能夠?qū)徍嘶蛘咦詣?dòng)通過。后臺管理是運(yùn)營支撐管理員維護(hù)科室、醫(yī)生、排班、公告、預(yù)約記錄得能統(tǒng)計(jì)每日預(yù)約量。我建議項(xiàng)目迭代上先做基礎(chǔ)版前臺用戶端訪客可瀏覽注冊登錄后預(yù)約 管理后臺管理員維護(hù)基礎(chǔ)數(shù)據(jù)、查看預(yù)約。如果你的項(xiàng)目要求帶簡單問診或者在線咨詢那是二期擴(kuò)展別塞進(jìn)基礎(chǔ)版里不然后端接口和前端頁面都會失控。說白了這套系統(tǒng)本質(zhì)就是一個(gè)“內(nèi)容管理 預(yù)約業(yè)務(wù)”的復(fù)合型Web應(yīng)用。核心難點(diǎn)不在業(yè)務(wù)復(fù)雜度而在前后端數(shù)據(jù)交互的一致性、預(yù)約排班的邊界條件、以及權(quán)限控制是否干凈。1.2 角色劃分與權(quán)限設(shè)計(jì)權(quán)限這個(gè)東西很多學(xué)生項(xiàng)目做得一團(tuán)糟本質(zhì)原因是角色和接口沒有對齊。我習(xí)慣先定義清楚三類角色未登錄訪客ROLE_GUEST可以瀏覽科室、醫(yī)生、公告但不能提交預(yù)約。注冊用戶ROLE_PATIENT登錄后可以提交預(yù)約、查看自己的預(yù)約記錄、取消未接診的預(yù)約。管理員ROLE_ADMIN維護(hù)科室、醫(yī)生、排班、公告審核或查詢所有預(yù)約。權(quán)限控制在后端做前端按鈕隱藏在安全上沒有任何意義。我的做法是Spring Security JWT接口上直接標(biāo)PreAuthorize(hasRole(ADMIN))之類的注解角色定義就放在 JWT 的 authorities 字段里。訪客和患者的公共接口用permitAll涉及預(yù)約寫操作的接口必須要求登錄管理端接口單獨(dú)收斂到/api/admin/**路徑下統(tǒng)一攔截校驗(yàn)。前端路由上也要做對應(yīng)處理Vue Router 里配置全局守衛(wèi)根據(jù)本地存的 token 和角色信息決定能否進(jìn)入后臺頁面。導(dǎo)航菜單按照角色動(dòng)態(tài)渲染比如未登錄只顯示“登錄/注冊”入口患者登錄后顯示“我的預(yù)約”管理員登錄后顯示“后臺管理”。前后端雙重控制這才是能上線交付的樣子。2. 技術(shù)選型與項(xiàng)目搭建2.1 為什么是這套技術(shù)棧SpringBoot 的社區(qū)生態(tài)和自動(dòng)配置能力能讓你在 10 分鐘內(nèi)拉起一個(gè)可運(yùn)行的 Web 服務(wù)內(nèi)嵌 Tomcat部署只需要一個(gè) jar 包省去獨(dú)立配置服務(wù)器的繁瑣步驟。Vue 對前端組件化和狀態(tài)管理的支撐很成熟配合 Element Plus 組件庫后臺管理頁面幾乎是拼積木一樣搭出來的。MyBatis 雖然不是最輕量的但勝在 SQL 可控性強(qiáng)復(fù)雜多表聯(lián)查時(shí)直接手寫 SQL排除問題時(shí)一眼能看到底。MySQL 則中規(guī)中矩免費(fèi)穩(wěn)定中小型項(xiàng)目沒有任何性能瓶頸。這套組合最舒服的地方在于團(tuán)隊(duì)里每個(gè)人都能找到自己熟悉的部分Java 后端、JavaScript 前端、SQL 數(shù)據(jù)三層各司其職。如果換成一套全棧框架反而會模糊前后端邊界不利于項(xiàng)目演示和后續(xù)維護(hù)。2.2 工程結(jié)構(gòu)規(guī)劃后端工程我習(xí)慣按模塊分包而不是按技術(shù)類型分包。對比一下很多項(xiàng)目是 controller、service、mapper 三個(gè)包平鋪結(jié)構(gòu)是com.hospital.demo ├── controller ├── service ├── mapper這在小項(xiàng)目里還能看一旦功能多了controller 棧會比較混亂比如預(yù)約相關(guān)接口和用戶相關(guān)接口都擠在一堆文件里。我更推薦按業(yè)務(wù)域分包c(diǎn)om.hospital.system ├── common # 返回結(jié)果封裝、異常處理、工具類 ├── config # 安全配置、CORS配置、MyBatis配置 ├── modules │ ├── auth # 登錄注冊、JWT處理 │ ├── user # 患者用戶信息 │ ├── department # 科室 │ ├── doctor # 醫(yī)生與排班 │ ├── appointment # 預(yù)約掛號的業(yè)務(wù)邏輯 │ └── announcement每個(gè) module 內(nèi)部再按 controller / service / mapper / entity 分層。這樣定位問題時(shí)路徑清晰比如預(yù)約時(shí)間沖突問題直接鉆到modules/appointment里找 service不用在一堆平鋪文件里翻。前端我更建議用 Vue CLI 或者 Vite 創(chuàng)建單頁應(yīng)用目錄結(jié)構(gòu)按 views、components、router、store、api 劃分。核心原則是組件只負(fù)責(zé)渲染和交互業(yè)務(wù)數(shù)據(jù)請求全部收斂到api/目錄里封裝成獨(dú)立函數(shù)避免在組件里散落一堆a(bǔ)xios.get。2.3 環(huán)境版本建議我踩過一個(gè)典型坑某臺機(jī)器上 Java 版本過新SpringBoot 用 2.x結(jié)果 JWT 庫和某些注解不兼容編譯報(bào)錯(cuò)報(bào)了半天。版本這塊先問清楚項(xiàng)目要求沒有強(qiáng)制要求的話我這套組合實(shí)測最穩(wěn)JDK 1.8 或者 11SpringBoot 2.7.xVue 2.6.14 或 Vue 3.2我傾向 Vue 3 Vite組件寫法更舒服Element Plus配 Vue 3或 Element UI配 Vue 2MyBatis 2.2.x配合 SpringBoot 官方 starterMySQL 8.0注意 MyBatis 不是 MyBatis-Plus雖然 Plus 在開發(fā)效率上更高但題意指定的是 MyBatis。如果你確實(shí)想省事可以引入 MyBatis-Plus 的通用 CRUD 能力不過項(xiàng)目報(bào)告里要說明你用的其實(shí)是 MyBatis 體系避免指導(dǎo)教師或評審追問時(shí)對不上。3. 數(shù)據(jù)庫設(shè)計(jì)與核心表結(jié)構(gòu)3.1 設(shè)計(jì)思路中小型醫(yī)院網(wǎng)站的數(shù)據(jù)量不會很大表結(jié)構(gòu)不需要過度設(shè)計(jì)但有幾張表的邊界條件必須想明白否則后面寫業(yè)務(wù)邏輯會痛苦。我規(guī)劃了 7 張核心表每一張都能回答一個(gè)具體的業(yè)務(wù)問題用戶表誰能登錄系統(tǒng)科室表醫(yī)院有哪些診療方向醫(yī)生表每個(gè)科室有哪些醫(yī)生排班表醫(yī)生在哪個(gè)時(shí)間段出診預(yù)約表患者約了哪個(gè)醫(yī)生哪個(gè)時(shí)間段公告表首頁展示什么通知評論/留言表可選患者對就診體驗(yàn)的反饋。實(shí)際項(xiàng)目中我把用戶表設(shè)計(jì)成統(tǒng)一賬號表。管理員和普通患者都用同一張 user 表用 role 字段區(qū)分。表結(jié)構(gòu)清晰登錄時(shí)只查一張表不用去區(qū)分患者表和員工表兩張表。3.2 核心表結(jié)構(gòu)說明先看用戶表CREATE TABLE sys_user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登錄賬號, password varchar(100) NOT NULL COMMENT BCrypt加密后的密碼, real_name varchar(50) DEFAULT NULL COMMENT 真實(shí)姓名, gender tinyint DEFAULT NULL COMMENT 0未知 1男 2女, phone varchar(20) DEFAULT NULL, id_card varchar(18) DEFAULT NULL COMMENT 身份證號可選, role varchar(20) NOT NULL DEFAULT PATIENT COMMENT ADMIN/PATIENT, status tinyint NOT NULL DEFAULT 1 COMMENT 1啟用 0禁用, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT系統(tǒng)用戶表;密碼字段必須存加密后的數(shù)據(jù)用 BCrypt。明文密碼是最低級的錯(cuò)誤實(shí)訓(xùn)項(xiàng)目里如果被問到安全問題這也能證明你考慮過防護(hù)?？剖冶鞢REATE TABLE department ( id bigint NOT NULL AUTO_INCREMENT, dept_name varchar(100) NOT NULL, intro text COMMENT 科室介紹, location varchar(100) COMMENT 科室位置, sort_order int DEFAULT 0, status tinyint DEFAULT 1, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT科室表;醫(yī)生表與排班表是預(yù)約功能的基礎(chǔ)我把排班設(shè)計(jì)成一句話排班記錄的是一個(gè)醫(yī)生在某天的某個(gè)午別上午/下午是否有號、剩余多少號。醫(yī)生表關(guān)聯(lián)科室排班表關(guān)聯(lián)醫(yī)生和時(shí)間。預(yù)約表是整個(gè)系統(tǒng)最關(guān)鍵的表CREATE TABLE appointment ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 預(yù)約人ID, doctor_id bigint NOT NULL, schedule_id bigint NOT NULL COMMENT 排班ID, appointment_date date NOT NULL, time_slot varchar(10) NOT NULL COMMENT MORNING/AFTERNOON, status tinyint NOT NULL DEFAULT 0 COMMENT 0待接診 1已完成 2已取消, remark varchar(255) DEFAULT NULL COMMENT 病情描述, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT預(yù)約掛號表;注意這里我把a(bǔ)ppointment_date和time_slot冗余到了預(yù)約表里。雖然通過 schedule_id 可以關(guān)聯(lián)查出來但冗余存儲有兩個(gè)好處一是業(yè)務(wù)上展示很方便查預(yù)約記錄時(shí)不需要每一條都去連接排班表二是排班表后續(xù)調(diào)整時(shí)預(yù)約記錄不受影響。3.3 唯一索引與并發(fā)控制預(yù)約表的(schedule_id, appointment_date, time_slot, user_id)要加唯一索引避免同一個(gè)人重復(fù)提交同一個(gè)時(shí)段的預(yù)約。這個(gè)唯一索引比在 Service 里手工判斷要可靠得多因?yàn)楦卟l(fā)場景下兩個(gè)請求同時(shí)查到?jīng)]預(yù)約過然后同時(shí)插入Service 判斷防不住但數(shù)據(jù)庫唯一索引能擋住。類似這種場景的例子是搶課、搶號。醫(yī)院預(yù)約就是典型的有限并發(fā)場景數(shù)據(jù)庫層面的兜底必不可少。4. 后端核心功能實(shí)現(xiàn)要點(diǎn)4.1 統(tǒng)一返回結(jié)構(gòu)與全局異常處理前后端分離項(xiàng)目必須定義一個(gè)統(tǒng)一的返回格式。我習(xí)慣下面這種{ code: 200, message: success, data: {...} }對應(yīng)的 Java 類Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.code 200; r.message success; r.data data; return r; } public static T ResultT error(Integer code, String message) { ResultT r new Result(); r.code code; r.message message; return r; } }同時(shí)配合RestControllerAdvice做全局異常攔截。業(yè)務(wù)拋異常、參數(shù)校驗(yàn)失敗、認(rèn)證失敗統(tǒng)一轉(zhuǎn)換成 Result 結(jié)構(gòu)返回前端不管遇到什么問題解析的都是同一個(gè) JSON 結(jié)構(gòu)聯(lián)調(diào)時(shí)不用到處找字段名。4.2 JWT認(rèn)證流程登錄接口流程是這樣的接收用戶名密碼查庫用 BCrypt 校驗(yàn)密碼通過后生成 JWT 令牌返回給前端。前端把 token 存在 localStorage 或 pinia/vuex 狀態(tài)里之后每個(gè)請求在 axios 攔截器中自動(dòng)帶上Authorization: Bearer token。后端通過 OncePerRequestFilter 過濾器對每個(gè)請求做 token 解析和校驗(yàn)把用戶信息塞進(jìn) SecurityContext后續(xù)接口通過AuthenticationPrincipal或者 SecurityContextHolder 獲取當(dāng)前用戶信息。關(guān)鍵代碼String authHeader request.getHeader(Authorization); if (authHeader ! null authHeader.startsWith(Bearer )) { String token authHeader.substring(7); try { Claims claims Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token) .getBody(); String username claims.getSubject(); // 封裝并存儲到 SecurityContext } catch (Exception e) { // token 無效不設(shè)置認(rèn)證信息后續(xù)權(quán)限攔截自然會拒絕 } }我建議 token 有效期設(shè)置成 2 到 4 小時(shí)別太長。別人演示時(shí)不會在意這種細(xì)節(jié)但你項(xiàng)目文檔里如果能寫清楚令牌過期時(shí)間、刷新策略這是加分項(xiàng)。4.3 預(yù)約接口的核心邏輯預(yù)約提交是整個(gè)系統(tǒng)最核心的接口邏輯有幾層要堵查出排班記錄確認(rèn)狀態(tài)是啟用中的。校驗(yàn)排班日期是否大于等于今天過去的日期不能預(yù)約。檢查剩余號數(shù)大于 0 才能預(yù)約。插入預(yù)約記錄同時(shí)扣減排班表的剩余號數(shù)。如果已經(jīng)約滿返回友好提示“該時(shí)段已約滿”。這里有個(gè)事務(wù)問題扣減號數(shù)和插入預(yù)約記錄必須放在同一個(gè)事務(wù)里。我是用Transactional注解包住整個(gè)方法然后做樂觀鎖控制。Transactional(rollbackFor Exception.class) public Appointment createAppointment(Long scheduleId, String remark) { DoctorSchedule schedule scheduleMapper.selectByIdForUpdate(scheduleId); if (schedule.getRemaining() 0) { throw new BusinessException(該時(shí)段已約滿); } schedule.setRemaining(schedule.getRemaining() - 1); scheduleMapper.updateById(schedule); // 構(gòu)建預(yù)約記錄并插入 }selectByIdForUpdate是SELECT ... FOR UPDATE的行級鎖把排班記錄鎖住。這樣兩個(gè)并發(fā)請求同時(shí)進(jìn)來時(shí)第二個(gè)只能等第一個(gè)事務(wù)提交后才能拿到排班記錄此時(shí)剩余號數(shù)已經(jīng)被扣減再判斷就會返回約滿。這是解決并發(fā)預(yù)約的關(guān)鍵手段。4.4 MyBatis多表查詢的寫法MyBatis 的設(shè)計(jì)哲學(xué)是寫 SQL。預(yù)約列表接口需要展示科室、醫(yī)生、日期、時(shí)間段這時(shí)候連接查詢比多張表分開查再組裝要高效代碼也直觀。典型 Mapper XMLselect idselectAppointmentDetail resultTypecom.hospital.system.modules.appointment.vo.AppointmentVO SELECT a.id, a.appointment_date, a.time_slot, a.status, a.remark, d.dept_name, doc.name AS doctor_name, doc.title AS doctor_title FROM appointment a LEFT JOIN doctor doc ON a.doctor_id doc.id LEFT JOIN department d ON doc.dept_id d.id WHERE a.id #{id} /selectVO視圖對象專門用來承接這種聯(lián)表查詢結(jié)果盡量別把數(shù)據(jù)庫實(shí)體直接吐給前端。理由是前端不關(guān)心你的表字段結(jié)構(gòu)只關(guān)心頁面需要展示什么。比如 user 實(shí)體里有密碼字段如果你直接返回實(shí)體前端雖然拿不到要是寫了敏感字段的 getter但一旦序列化疏忽密碼字段就漏出去了。安全習(xí)慣要從這個(gè)層面就養(yǎng)起來。5. 前端頁面開發(fā)與接口聯(lián)調(diào)5.1 路由與頁面結(jié)構(gòu)規(guī)劃前端路由分成兩塊訪客/患者端和管理端。我按業(yè)務(wù)設(shè)計(jì)的頁面首頁/輪播圖、醫(yī)院簡介、公告列表、快捷掛號入口?？剖伊斜?departments卡片式展示科室點(diǎn)進(jìn)去看到科室和該科室醫(yī)生。醫(yī)生詳情/doctor/:id醫(yī)生簡介、排班表、預(yù)約按鈕。登錄/login、注冊/register注冊即患者角色。個(gè)人中心/my-appointments當(dāng)前登錄患者的預(yù)約記錄可取消操作。管理后臺/admin儀表盤、科室管理、醫(yī)生管理、排班管理、預(yù)約管理、公告管理。路由守衛(wèi)實(shí)現(xiàn)這樣router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.path.startsWith(/admin)) { const role localStorage.getItem(role); if (token role ADMIN) next(); else next(/login); } else if (to.path /my-appointments !token) { next(/login); } else { next(); } });5.2 axios封裝與請求攔截前端請求層我封裝了一個(gè)統(tǒng)一的 request 模塊導(dǎo)出各業(yè)務(wù)模塊對應(yīng)的 API 函數(shù)。axios 攔截器里做兩件事請求時(shí)帶 token響應(yīng)時(shí)統(tǒng)一處理 code。request.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer token; } return config; }); request.interceptors.response.use( res { const { code, message, data } res.data; if (code 200) { return data; } else if (code 401) { localStorage.clear(); router.push(/login); return Promise.reject(new Error(message)); } else { ElMessage.error(message); return Promise.reject(new Error(message)); } }, err Promise.reject(err) );這里要注意401 統(tǒng)一跳登錄頁面是個(gè)技術(shù)關(guān)鍵處理。如果不做token 過期之后用戶操作沒有任何反應(yīng)頁面看起來像卡住了一樣。5.3 預(yù)約表單的前后交互邏輯前端預(yù)約表單有排班選擇。點(diǎn)擊某個(gè)醫(yī)生排班后前端要拿到該排班的剩余號數(shù)實(shí)時(shí)顯示“剩余 12 人”。如果剩余為 0禁止提交。這個(gè)判斷背后依賴的是后端接口/api/schedule/listByDoctorAndDate。我處理的方式是醫(yī)生詳情頁初始加載時(shí)調(diào)用后端子啊接口拉取該醫(yī)生 7 天內(nèi)的排班前端以卡片橫排展示。選中某天的排班后下方顯示預(yù)約按鈕若當(dāng)天已約滿按鈕置灰并顯示“約滿”?；颊叽_認(rèn)提交后寫 remark 病情描述提交到/api/appointment接口。前端拿到的數(shù)據(jù)是展示層模型前端不做業(yè)務(wù)判斷嚴(yán)格要求后端校驗(yàn)排班時(shí)間、剩余號數(shù)、重復(fù)預(yù)約等多個(gè)邊界條件。前后端分離的設(shè)計(jì)原則是前端負(fù)責(zé)“展示對不對”后端負(fù)責(zé)“業(yè)務(wù)能不能做”。5.4 ECharts圖表在管理后臺的運(yùn)用管理后臺的儀表盤我一般展示三塊數(shù)據(jù)今日預(yù)約量、各科室預(yù)約占比餅圖、近一周每日預(yù)約趨勢柱狀圖。用 ECharts 實(shí)現(xiàn)不復(fù)雜但關(guān)鍵在于給后端提供對應(yīng)的統(tǒng)計(jì)接口。后端統(tǒng)計(jì)接口是一個(gè)典型的練習(xí)點(diǎn)近七日的每日預(yù)約量SQL 里GROUP BY appointment_date即可。各科室預(yù)約占比需要連接科室、醫(yī)生、預(yù)約三張表。這個(gè)接口返回的格式要和 ECharts 的數(shù)據(jù)結(jié)構(gòu)對齊比如餅圖需要{ name: 內(nèi)科, value: 35 }后端可以直接構(gòu)造 List返回前端無需二次加工。這類統(tǒng)計(jì)功能雖然業(yè)務(wù)邏輯簡單但把 SQL 聚合、Map 構(gòu)造、圖表數(shù)據(jù)綁定這幾個(gè)環(huán)節(jié)都打通了整個(gè)項(xiàng)目的完整度會明顯提升。6. 部署流程與常見問題排查6.1 本地快速啟動(dòng)指南拿到源碼后的部署流程我提供一個(gè)實(shí)操過的順序。假設(shè)你用的是 IDEA 命令行前端工具。后端啟動(dòng)創(chuàng)建本地?cái)?shù)據(jù)庫hospital_web執(zhí)行sql/init.sql腳本初始化表和默認(rèn)數(shù)據(jù)。修改application.yml的數(shù)據(jù)庫連接改成你自己的賬號密碼。運(yùn)行mvn spring-boot:run默認(rèn)端口 8080。默認(rèn)數(shù)據(jù)里我會預(yù)置一個(gè)管理員賬號admin / admin123一個(gè)患者測試賬號patient / 123456。演示時(shí)直接能登錄不用手動(dòng)注冊。前端啟動(dòng)進(jìn)入frontend/目錄執(zhí)行npm install。npm run serve默認(rèn)端口 5173Vite或 8081Vue CLI。瀏覽器訪問前端地址用測試賬號登錄。如果前端接口連不上后端優(yōu)先檢查前端.env文件里的VITE_API_BASE_URL確保代理配置指向http://localhost:8080。Vite 開發(fā)服務(wù)器配置代理server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }這樣前端請求/api/login時(shí)會自動(dòng)轉(zhuǎn)發(fā)到后端的http://localhost:8080/api/login不需要跨域配置也能工作。生產(chǎn)環(huán)境下Nginx 反向代理也是同樣原理。6.2 前后端跨域配置很多初學(xué)前后端分離的人在本地聯(lián)調(diào)時(shí)遇到跨域亂加一通 header 解決不了我來給一個(gè)最可靠的兩個(gè)位置解決方案后端明確開啟全局 CORS 配置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); } }但注意如果你已經(jīng)用了 Spring SecurityCORS 配置必須生效于 Security 過濾器鏈之前。所以安全配置里要加http.cors()只是WebMvcConfigurer配置有可能被 Security 層的攔截器擋住OPTIONS 預(yù)檢請求直接被 401 攔截掉。解決方法是安全配置中放行 OPTIONS 請求。這個(gè)坑非常經(jīng)典。如果你使用了 Vite 或 Vue CLI 開發(fā)服務(wù)器代理那么前端請求和后端同源跨域問題根本不存在。生產(chǎn)環(huán)境由 Nginx 反向代理同樣不存在跨域。所以我個(gè)人淺見后端 CORS 配置是兜底方案首選是代理。6.3 常見錯(cuò)誤清單我把做這類項(xiàng)目過程中遇到頻率最高的錯(cuò)誤列成一張表你可以直接對照排查錯(cuò)誤現(xiàn)象可能原因解決方案前端請求報(bào) 401頁面反復(fù)跳登錄JWT 過期、token 沒帶上、Security 放行了錯(cuò)誤路徑檢查后端放行名單是否包含 /api/login、檢查前端攔截器是否帶 token登錄時(shí)報(bào)“密碼錯(cuò)誤”但密碼明明是 admin123默認(rèn)數(shù)據(jù)腳本里的密碼沒有經(jīng)過 BCrypt 加密直接去數(shù)據(jù)庫跑一個(gè) BCrypt 加密工具生成密文或者用注冊接口注冊一個(gè)新管理員預(yù)約接口返回 500控制臺報(bào)“數(shù)據(jù)被截?cái)唷泵杜e值或長度超限檢查 status 字段類型確保用 tinyint 映射 0/1/2頁面能出數(shù)據(jù)但圖片全部裂開上傳的圖片路徑是相對路徑跨域或代理后失效統(tǒng)一用絕對 URL 組裝圖片路徑生產(chǎn)環(huán)境配合 Nginx 設(shè)置靜態(tài)資源路由部署到服務(wù)器后接口能通但訪問靜態(tài)資源 404打包后的 dist 目錄路徑問題Nginx 里配置root /your_project/distlocation 指向準(zhǔn)確路徑try_files $uri /index.html順帶說一個(gè)特別常見的坑SpringBoot 多模塊項(xiàng)目里如果 resources 目錄下沒有mapper文件夾或者 Mapper XML 文件沒有被 Maven 打包進(jìn) jar運(yùn)行時(shí) MyBatis 會報(bào)Invalid bound statement (not found)。解決方案是在 pom.xml 的 build 插件里配置 resources 包含 XML 文件路徑或者把 Mapper XML 放在 resources/mapper 目錄下保證打包后 classes 里有對應(yīng)文件。6.4 Nginx部署實(shí)戰(zhàn)生產(chǎn)環(huán)境部署我通常不用 jar 直接裸奔而是前端打包后交由 Nginx 托管后端 jar 通過 systemd 守護(hù)進(jìn)程方式運(yùn)行。后端 jar 啟動(dòng)nohup java -jar hospital-system-1.0.0.jar --server.port8080 app.log 21 Nginx 配置同時(shí)處理前端靜態(tài)資源和 API 反向代理server { listen 80; server_name your-domain.com; root /usr/share/nginx/hospital-frontend; index index.html; # 前端路由 history 模式 location / { 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }這里try_files $uri $uri/ /index.html是 Vue Router history 模式的關(guān)鍵不加這行直接訪問/my-appointments就會 404。還有一個(gè)小細(xì)節(jié)是數(shù)據(jù)庫連接池配置。默認(rèn)的 HikariCP 在長時(shí)間空閑后MySQL 可能會斷開空閑連接報(bào)Communications link failure。在application.yml里加spring: datasource: hikari: connection-test-query: SELECT 1 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000這就是保活設(shè)置。很多項(xiàng)目跑到第二天突然接口全部超時(shí)大概率就是這個(gè)原因。7. 項(xiàng)目擴(kuò)展與進(jìn)階心得7.1 可擴(kuò)展的方向基礎(chǔ)功能做完后這套系統(tǒng)往上擴(kuò)展的空間很大。一個(gè)方向是引入 Redis 緩存。目前科室、醫(yī)生列表這類熱點(diǎn)數(shù)據(jù)每次請求都打 MySQL如果訪問量上來壓力會逐步增加。引入 Redis 做緩存把科室列表、醫(yī)生列表先緩存預(yù)約時(shí)再走數(shù)據(jù)庫強(qiáng)一致操作。另一個(gè)方向是增加消息推送。患者預(yù)約成功、預(yù)約前一天提醒這類需求可以通過接入簡單消息服務(wù)實(shí)現(xiàn)。不過如果是高校項(xiàng)目不建議在這個(gè)方向耗費(fèi)太多時(shí)間——評估要求里沒有這項(xiàng)價(jià)值不大。把基礎(chǔ)功能做扎實(shí)、寫清楚比堆功能更能拿高分。至于在線支付功能我勸你別在基礎(chǔ)版里加。支付涉及商戶號申請和真實(shí)交易流程項(xiàng)目演示時(shí)引入復(fù)雜度遠(yuǎn)大于收益。如果導(dǎo)師非要求有支付環(huán)節(jié)你做一個(gè)“線下到付”狀態(tài)標(biāo)記即可預(yù)約成功顯示“請到院支付掛號費(fèi)”。7.2 代碼規(guī)范與項(xiàng)目文檔項(xiàng)目文檔的重要性很多時(shí)候被團(tuán)隊(duì)低估了。代碼寫得再好如果 README 里沒有啟動(dòng)步驟數(shù)據(jù)庫腳本沒給全部署說明一團(tuán)糊演示的時(shí)候手忙腳亂印象分還是會打折扣。我慣用的 README 骨架是項(xiàng)目簡介與角色說明。技術(shù)棧列表。數(shù)據(jù)庫初始化步驟。后端啟動(dòng)步驟。前端啟動(dòng)步驟。默認(rèn)賬號。接口文檔簡表路徑、方法、鑒權(quán)要求。常見問題啟動(dòng)失敗、連不上數(shù)據(jù)庫等。接口文檔不一定要用 Swagger但可以引入SpringBoot 集成 springdoc 很輕松。訪問/swagger-ui.html就能看到在線接口列表。這個(gè)對評審、對自測、對前后端聯(lián)調(diào)都非常有用強(qiáng)烈建議加。7.3 一點(diǎn)個(gè)人建議最后分享一條我在這類項(xiàng)目上反復(fù)體會到的經(jīng)驗(yàn)功能寧可少而穩(wěn)不要多而崩。評審老師或者客戶在演示時(shí)更看重的是核心流程能不能從頭到尾走通以及你對自己代碼邏輯的理解程度。與其堆一堆花哨功能但到處都是坑不如把掛號預(yù)約這條主鏈路做深做透把事務(wù)、并發(fā)、權(quán)限這些細(xì)節(jié)處理干凈。這套系統(tǒng)的表結(jié)構(gòu)、接口設(shè)計(jì)、部署方式做完這一次你后面再做 CRM、教務(wù)、物資管理本質(zhì)上就是換皮加改幾個(gè)業(yè)務(wù)字段——底層套路都是相通的。